You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The values of interest are 0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563 (keccak256(0, 32)) and 0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e564 (add(keccak256(0, 23), 1)).
The bug is that the legacy optimiser "pre-computes" keccak256(0, 23) to be somehow equal to keccak256(0, 32) which is incorrect. Although the value at memory location is zero, keccak256(0, 32) = 0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563 but keccak256(0, 23) = 0xe2b9f9f9430b05bfa9a3abd3bac9a181434d23a707ef1cde8bd25d30203538d8.
Because of the incorrect code, it turns out that data[1] == 123 although the assembly operation sstore(add(keccak256(0, 23), 1), 123) is actually storing the value 123 to some unrelated storage slot.
Please note that the old code generator without optimisation enabled produces correct result (failing assertion because both the keccaks are not precomputed). The same holds true for new code gen with or without optimisation enabled.
It looks like loadFromMemory always works at 32-byte granularity, so the fact that we are actually doing a sub-32-byte-word keccak is not taken into consideration. Anyway, good to get a quick ack, thanks once again for the pointer hrkrshnn
bshastry
changed the title
[Optimizer] Legacy optimizer precomputes keccak256 incorrectly
[Optimizer] Legacy optimizer precomputes successive keccak256 from the same location but different size incorrectly
Mar 20, 2021
Description
The following test does not revert when run on an EVM client after it has been optimised by the legacy optimiser (i.e.,
solc --optimize test.sol
).The following assembly code is produced (only relevant snippet has been pasted)
The values of interest are
0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563
(keccak256(0, 32)
) and0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e564
(add(keccak256(0, 23), 1)
).The bug is that the legacy optimiser "pre-computes"
keccak256(0, 23)
to be somehow equal tokeccak256(0, 32)
which is incorrect. Although the value at memory location is zero,keccak256(0, 32) = 0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563
butkeccak256(0, 23) = 0xe2b9f9f9430b05bfa9a3abd3bac9a181434d23a707ef1cde8bd25d30203538d8
.Because of the incorrect code, it turns out that
data[1] == 123
although the assembly operationsstore(add(keccak256(0, 23), 1), 123)
is actually storing the value123
to some unrelated storage slot.Please note that the old code generator without optimisation enabled produces correct result (failing assertion because both the keccaks are not precomputed). The same holds true for new code gen with or without optimisation enabled.
Environment
Steps to Reproduce
val()
The text was updated successfully, but these errors were encountered: