[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||13.2.1 --- Comment #21 from Richard Biener --- yes, it looks suspiciously close to what I'd expect.
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #20 from Mikael Pettersson --- For gcc-14 this test case was fixed by dc48d1d1d4458773f89f21b2f019f66ddf88f2e5 is the first new commit commit dc48d1d1d4458773f89f21b2f019f66ddf88f2e5 Author: Andrew MacLeod Date: Thu Aug 17 11:13:14 2023 -0400 Fix range-ops operator_addr. Lack of symbolic information prevents op1_range from beig able to draw the same conclusions as fold_range can. PR tree-optimization/111009 gcc/ * range-op.cc (operator_addr_expr::op1_range): Be more restrictive. That commit was backported to gcc-13 in 421311a31a12b96143eb901fde0e020771fe71d4, and that fixed this test case there too. Not sure if this is the proper fix or just makes the issue latent.
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #19 from rguenther at suse dot de ---
On Tue, 23 Jan 2024, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
>
> --- Comment #13 from Andrew Pinski ---
> (In reply to Yuxuan Shui from comment #12)
> > I think this is the MRE:
> >
> >
> > void bug(struct obj *dso) {
> > if (>i) {
> > if (dso == (void *)0)
> > return;
> >
> > assert_not_null(dso);
> > }
> > }
>
> Except that is undefined ...
> Manually unswitching introduces the undefined behavior in the code.
> So even though the code was unswitched before GCC 13 incorrectly, GCC didn't
> take into that account before hand.
>
> I am 99% sure what is happening is GCC is see `if (a+1)` and then assuming a
> can't be a nullptr. Which is due to undefinedness there of adding 1 to an null
> ptr ... (for C that is).
>
> Basically the unswitch is the issue ... Or we maybe we should turn `if (a+1)`
> into just `if (a)` ... Likewise for `if (>i)` into `if (a)`
It's not undefined on GIMPLE. As said I believe this was fixed for GCC 14
but appearantly not backported. bisection should tell
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 Richard Biener changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #8 from Richard Biener --- Note on trunk we have jump-threaded this to move dso == (void *)0 || dso == this out of the loop so there's nothing to unswitch and the bad circumstances likely do not trigger. I still remember the ranger bug though.
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW Priority|P3 |P2 Known to work||14.0 Summary|[13/14 Regression] |[13 Regression] |Miscompilation with -O1 |Miscompilation with -O1 |-funswitch-loops|-funswitch-loops |-fno-strict-overflow|-fno-strict-overflow CC||rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- The IL after unswitching looks OK, but we assume that when >i is NULL then dso == NULL and when >i is not NULL then dso also isn't. I think this is a ranger bug that has been fixed on trunk but eventually not yet backported, thus we have a duplicate somewhere. Bisection will tell.
