[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114 Richard Biener changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #7 from Richard Biener --- Based on that, closing as invalid.
[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-12-22
--- Comment #6 from Richard Biener ---
Confirmed for the diagnostics. But note the loop in question is basically
for (a = 1; a != 0; a++)
so it iterates until we wrap to zero (a is 'short', the increment is in
'int' due to promotion so short wrap doesn't invoke undefined overflow).
That means the loop iterates >65000 times which means the repeated add
of 264487869 overflows.
At the point we emit this diagnostic this will always happen so the
diagnostic is correct?
We do fail to optimize if ((c += 264487869) == 9) though, but likely
because VRP no longer iterates. c starts from 1 and we only add positive
numbers the range for it should be [1, +INF]. The entry to the line:
tail loop has this optimized and the add removed as dead code. That's
what possibly happened before - we optimized this branch and thus DCEd
the add?
Anyhow, on x86_64 we mangle the whole thing a bit more than on arc-elf.
Huh, it looks like arc-elf disables GIMPLE loop optimizers. I can reproduce
the diagnostic on x86_64 with -fno-tree-loop-optimize.
gcc/common/config/arc/arc-common.cc has
{ OPT_LEVELS_SIZE, OPT_ftree_loop_optimize, NULL, 0},
for whatever reason. -ftree-loop-optimize "fixes" the diagnostic.
But as said, I think the diagnostic is correct.
[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114 Richard Biener changed: What|Removed |Added Priority|P4 |P3 Keywords||missed-optimization Target Milestone|--- |13.0 --- Comment #5 from Richard Biener --- (In reply to Jeffrey A. Law from comment #4) > I'll double check, but IIRC we throw away the loop structures at the end of > DOM and they're supposed to be rebuilt (which appears to be happening as we > re-construct LCSSA). If you elide a loop it gets removed by fixup but we never fully re-build loops. Eliding a loop might have removed a stmt based on which undefined behavior on overflow we could have derived an upper bound for the outer loop. But you really have to sit down and see why we are no longer deriving number of iterations [upper bound].
[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114 --- Comment #4 from Jeffrey A. Law --- I'll double check, but IIRC we throw away the loop structures at the end of DOM and they're supposed to be rebuilt (which appears to be happening as we re-construct LCSSA).
[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114 --- Comment #3 from Andrew Macleod --- yeah, we just invoke the loop analyzer and pick up what it tells us. From VRP2 point of view, it is just not getting the info supplied from the loop optimizer. I see dom3 removes some code and I see < fix_loop_structure: removing loop 5 any chance it doesn't fix it up right somehow?
[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114 --- Comment #2 from Jeffrey A. Law --- Which is just uber-weird. The change in question removes a little subloop which becomes unreachable. Why that would cause us to be unable to analyze the remaining key loop for the IV's range is a complete mystery. Though I guess I'll have to sit down and debug that a bit. VRP is just calling into the loop optimizer to to the IV analysis, right? WRT the new blocks -- I strongly suspect they're part of normalization of the loop and putting it into LCSSA form. I'm not terribly worried about them. Typically they're just going to be creating empty loop latches.
[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114 --- Comment #1 from Andrew Macleod --- Looks like something in the change is causing the loop analysis to not be able to count the iterations. > Analyzing # of iterations of loop 1 > exit condition [1, + , 1] != 0 > bounds on difference of bases: -1 ... -1 > result: > # of iterations 65535, bounded by 65535 109,110d68before this change, loop analysis decided the range of _26 as a_lsm.14_26: [irange] short int [1, 9] NONZERO 0xf a afterwards, it doesn't even seem to see the loop. IN fact, before LCSSA creates a whole bunch of new blocks too. < ;; Created LCSSA PHI: a_lsm.14_15 = PHI < ;; Created LCSSA PHI: a_lsm_flag.15_16 = PHI < ;; Created LCSSA PHI: d_47 = PHI < < Updating SSA: < Registering new PHI nodes in block #13 < Updating SSA information for statement if (a_lsm.14_26 != 0) < Registering new PHI nodes in block #6 < Registering new PHI nodes in block #12 < Updating SSA information for statement a.9_9 = (unsigned short) a_lsm.14_26; < Registering new PHI nodes in block #16 < Registering new PHI nodes in block #7 < Registering new PHI nodes in block #8 < Updating SSA information for statement if (d_13 != 0B) < Registering new PHI nodes in block #9 < Updating SSA information for statement if (a_lsm_flag.15_28 != 0) < Registering new PHI nodes in block #10 < Updating SSA information for statement a = a_lsm.14_26; < Registering new PHI nodes in block #11 < Registering new PHI nodes in block #19 < Registering new PHI nodes in block #15
[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at gcc dot gnu.org
