https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Optimization reasons as follows. points-to analysis considers even integers as
possible pointer (parts) and thus starts with i pointing to the NULL object.
Incrementing that get's you to any _global_ object (but not automatic vars
as those do not need to have a fixed location). Thus p ends up as
p_8 = { NULL NONLOCAL }
and dereferencing that aliases with any global but not x as that is an
automatic
var.
I think the compiler is free to re-locate x right before
*p = 15;
and load x from a different location. Computing the value (uintptr_t)&x
isn't preventing that as the address is not "live" after that.
