The Yul optimizer causes mstore results to be inconsistent.
- Dominant language
- C++
- Stars
- 25.7k
- Forks
- 6.2k
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 29
Description
## Environment
- Compiler version: 0.8.26
- Target EVM version (as per compiler settings): None
- Framework/IDE (e.g. Truffle or Remix): None
- EVM execution environment / backend / blockchain client: None
- Operating system: Linux
## Steps to Reproduce
```solidity
{
function f(a, b) -> x {
x := add(b, a)
}
function g() -> y {
y := mload(0)
mstore(0, 4)
}
let i := 0
for {} lt(i, 2) { i := add(i, 1) }
{
let x := 1337
if lt(i, 1) {
x := 42
continue
}
mstore(0, x)
}
let r := f(g(), mload(0))
sstore(0, r)
}
```
### Get Bin
#### normal
```
solc-0826 --strict-assembly --bin test.yul
5f5b60028110601a5760165f5160126037565b6033565b5f55005b600190610539828210602e575f525b016001565b506029565b0190565b5f519060045f5256
```
#### optimize
```
solc-0826 --strict-assembly --optimize --bin test.yul
5f5b600281106010575f5180015f55005b6001906105398282106024575f525b016001565b50601f56
```
### Run in EVM
#### normal
```
go-ethereum/build/bin/evm --debug --json --code 5f5b60028110601a5760165f5160126037565b6033565b5f55005b600190610539828210602e575f525b016001565b506029565b0190565b5f519060045f5256 run
```
#### optimize
```
go-ethereum/build/bin/evm --debug --json --code 5f5b600281106010575f5180015f55005b6001906105398282106024575f525b016001565b50601f56 run
```
### Execution result analysis
#### normal
```
output,storage,memory
{'output': '', 'gasUsed': '0x575c'},{'0': '2674'},{'0': '4'}
```
#### optimize
```
output,storage,memory
{'output': '', 'gasUsed': '0x571c'},{'0': '2674'},{'0': '1337'}
```
The data at position 0 is different. The suspected cause is that mstore(0, 4) was incorrectly optimized away.
Contributor guide
Research direction
Start with the strict-assembly reproducer in the issue, compile it with solc 0.8.26 both with and without --optimize, and run the resulting bytecode using go-ethereum's evm command. Trace the Yul optimizer's handling of mstore and compare memory position 0; the fix is complete when optimized and unoptimized execution produce the same memory and storage results.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, solidity
- Domain
- blockchain, compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100