https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93010
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm not sure GCCs behavior is non-conforming here. What happens is that we
compute u == v at compile-time, combining stmts from
<bb 2> :
D.2438 = 0;
u_6 = (long unsigned int) &D.2438;
D.2438 ={v} {CLOBBER};
D.2439 = 0;
v_9 = (long unsigned int) &D.2439;
D.2439 ={v} {CLOBBER};
_1 = u_6 - v_9;
printf ("diff = %lu\n", _1);
_2 = u_6 == v_9;
_3 = (int) _2;
printf ("eq = %d\n", _3);
_13 = 0;
return _13;
but we can't compute a definitive value for the difference so that gets
computed at runtime where stack layouting happens to place D.2438 and D.2439
at the same address.
So the inconsistency is that GCC first assumes no such thing as stack slot
sharing happens but then does it anyways. I guess we'd be allowed to
optimize u - v to an arbitrary constant(?) but then enough trickery can
expose the "real" values again (and the "inconsistency").
I see no good way "fixing" GCC here without sacrifying normal usage for this
arcane case.
