solc Compiler optimization error(Optimizes the definition of equivalence to the same goal) about solidity HOT 6 CLOSED

Thanks for the report! It's a real issue, but we already have one covering it (#13969), so I'm going to close this one as a duplicate.

On 0.8.x and earlier it's best to consider the result of comparisons between internal function pointers undefined (i.e. it has a consistent value, but not across compilations; do not rely on this value staying the same regardless of compiler settings or releases). The pointer type has always been (intentionally) treated as opaque in the language. The underlying value cannot be obtained without using assembly and was only indirectly exposed via this kind of comparison. Its usefulness is questionable so hopefully this pattern is pretty rare. A proper fix is breaking so it's only going to be fixed in 0.9, but we're going to start issuing a warning about this pattern soon.

solc compiler ignored the effect of identifiers on the contract code when the optimizer was on, only cared about the function statements, and collapsed the storage if the function statements were consistent.

Well, the values of the storage variables are never used (statements a; and b; have no side-effects) so the optimizer is very likely to remove them and collapse the function bodies into one.

from solidity.

But I ran into the same problem in a similar example below：I can understand that when f3() is executed, the local variable has been released, so the optimizer considers it consistent.

pragma solidity ^0.8.18;

contract Test {

function c() public {uint a = 1;}
function b() public {bool a = true;}

function f3() external returns(bool) {
return c == b;
}
}

from solidity.

hello，I was wondering if you could still receive my comments after the issue is closed?

from solidity.

I mean, this issue is closed as a duplicate, but #13969 is still open. But I'm not sure what your question is here.

from solidity.

What I mean is that the original examples provided may not have significant functional differences, but in the following examples, the local variable "uint a = 1;" and "bool a = true;" should not generate the same error. However, in fact, they triggered the aforementioned error.
contract Test {
function c() public { uint a = 1;}
function b() public { bool a = true;}
function f3() external returns(bool) {
return c == b;
}
}

from solidity.

Why do you think they should not generate the same error? Both variable declarations are basically no-ops so the optimizer may remove them.

If you want something that won't get optimized out, it needs to affect the environment. Like, change the return value, write to storage, emit an event, revert, etc.

BTW, if you want to see what really happens, compile with --optimize --ir-optimized and look for the function in the output.

from solidity.