[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:d1f4dfd409dedf4d00ca7be001cf757d0d6e82f4 commit r11-9688-gd1f4dfd409dedf4d00ca7be001cf757d0d6e82f4 Author: Richard Biener Date: Wed Mar 16 14:53:06 2022 +0100 tree-optimization/104931 - mitigate niter analysis issue The following backports a pointer associating pattern from trunk that mitigates an issue with number_of_iterations_lt_to_ne in which context we fail to fold a comparison but succeed in folding a related subtraction. In the failure mode this results in a loop wrongly assumed looping with a bogus number of iterations, resulting in crashing of the premake application on start. With the backported simplification we are able to fold the comparison and correctly compute the loop as not iterating. I have failed to create a standalone testcase. I belive part of the issue is still latent but I have failed to nail down the issue exactly. Still I believe the backporting of the mitigation patch is the most sensible and safe thing at this point. 2022-03-16 Richard Biener PR tree-optimization/104931 * match.pd ((ptr) (x p+ y) p+ z -> (ptr) (x p+ (y + z))): New GENERIC simplification.
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #10 from Richard Biener --- The bug also shows in a -flto-partition=max build where the offending function ends up in ltrans unit 23 (and only this function) which might enable side-by-side debugging if desired.
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #9 from Richard Biener --- Created attachment 52646 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52646=edit ivcanon dump from the GIMPLE testcase (without bug) The difference is that with LTO we have expanded expressions to Analyzing # of iterations of loop 1 exit condition [(struct TValue *) (_2 + 4294967272) + 12, + , 24](no_overflow) < _2 + 4294967272 while with the GIMPLE testcase we immediately get to Statement (exit)if (from_26 < to_27) is executed at most 0 (bounded by 0) + 1 times in loop 1. ... Loop 1 iterates 0 times. Note the GIMPLE FE doesn't yet support parsing CLOBBER stmts (but I'm quite sure this doesn't matter here) and for the loops() support you need to commit a pending patch.
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #8 from Richard Biener --- Created attachment 52645 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52645=edit ivcanon dump as seen from LTO (with bug)
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #7 from Richard Biener --- Created attachment 52644 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52644=edit GIMPLE testcase This is a GIMPLE testcase created from the cddce2 IL of the respective ltrans unit from trunk with the match.pd hunk reverted. It does not exhibit the bug. The reason is likely different pre-caching in SCEV and/or niter estimates.
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #6 from Richard Biener --- Also confirmed the issue still happens on trunk when we revert this match.pd pattern.
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 Richard Biener changed: What|Removed |Added Summary|wrong-code with |[9/10/11 Regression] |number_of_iterations_lt_to_ |wrong-code with |ne |number_of_iterations_lt_to_ ||ne Priority|P3 |P2 Target Milestone|--- |9.5 Known to fail||9.3.1 Known to work||7.5.0 --- Comment #5 from Richard Biener --- Verified the issue also happens with GCC 9, it doesn't happen with GCC 7.
