https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67828
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #3 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Created attachment 36448
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36448&action=edit
Patch I'm testing to fix the bug
This testcase invokes undefined behavior because of the overflow on the
iterator, but the cause of the problem is undefined behavior we introduce
ourselves by unswitching the loop on the uninitialized variable j. Things go
down the hill from there, as we uncprop j's default def in the j==0 branch into
one of D's phi nodes in that version of the loop, then we coalesce j's default
def with some versions of d (we only detect conflicts for parms' and results'
default defs), including the one passed to printf. init-regs adds zero
initialization for j, the loop-entry initialization of d with 1 overrides it,
and the assignment to zero within the loop, that uncprop had turned into a copy
from j (known to be zero in that branch), is optimized out because of the
coalescing. So the initialization of d to 1 prevails. Preventing coalescing
by detecting conflicts with non-params would also avoid the symptom, but since
accessing uninitialized variables is undefined behavior, we shouldn't have to
worry about that. This is only relevant in this case because we introduce the
undefined access in the first place, so that's what the patch fixes.
