-
Notifications
You must be signed in to change notification settings - Fork 25
fix(compiler): align call gas accounting with interpreter #311
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#312 is for interpreter to pass the evmone unittest.
You change fails the evmone unittest for multipass.
[ FAILED ] multi_vm/evm.call_failing_with_value/external_vm, where GetParam() = 0x602000006f10
[ FAILED ] multi_vm/evm.call_new_account_creation_cost/external_vm, where GetParam() = 0x602000006f10
Looks like the state test you tend to fix conflicts with evmone's unittest.
|
conflict |
| constexpr bool PRINT_FAILURE_DETAILS = true; | ||
| // TODO: RunMode selection logic will be refactored in the future. | ||
| constexpr auto STATE_TEST_RUN_MODE = common::RunMode::MultipassMode; | ||
| constexpr auto STATE_TEST_RUN_MODE = common::RunMode::InterpMode; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why change to InterpMode by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The latest #334 defaults to InterpMode.
|
It seems these |
evm_interp_tests then scans all .evm.hex files and fails if a matching .expected is missing.So these .expected files are not redundant—they are the missing golden outputs for shift tests that are now actually executed. Removing them would make the interpreter tests fail unless we also stop generating those .evm.hex files or relax the test requirements. |
1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):
2. What is the scope of this PR (e.g. component or file name):
3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):
4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):
5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:
6. Release note