https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82282
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |82177
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is really the same / similar as PR82177.
if (u_14 != v_15)
goto <bb 3>;
else
goto <bb 4>;
<bb 4>:
# v_1 = PHI <u_14(2), u_14(3)>
v.0_19 = (int *) v_1;
glb = v.0_19;
so there's a missed trivial optimization not done by phiopt to
u_14 = (uintptr_t) &MEM[(void *)&x + 4B];
...
if (u_14 != v_15)
goto <bb 3>;
else
goto <bb 4>;
<bb 4>:
v.0_19 = (int *) u_14;
where (int *) u_14 would be folded to just &MEM[(void *)&x + 4B].
It's not partial redundancy elimination but value-numbering does this
kind of cleanup. forwprop would also do it and there's nothing wrong
with this.
In C you are only allowed to convert a pointer back and forth
with [u]intptr_t, so when you convert it back you get the original
pointer which means it still points to one-after 'x'. You can't
make it possibly point to 'y' by this trick. Specifically you
are not allowed to make a uintptr_t from a pointer to object A,
do some magic on that value, convert it to a pointer again and
expect it to point to object B.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82177
[Bug 82177] Alias analysis too aggressive with integer-to-pointer cast
