https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87276
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is really a duplicate of PR86554. We're performing code-hoisting on
sum + ps->e in the following bit:
if (sum >= 0 && ps->e >= 0)
{
unsigned long uc;
uc = (unsigned long) sum + (unsigned long) ps->e;
if (uc > 9223372036854775807)
r = 2;
else
sum = 17;
}
else
sum = sum + ps->e;
Inserting expression in block 5 for code hoisting: {plus_expr,_8,sum_9} (0008)
Inserted _36 = _8 + sum_9;
in predecessor 5 (0008)
because at some point I teached value-numbering that the two expressions
compute the same value and GCC transforms if (uc > 9223372036854775807)
to if ((signed long)uc < 0).
The testcase works correctly with -fno-code-hoisting. Not sure why the
cited rev. triggers it but as seen with the other PR the underlying issue
(hoisting an expression with undefined behavior) is latent. After
code-hoisting
later VRP pass will optimize the compare (as expected), so -fno-tree-vrp also
is a workaround.
*** This bug has been marked as a duplicate of bug 86554 ***
