https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105337
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd say that ivopts is at fault here. Before that we have:
<bb 2> [local count: 312727306]:
<bb 3> [local count: 805306369]:
# b_14 = PHI <b_9(6), 0(2)>
# c_15 = PHI <c_7(6), c_5(D)(2)>
# ivtmp_3 = PHI <ivtmp_2(6), 3(2)>
a.0_1 = a;
if (a.0_1 == 0)
goto <bb 7>; [5.50%]
else
goto <bb 4>; [94.50%]
...
<bb 7> [local count: 44291850]:
# b_4 = PHI <b_14(3)>
<bb 5> [local count: 312727306]:
# b_10 = PHI <b_4(7), 3(8)>
return b_10;
as the path actually taken at runtime, yes, we use uninitialized c in the PHI,
but that doesn't correspond to UB at runtime.
But ivopts changes that to:
<bb 2> [local count: 312727306]:
_19 = (unsigned int) c_5(D);
_20 = _19 + 4294967293;
_21 = (int) _20;
<bb 3> [local count: 805306369]:
# c_15 = PHI <c_7(6), c_5(D)(2)>
_13 = (unsigned int) c_5(D);
_12 = (unsigned int) c_15;
_11 = -_12;
_18 = _11 + _13;
b_14 = (int) _18;
a.0_1 = a;
if (a.0_1 == 0)
goto <bb 7>; [5.50%]
else
goto <bb 4>; [94.50%]
...
<bb 7> [local count: 44291850]:
# b_4 = PHI <b_14(3)>
<bb 5> [local count: 312727306]:
# b_10 = PHI <b_4(7), 3(8)>
return b_10;
and now it uses the uninitialized value in arithmetics in the actually executed
code. And, even the return value which gets a copy of b_14 now depends on that
uninitialized value. I think we had some other PR about this...
Then comes ccp4 and figures out that many values are UNDEFINED and optimizes it
into return 3;
