Miscompile in `__revive_signed_remainder`: `srem(INT256_MIN, -1)` UB

[jubnzv]

SignedRemainder lowers Solidity signed % (EVM SMOD) to a bare LLVM srem via build_int_signed_rem, guarded only against a zero divisor by wrapped_division. For divisor -1 it emits srem x, -1, which is UB in LLVM when x == INT256_MIN and constant-folds to poison.

MRE:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.20;
contract C {
    function f(int256 x) external pure returns (int256) {
        // INT_MIN % -1 == 0, so this is the identity `return x;`
        unchecked { return (type(int256).min % ((int256(-1) << 58) >> 58)) ^ x; }
    }
}

Reproduce: compile with resolc -O3 --bin mre.sol and call f(5) on PolkaVM/pallet-revive — it returns 0. The same source compiled with solc --bin-runtime --optimize and run on go-ethereum evm returns 5.

EVM:     f(5) = 0x...05   (correct)
PolkaVM: f(5) = 0x...00   (whole function collapsed to 0)

Expected behavior: f(x) == x for all x (EVM SMOD(INT_MIN, -1) = 0).

Notes:

• Only signed % (srem); / (sdiv) is guarded and correct.
• Runtime x % y with (INT_MIN, -1) is correct — the bare srem lowers to RISC-V rem, which defines INT_MIN rem -1 = 0; the bug is only LLVM's constant-fold of srem(constINT_MIN, const-1), so the dividend must also be compile-time constant.
• The divisor must be a -1 that solc does not pre-fold to a literal (here (int256(-1) << 58) >> 58); writing int256(-1) directly makes solc fold INT_MIN % -1 → 0 itself and the bug disappears.
• Silent: no diagnostic; PolkaVM bytecode returns the wrong constant.

Git commit: 7fe8d41 (revive)
Build: resolc release, -O3; solc 0.8.35-develop; go-ethereum evm 1.17.2

[xermicus]

Many thanks for the bug report @jubnzv. The bug stems from constant folding optimizations in LLVM. We already test against those EVM specific edge cases, but not where one side of the operation is constant. I'm on a PR and release fixing this.

[xermicus]

How did you find this, do you know of any popular library or dApp code affected by this? Its a narrow hit; the bug is only triggered for SREM with the two exact constants type(int256).min and -1, and then only when not expressed directly but written specifically such that solc doesn't constant fold it but LLVM does.

[jubnzv]

How did you find this, do you know of any popular library or dApp code affected by this?

I found it using a custom tool for testing Ethereum compilers. The program is generated, and the identity is synthesized.

I don't think this could occur in any production contract because of the requirements to constants and the shape of the pattern. That's is why I reported it publicly.

[xermicus]

Yeah I agree, its a very weird way to express the constant of 0 after all. But its anyways nice to have the edge case fixed.