https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #4 from Mikael Morin ---
For what's worth adding -fno-tree-vrp "fixes" this and enables removal of the
call to 'foo' with trunk.
Here is a minimal revert of the regressing revision, but it may just make the
problem latent.
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #2 from Andrew Macleod ---
It seems like we set 'e' to 3 immediately at the start:
[local count: 1073741824]:
e = 3;
goto ; [100.00%]
and it is never changed again. However, when we load from 'e' later in the IL
[local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #1 from Andrew Pinski ---
The difference is the trunk can figure out the range for j_8:
PHI GROUP query for j_8 found : [irange] int [1, 1][8, 8] and adjusted original
range from :[irange] int [1, 1][8, 8] to :[irange] int [1, 1][8,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target
