public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug tree-optimization/107639] New: GCC unable to reason about range of idx/len @ 2022-11-11 15:44 jmuizelaar at mozilla dot com 2022-11-11 15:46 ` [Bug tree-optimization/107639] " jmuizelaar at mozilla dot com ` (2 more replies) 0 siblings, 3 replies; 4+ messages in thread From: jmuizelaar at mozilla dot com @ 2022-11-11 15:44 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639 Bug ID: 107639 Summary: GCC unable to reason about range of idx/len Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jmuizelaar at mozilla dot com Target Milestone: --- Clang 14 is able to optimize this function to just 'ret'. GCC 12.2 is not. #include <cstddef> void do_checks(const int* begin, const size_t len){ size_t idx = 0; const auto end = begin + len; for (const int* it = begin; it!=end; ++it, ++idx){ if (idx <= len){ // Do something useful } else { throw 5; } } } https://godbolt.org/z/f7PjjqG9T ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/107639] GCC unable to reason about range of idx/len 2022-11-11 15:44 [Bug tree-optimization/107639] New: GCC unable to reason about range of idx/len jmuizelaar at mozilla dot com @ 2022-11-11 15:46 ` jmuizelaar at mozilla dot com 2022-11-14 11:32 ` rguenth at gcc dot gnu.org 2022-11-14 14:24 ` amacleod at redhat dot com 2 siblings, 0 replies; 4+ messages in thread From: jmuizelaar at mozilla dot com @ 2022-11-11 15:46 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639 --- Comment #1 from Jeff Muizelaar <jmuizelaar at mozilla dot com> --- This test case comes from https://github.com/llvm/llvm-project/issues/56612 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/107639] GCC unable to reason about range of idx/len 2022-11-11 15:44 [Bug tree-optimization/107639] New: GCC unable to reason about range of idx/len jmuizelaar at mozilla dot com 2022-11-11 15:46 ` [Bug tree-optimization/107639] " jmuizelaar at mozilla dot com @ 2022-11-14 11:32 ` rguenth at gcc dot gnu.org 2022-11-14 14:24 ` amacleod at redhat dot com 2 siblings, 0 replies; 4+ messages in thread From: rguenth at gcc dot gnu.org @ 2022-11-14 11:32 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Keywords| |missed-optimization Blocks| |85316 Ever confirmed|0 |1 Version|unknown |13.0 Last reconfirmed| |2022-11-14 --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- Confirmed. Something for ranger/VRP "symbolic" handling. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/107639] GCC unable to reason about range of idx/len 2022-11-11 15:44 [Bug tree-optimization/107639] New: GCC unable to reason about range of idx/len jmuizelaar at mozilla dot com 2022-11-11 15:46 ` [Bug tree-optimization/107639] " jmuizelaar at mozilla dot com 2022-11-14 11:32 ` rguenth at gcc dot gnu.org @ 2022-11-14 14:24 ` amacleod at redhat dot com 2 siblings, 0 replies; 4+ messages in thread From: amacleod at redhat dot com @ 2022-11-14 14:24 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639 --- Comment #3 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Richard Biener from comment #2) > Confirmed. Something for ranger/VRP "symbolic" handling. I'm not so sure. what is related? there are 2 loop values being bumped by different amounts. the loop is controlled by the it pointer, which is bumped by 4. The only connection between len5 and idx_14 is thru the calculation of end_7, which boils down to is begin+len_5 * 4. theres no way ranger is making that connection now. The loop boils down to: <bb 2> [local count: 118111600]: _1 = (long unsigned int) len_5(D); _2 = _1 * 4; end_7 = begin_6(D) + _2; if (begin_6(D) != end_7) goto <bb 5>; [89.00%] <bb 3> [local count: 850510901]: if (len_5(D) >= idx_14) // how to know this is always true goto <bb 5>; [100.00%] else goto <bb 4>; [0.00%] <bb 5> [local count: 955630225]: # idx_17 = PHI <idx_14(3), 0(5)> # it_18 = PHI <it_13(3), begin_6(D)(5)> it_13 = it_18 + 4; idx_14 = idx_17 + 1; if (end_7 != it_13) goto <bb 3>; [89.00%] else goto <bb 6>; [11.00%] This seems more like a loop thing. both values are being bumped by the loop, and the end condition is based on a calculation using len_5.. it seems like it should now the bounds of both ir and idx? or maybe it does and cant communicate it any more? ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-11-14 14:24 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-11-11 15:44 [Bug tree-optimization/107639] New: GCC unable to reason about range of idx/len jmuizelaar at mozilla dot com 2022-11-11 15:46 ` [Bug tree-optimization/107639] " jmuizelaar at mozilla dot com 2022-11-14 11:32 ` rguenth at gcc dot gnu.org 2022-11-14 14:24 ` amacleod at redhat dot com
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).