-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deploy Bytecode Generated by --via-ir Failed #13311
Comments
The difference is documented in https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes This is due to the order of initialization of Closing this for now. Feel free to reply if you have questions. |
Closed
2 tasks
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 22, 2023
…et exchange 1. Without having it pinned to v0.8.8, some breaking changes that solc has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract deployment in a way that opcodes end up in the migration contract's constructor that Besu does not recognize ("opcode INVALID" in the besu logs if you set the log level to "ALL") in the Besu logs and then sends back an "internal error" message via the JSON-RPC response, which is a bug IMO it should state that the user input was invalid (user input being the contract) 2. Disabled IR in the truffle (solc) config which is a step backwards because it's a new feature of the solidity compiler that has certain benefits to it compared to the legacy compilation mode, but enabling it breaks the build so it just had to be done. In the future if someone has time to do a deep dive on why exactly it's failing, then it should be re-enabled because having the legacy compilation mode being our default is technical debt that should be paid off rather sooner than later because we never know how it will come back to cause different issues later on. When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc): > Compiling ./contracts/transferInterface.sol > YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack. [1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes [2]: ethereum/solidity#13311 (comment) Fixes hyperledger-cacti#2423 Signed-off-by: Peter Somogyvari <[email protected]>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 22, 2023
…et exchange 1. Without having it pinned to v0.8.8, some breaking changes that solc has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract deployment in a way that opcodes end up in the migration contract's constructor that Besu does not recognize ("opcode INVALID" in the besu logs if you set the log level to "ALL") in the Besu logs and then sends back an "internal error" message via the JSON-RPC response, which is a bug IMO it should state that the user input was invalid (user input being the contract) 2. Disabled IR in the truffle (solc) config which is a step backwards because it's a new feature of the solidity compiler that has certain benefits to it compared to the legacy compilation mode, but enabling it breaks the build so it just had to be done. In the future if someone has time to do a deep dive on why exactly it's failing, then it should be re-enabled because having the legacy compilation mode being our default is technical debt that should be paid off rather sooner than later because we never know how it will come back to cause different issues later on. When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc): > Compiling ./contracts/transferInterface.sol > YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack. [1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes [2]: ethereum/solidity#13311 (comment) Fixes hyperledger-cacti#2423 Signed-off-by: Peter Somogyvari <[email protected]>
sandeepnRES
pushed a commit
to petermetz/cacti
that referenced
this issue
May 30, 2023
…et exchange 1. Without having it pinned to v0.8.8, some breaking changes that solc has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract deployment in a way that opcodes end up in the migration contract's constructor that Besu does not recognize ("opcode INVALID" in the besu logs if you set the log level to "ALL") in the Besu logs and then sends back an "internal error" message via the JSON-RPC response, which is a bug IMO it should state that the user input was invalid (user input being the contract) 2. Disabled IR in the truffle (solc) config which is a step backwards because it's a new feature of the solidity compiler that has certain benefits to it compared to the legacy compilation mode, but enabling it breaks the build so it just had to be done. In the future if someone has time to do a deep dive on why exactly it's failing, then it should be re-enabled because having the legacy compilation mode being our default is technical debt that should be paid off rather sooner than later because we never know how it will come back to cause different issues later on. When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc): > Compiling ./contracts/transferInterface.sol > YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack. [1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes [2]: ethereum/solidity#13311 (comment) Fixes hyperledger-cacti#2423 Signed-off-by: Peter Somogyvari <[email protected]>
sandeepnRES
pushed a commit
to hyperledger-cacti/cacti
that referenced
this issue
May 30, 2023
…et exchange 1. Without having it pinned to v0.8.8, some breaking changes that solc has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract deployment in a way that opcodes end up in the migration contract's constructor that Besu does not recognize ("opcode INVALID" in the besu logs if you set the log level to "ALL") in the Besu logs and then sends back an "internal error" message via the JSON-RPC response, which is a bug IMO it should state that the user input was invalid (user input being the contract) 2. Disabled IR in the truffle (solc) config which is a step backwards because it's a new feature of the solidity compiler that has certain benefits to it compared to the legacy compilation mode, but enabling it breaks the build so it just had to be done. In the future if someone has time to do a deep dive on why exactly it's failing, then it should be re-enabled because having the legacy compilation mode being our default is technical debt that should be paid off rather sooner than later because we never know how it will come back to cause different issues later on. When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc): > Compiling ./contracts/transferInterface.sol > YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack. [1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes [2]: ethereum/solidity#13311 (comment) Fixes #2423 Signed-off-by: Peter Somogyvari <[email protected]>
barnapa
pushed a commit
to barnapa/cacti
that referenced
this issue
Jun 15, 2023
…et exchange 1. Without having it pinned to v0.8.8, some breaking changes that solc has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract deployment in a way that opcodes end up in the migration contract's constructor that Besu does not recognize ("opcode INVALID" in the besu logs if you set the log level to "ALL") in the Besu logs and then sends back an "internal error" message via the JSON-RPC response, which is a bug IMO it should state that the user input was invalid (user input being the contract) 2. Disabled IR in the truffle (solc) config which is a step backwards because it's a new feature of the solidity compiler that has certain benefits to it compared to the legacy compilation mode, but enabling it breaks the build so it just had to be done. In the future if someone has time to do a deep dive on why exactly it's failing, then it should be re-enabled because having the legacy compilation mode being our default is technical debt that should be paid off rather sooner than later because we never know how it will come back to cause different issues later on. When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc): > Compiling ./contracts/transferInterface.sol > YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack. [1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes [2]: ethereum/solidity#13311 (comment) Fixes hyperledger-cacti#2423 Signed-off-by: Peter Somogyvari <[email protected]>
barnapa
pushed a commit
to barnapa/cacti
that referenced
this issue
Jun 15, 2023
…et exchange 1. Without having it pinned to v0.8.8, some breaking changes that solc has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract deployment in a way that opcodes end up in the migration contract's constructor that Besu does not recognize ("opcode INVALID" in the besu logs if you set the log level to "ALL") in the Besu logs and then sends back an "internal error" message via the JSON-RPC response, which is a bug IMO it should state that the user input was invalid (user input being the contract) 2. Disabled IR in the truffle (solc) config which is a step backwards because it's a new feature of the solidity compiler that has certain benefits to it compared to the legacy compilation mode, but enabling it breaks the build so it just had to be done. In the future if someone has time to do a deep dive on why exactly it's failing, then it should be re-enabled because having the legacy compilation mode being our default is technical debt that should be paid off rather sooner than later because we never know how it will come back to cause different issues later on. When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc): > Compiling ./contracts/transferInterface.sol > YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack. [1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes [2]: ethereum/solidity#13311 (comment) Fixes hyperledger-cacti#2423 Signed-off-by: Peter Somogyvari <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I tested the bytecode generated by IR (compiler version is 0.8.15).
The source code is here: https://paste.ubuntu.com/p/rxH3snBD6Y/
I compile it with the following command to obtain the bytecode.
I used Ganache (v2.6.0-beta.3) to be the local Ethereum environment.
The key part of my deploy script:
The deployment was revert
But the constructor is
where maxSupply is 4444.
The constructor of ERC721A:
However, when I use the command
to generate the bytecode. The bytecode can be deployed successfully.
Actually, I tested 50 real-world smart contracts from Etherscan and 5 of them couldn't be deployed.
Another finding is that the gas consumption of IR generator is higher than the legacy generator.
Update:
If I change
to
IR generator works.
The text was updated successfully, but these errors were encountered: