[Bug fortran/110311] New: [gfortran 14.0 regression]

[Bug fortran/110311] New: [gfortran 14.0 regression]

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

            Bug ID: 110311
           Summary: [gfortran 14.0 regression]
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Hi,
let me open up an issue already. I believe there was a regression introduced in
gfortran between June 11 and June 19, as our CI with a git-clone built
gcc/gfortran worked last week, and fails this week. Two out of our ca. 340
functional tests fail because they return zero results. I will try to boil this
down to a smaller reproducer (fingers crossed), but if you want to play around
already, checkout our code from here:
https://gitlab.tp.nt.uni-siegen.de/whizard/public
Note that you need noweb and OCaml besides gcc/gfortran. Do in the main
directory ./build_master.sh and autoreconf, then in a build directory _build 
do ../configure, make -j4, make -C tests/functional_tests -j4 check.
The failing tests are nlo_9.run and nlo_10.run in case you want to run them
already now.
Cheers,
 Juergen

[Bug fortran/110311] [gfortran 14.0 regression]

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #1 from Jürgen Reuter <juergen.reuter at desy dot de> ---
It looks like there were no specific changes in the fortran backend or the
libgfortran but a lot of optimization in the middle-end. Maybe that is
responsible for this issue. Need to see what is going on.

[Bug fortran/110311] [gfortran 14.0 regression]

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

Jürgen Reuter <juergen.reuter at desy dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #2 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Actually, it could have been this commit here:
2023-06-13  Harald Anlauf  <anlauf@gmx.de>
            Mikael Morin  <mikael@gcc.gnu.org>

        PR fortran/86277
        * trans-array.cc (gfc_trans_allocate_array_storage): When passing a
        zero-sized array with fixed (= non-dynamic) size, allocate temporary
        by the caller, not by the callee.

[Bug fortran/110311] [14 Regression] gfortran 14.0 regression

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
            Summary|[gfortran 14.0 regression]  |[14 Regression] gfortran
                   |                            |14.0 regression

[Bug fortran/110311] [14 Regression] gfortran 14.0 regression

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #3 from Jürgen Reuter <juergen.reuter at desy dot de> ---
I redid this change here:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index
e1c75e9fe0266d760b635f0dc7869a00ce53bf48..e7c51bae052b1e0e3a60dee35484c093d28d4653
100644 (file)
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,

   desc = info->descriptor;
   info->offset = gfc_index_zero_node;
-  if (size == NULL_TREE || integer_zerop (size))
+  if (size == NULL_TREE || (dynamic && integer_zerop (size)))
     {
       /* A callee allocated array.  */
       gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);

and it seems this is not the cause of the problem :(

[Bug fortran/110311] [14 Regression] gfortran 14.0 regression

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
Jürgen,

I'm afraid we need a reproducer.  Or can you bisect the regression further?

[Bug fortran/110311] [14 Regression] gfortran 14.0 regression

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #5 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to anlauf from comment #4)
> Jürgen,
> 
> I'm afraid we need a reproducer.  Or can you bisect the regression further?

In principle, I could. But I just undid this commit of yours which is just one
line in trans-array.cc, and that didn't solve the problem. So in the
corresponding period of time between last Monday (June 12) and this week (June
19) there have not been any other commits to gcc/fortran or libgfortran, as far
as I can say. So this seems to be a problem with tree-optimization, maybe.

[Bug fortran/110311] [14 Regression] gfortran 14.0 regression

[manolis.tsamis at vrull dot eu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

manolis.tsamis at vrull dot eu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manolis.tsamis at vrull dot eu

--- Comment #6 from manolis.tsamis at vrull dot eu ---
Hi,

Due to the time frame mentioned (June 12-19), could you please test if the
offending commit is r14-1873-g6a2e8dcbbd4bab374b27abea375bf7a921047800 ? This
commit is now known to cause general issues, as also described in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308.

Thanks,
Manolis

[Bug fortran/110311] [14 Regression] gfortran 14.0 regression

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #7 from Jürgen Reuter <juergen.reuter at desy dot de> ---
The problem seems really connected to optimization, if I compile our code with
-g -O0 or -g -O1, everything works ok. Next, I will try to check why it is
actually failing (my guess, unconfirmed yet, is that some data structures are
optimized away such that the program runs then on inconsistent data). Then I
will check that specific commit. We are sure that it was introduced within this
time frame, because we have a weekly CI that clones gcc, and then builds and
runs our code and testsuite. That was working on the morning of June 12, but
failed on the morning of June 19.

[Bug fortran/110311] [14 Regression] gfortran 14.0 regression

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jürgen Reuter from comment #7)
> The problem seems really connected to optimization, if I compile our code
> with -g -O0 or -g -O1, everything works ok. Next, I will try to check why it
> is actually failing (my guess, unconfirmed yet, is that some data structures
> are optimized away such that the program runs then on inconsistent data).
> Then I will check that specific commit. We are sure that it was introduced
> within this time frame, because we have a weekly CI that clones gcc, and
> then builds and runs our code and testsuite. That was working on the morning
> of June 12, but failed on the morning of June 19.

Do you know if -fno-tree-vectorizer causes the issue to go away?

[Bug fortran/110311] [14 Regression] gfortran 14.0 regression

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #9 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Jürgen Reuter from comment #7)
> > The problem seems really connected to optimization, if I compile our code
> > with -g -O0 or -g -O1, everything works ok. Next, I will try to check why it
> > is actually failing (my guess, unconfirmed yet, is that some data structures
> > are optimized away such that the program runs then on inconsistent data).
> > Then I will check that specific commit. We are sure that it was introduced
> > within this time frame, because we have a weekly CI that clones gcc, and
> > then builds and runs our code and testsuite. That was working on the morning
> > of June 12, but failed on the morning of June 19.
> 
> Do you know if -fno-tree-vectorizer causes the issue to go away?

Hi Andrew,
you were right. Compiling and running with -fno-tree-vectorize does not show
any issues. All our checks work without problems.
Cheers,
   Juergen

[Bug fortran/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #10 from Jürgen Reuter <juergen.reuter at desy dot de> ---
*** Bug 110326 has been marked as a duplicate of this bug. ***

[Bug fortran/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

Jürgen Reuter <juergen.reuter at desy dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |fortran
           Keywords|wrong-code                  |
             Target|x86_64-linux-gnu            |

--- Comment #11 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to manolis.tsamis from comment #6)
> Hi,
> 
> Due to the time frame mentioned (June 12-19), could you please test if the
> offending commit is r14-1873-g6a2e8dcbbd4bab374b27abea375bf7a921047800 ?
> This commit is now known to cause general issues, as also described in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308.
> 
> Thanks,
> Manolis

Unfortunately, this is not the problematic commit, the problem is still there
when reverting this commit.

[Bug fortran/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #12 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Any idea which commit could cause such an issue? At least I now understand that
in our program the random number object gets undefined and produces NaNs.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #13 from Jürgen Reuter <juergen.reuter at desy dot de> ---
I changed the component from fortran to tree-optimization, as the problematic
commit during that week was in that component. The only commit in the fortran
component turns out to be unproblematic.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #14 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Did anybody manage to reproduce this? 
Download https://whizard.hepforge.org/downloads/?f=whizard-3.1.2.tar.gz
You need OCaml as a prerequisite, though.
Then configure, make, 
cd tests/functional_tests
make check TESTS=nlo_9.run
This will fail, as there are NaNs produced in our RNG module which are
presumably caused by this regression in the tree-optimizer. At the moment I am
deeply struggling with generating a reproducer but I don't know how tbh.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|anlauf at gmx dot de               |

--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #14)
> Did anybody manage to reproduce this? 
> Download https://whizard.hepforge.org/downloads/?f=whizard-3.1.2.tar.gz
> You need OCaml as a prerequisite, though.
> Then configure, make, 
> cd tests/functional_tests
> make check TESTS=nlo_9.run
> This will fail, as there are NaNs produced in our RNG module which are
> presumably caused by this regression in the tree-optimizer. At the moment I
> am deeply struggling with generating a reproducer but I don't know how tbh.

I may be telling you the obvious, but here's what I do in cases where changes
in optimization in new compilers cause failures and recompiling is expensive:

- create standalone-version of Fortran code and testcase
- have two build trees in parallel, (a) working and (b) failing
- relink by successively replacing objects in (a) by those from (b)
- run each binary until the failure occurs

In your case you are lucky in that you get a crash.

If testing is expensive, it may be worth to do bisecting on sets of objects.

I avoid building of shared libs for the project to ease testing.

Note: there might be multiple bad objects.

This works for me even with $$$$ compilers on $$$$ platforms, even if that
takes a day or two.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #16 from Jürgen Reuter <juergen.reuter at desy dot de> ---
It seems that it is this function where the NaNs appear:
  function mult_mod (a, b, c, m) result (v)
    real(default), intent(in) :: a
    real(default), intent(in) :: b
    real(default), intent(in) :: c
    real(default), intent(in) :: m
    real(default) :: v
    integer :: a1
    real(default) :: a2
    v = a * b + c
    if (v >= two53 .or. v <= -two53) then
       a1 = int (a / two17)
       a2 = a - a1 * two17
       v = mod (a1 * b, m)
       v = v * two17 + a2 * b + c
    end if
    v = mod (v, m)
    if (v < 0.0_default) v = v + m
  end function mult_mod

particularly mod (v, m) gets evaluated to NaN, even if a replace it with
v = mod (v0, m) to avoid potential aliasing problems. It appears only in a very
complex setup, not in a 100 line program.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #17 from Jürgen Reuter <juergen.reuter at desy dot de> ---
How would I set up such a bisection for the n git commits between June 12 to
June 19? Unfortunately, I cannot really get a small reproducer ....

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #18 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #17)
> How would I set up such a bisection for the n git commits between June 12 to
> June 19? Unfortunately, I cannot really get a small reproducer ....

I didn't mean that.  I meant doing a bisection on the .o files of your code.

But given that you have isolated a procedure, that is not necessary.

You could try to defeat optimization by using a temporary v0 for v and
declare it as volatile.  Would be interesting to see if that makes a
difference.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #19 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to anlauf from comment #18)
> (In reply to Jürgen Reuter from comment #17)
> > How would I set up such a bisection for the n git commits between June 12 to
> > June 19? Unfortunately, I cannot really get a small reproducer ....
> 
> I didn't mean that.  I meant doing a bisection on the .o files of your code.
> 
> But given that you have isolated a procedure, that is not necessary.
> 
> You could try to defeat optimization by using a temporary v0 for v and
> declare it as volatile.  Would be interesting to see if that makes a
> difference.

I tried both things, or at least partially, didn't help. It also is a problem
only when called in a very complicated setup in our program, in complicated
setups, it works. I fear, we have to change the functionality in our program,
sadly, if we are not to be stuck for all times to version of gcc < 14.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #20 from anlauf at gcc dot gnu.org ---
If that doesn't help: there appear to be recent optimizations for divmod.
Try declaring a1, a2 as volatile.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #21 from anlauf at gcc dot gnu.org ---
I forgot to mention that you need to check that the location where a symptom
is seen sometimes may not be the location of the cause.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #22 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to anlauf from comment #21)
> I forgot to mention that you need to check that the location where a symptom
> is seen sometimes may not be the location of the cause.

Indeed, I think you are right and the problem is elsewhere. I don't really know
where to continue.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #23 from anlauf at gcc dot gnu.org ---
You could check the input arguments for validity, e.g. using ieee_is_finite
from the intrinsic ieee_arithmetic module.

  use, intrinsic :: ieee_arithmetic, only: ieee_is_finite

...

  if (.not. ieee_is_finite (a)) then
     print *, "bad: a=", a
     stop 1
  end if

As last resort I still recommend what I wrote in comment#15: build (=link)
your executable from *.o from your project build tree with known-good objects
but replacing one candidate.o by the one from the build tree showing the
problem.

And I really mean: link only und run.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #24 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Here is a first reproducer without the need for OCaml, unfortunately a bit too
big to be uploaded, here is the link:
https://www.desy.de/~reuter/downloads/repro001.tar.xz
the tarball contains Fortran files that compile to two binaries, ./whizard and
./whizard_check.
After compilation, perform ./whizard r1.sin 
to run the program. There will be NaNs generated in our RNG stream random
number generator. They originate from an erroneous optimization by the
gcc/gfortran tree-optimizer. This code resides in rng_stream_sub.f90, in the
function mult_mod. Eliminating the intrinsic function mod and explicitly doing
the calculation makes the problem go away.
  function mult_mod (a, b, c, m) result (v)
    real(default), intent(in) :: a
    real(default), intent(in) :: b
    real(default), intent(in) :: c
    real(default), intent(in) :: m
    real(default) :: v
    integer :: a1
    real(default) :: a2
    v = a * b + c
    if (v >= two53 .or. v <= -two53) then
       a1 = int (a / two17)
       a2 = a - a1 * two17
       v = mmm_mod (a1 * b, m)
       v = v * two17 + a2 * b + c
    end if
    v = mmm_mod (v, m)
    if (v < 0.0_default) v = v + m
  contains
    elemental function mmm_mod (x1, x2) result (res)
      real(default), intent(in) :: x1, x2
      real(default) :: res
      res = x1 - int(x1/x2) * x2
    end function mmm_mod
  end function mult_mod

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #25 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #24)
> Here is a first reproducer without the need for OCaml, unfortunately a bit
> too big to be uploaded, here is the link:
> https://www.desy.de/~reuter/downloads/repro001.tar.xz
> the tarball contains Fortran files that compile to two binaries, ./whizard
> and ./whizard_check.

Unfortunately, there is no main.f90, which is needed to build whizard.

The Makefile needs to be modified to take into account that pythia.f
needs preprocessing, e.g.:

%.o: %.f
        $(FC) $(FCFLAGS) -c $< -cpp

Furthermore, one needs to compile serially; parallel make does not seem to
be supported.

Can you please provide the missing file?

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #26 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to anlauf from comment #25)

> Unfortunately, there is no main.f90, which is needed to build whizard.
>

Indeed, sorry, cf. below

> The Makefile needs to be modified to take into account that pythia.f
> needs preprocessing, e.g.:
> 
> %.o: %.f
> 	$(FC) $(FCFLAGS) -c $< -cpp
> 
> Furthermore, one needs to compile serially; parallel make does not seem to
> be supported.

I changed the pythia.f to make the preprocessing unnecessary.

> 
> Can you please provide the missing file?

It is included here:
https://www.desy.de/~reuter/downloads/repro002.tar.xz
I am working on a smaller example right now.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #27 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #26)
> It is included here:
> https://www.desy.de/~reuter/downloads/repro002.tar.xz
> I am working on a smaller example right now.

Good.  I can reproduce the failure, but here's what others need to know:

- I have to

rm -f nlo_9_p2.i1.phs nlo_9_p2.m1.vg2

  each time *before* running the test. ???

- I am using the modification to rng_stream_sub.f90 from comment#24 with the
  printout added

- I am switching between

      res = mod (x1, x2)

and
      res = x1 - int(x1/x2) * x2

- I am disabling optimization completely for this file and added to Makefile:

rng_stream_sub.o: rng_stream_sub.f90
        $(FC) $(FCFLAGS) -c $< -O0 -fdump-tree-original -fdump-tree-optimized


which gives (v1 is with intrinsic mod, v2 is with explicitly coded mod):

--- rng_stream_sub.f90.005t.original.v1 2023-06-29 20:44:58.148284991 +0200
+++ rng_stream_sub.f90.005t.original.v2 2023-06-29 20:45:45.408160849 +0200
@@ -3,7 +3,7 @@
 {
   real(kind=8) res;

-  res = __builtin_fmod (*x1, *x2);
+  res = *x1 - (real(kind=8)) (integer(kind=4)) (*x1 / *x2) * *x2;
   return res;
 }

as expected.  The dump-tree-optimized looks unsuspicious to me.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #28 from anlauf at gcc dot gnu.org ---
Update: recompiling that file with 13-branch fails for me, too.
Playing with the one-line patch for pr86277 makes no difference, fortunately.

Compiling the file with gfortran-12 seems to work ok.

So is this really a 14-only regression, or is 13-branch already suspicious?

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #29 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to anlauf from comment #28)
> Update: recompiling that file with 13-branch fails for me, too.
> Playing with the one-line patch for pr86277 makes no difference, fortunately.
> 
> Compiling the file with gfortran-12 seems to work ok.
> 
> So is this really a 14-only regression, or is 13-branch already suspicious?

We have gcc 13.1 in our CI, everything works fine there. I am still working on
a smaller test, but have very bad connection rn.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #30 from anlauf at gcc dot gnu.org ---
BTW: you can get a traceback on FP exceptions by adding to the linker options:

 -ffpe-trap=zero,overflow,invalid

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #31 from anlauf at gcc dot gnu.org ---
Looking at rng_stream_sub.o with objdump, I see fprem generated for 13 & 14,
but not for 12.

I haven't yet found an option to suppress its generation and fall back to
the behavior of 12-branch.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uros at gcc dot gnu.org

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Then maybe r13-6361-g8020c9c42349f51f75239b
is the commit that changed it?
Would be good to put a breakpoint at that instruction and see in which
iteration it results in NaN and what operands it had...

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #33 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #32)
> Then maybe r13-6361-g8020c9c42349f51f75239b
> is the commit that changed it?
> Would be good to put a breakpoint at that instruction and see in which
> iteration it results in NaN and what operands it had...

Program received signal SIGFPE, Arithmetic exception.
0x0000000000678f1a in rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
x2=4294967087) at rng_stream_sub.f90:336
336         res = mod (x1, x2)
(gdb) p x1
$1 = 330289839997
(gdb) p x2
$2 = 4294967087

Strangely enough, a small testcase with these arguments does not fail...

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #34 from anlauf at gcc dot gnu.org ---
A few more data points:

reverting r13-6361-g8020c9c42349f51f75239b on 13-branch fixes the issue:
no fprem generated, no FPE.

Adding -ffinite-math-only to the modified 13-branch restores the FPE.

Compiling the affected module (only) with 12-branch and linking everything
with 14-mainline shows the same: fprem is used only with -ffinite-math-only,
and I get an FPE even with 12-branch in that case.

Same with 11-branch.

I am still not sure why it cannot be reproduced with a smaller example,
thus I hope that Jürgen can provide a significantly smaller reproducer.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #35 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to anlauf from comment #33)
> (In reply to Jakub Jelinek from comment #32)
> > Then maybe r13-6361-g8020c9c42349f51f75239b
> > is the commit that changed it?
> > Would be good to put a breakpoint at that instruction and see in which
> > iteration it results in NaN and what operands it had...
> 
> Program received signal SIGFPE, Arithmetic exception.
> 0x0000000000678f1a in rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
> x2=4294967087) at rng_stream_sub.f90:336
> 336         res = mod (x1, x2)
> (gdb) p x1
> $1 = 330289839997
> (gdb) p x2
> $2 = 4294967087
> 
> Strangely enough, a small testcase with these arguments does not fail...

Please show the FP registers (and coprocessor state, 'info float') just before
the FPREM instruction. These two values (as shown) are nothing special, but
perhaps FP register value contains something that FPREM does not like. Also,
please show the state after FPREM is executed. Please note that FPREM is
performed in the loop, so perhaps a couple of trips through the loop will be
needed.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #36 from anlauf at gcc dot gnu.org ---
Breakpoint 2, rng_stream.rng_stream_s::mmm_mod (x1=330289839997, x2=4294967087)
at rng_stream_sub.f90:336
336         res = mod (x1, x2)
(gdb) info float
  R7: Valid   0x401be51fb57800000000 +480507567                 
  R6: Valid   0x401be51fb57800000000 +480507567                 
  R5: Zero    0x00000000000000000000 +0                         
  R4: Zero    0x00000000000000000000 +0                         
  R3: Zero    0x00000000000000000000 +0                         
  R2: Zero    0x00000000000000000000 +0                         
  R1: Zero    0x00000000000000000000 +0                         
=>R0: Special 0xffff0000000004f5dc90 Unsupported

Status Word:         0x0000                                            
                       TOP: 0
Control Word:        0x0372      DM       UM PM
                       PC: Extended Precision (64-bits)
                       RC: Round to nearest
Tag Word:            0x0556
Instruction Pointer: 0x00:0x00000000
Operand Pointer:     0x00:0x00000000
Opcode:              0x0000
(gdb) n

Program received signal SIGFPE, Arithmetic exception.
0x0000000000678e6a in rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
x2=4294967087) at rng_stream_sub.f90:336
336         res = mod (x1, x2)

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #37 from anlauf at gcc dot gnu.org ---
After the FPE:

(gdb) info float
  R7: Valid   0x401be51fb57800000000 +480507567                 
  R6: Valid   0x401be51fb57800000000 +480507567                 
  R5: Zero    0x00000000000000000000 +0                         
  R4: Zero    0x00000000000000000000 +0                         
  R3: Zero    0x00000000000000000000 +0                         
  R2: Zero    0x00000000000000000000 +0                         
  R1: Zero    0x00000000000000000000 +0                         
=>R0: Special 0xffff0000000004f5dc90 Unsupported

Status Word:         0x82c1   IE                  ES   SF      C1      
                       TOP: 0
Control Word:        0x0372      DM       UM PM
                       PC: Extended Precision (64-bits)
                       RC: Round to nearest
Tag Word:            0x0556
Instruction Pointer: 0x00:0x004031d2
Operand Pointer:     0x00:0x011b5708
Opcode:              0xdd45

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #38 from Jürgen Reuter <juergen.reuter at desy dot de> ---
At the moment unfortunately too busy to provide a smaller reproducer (which
also still has a small dependency on a dynamic library), but one more info:
inserting the explicit operations instead of the intrinsic mod function leads
to no more NaNs with the gfortran 14, but still is numerically different from
the one with previous gfortran versions: so it looks like it leads to a
different random number sequence which is really disturbing.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #39 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to anlauf from comment #36)
> Breakpoint 2, rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
> x2=4294967087) at rng_stream_sub.f90:336
> 336         res = mod (x1, x2)
> (gdb) info float
>   R7: Valid   0x401be51fb57800000000 +480507567                 
>   R6: Valid   0x401be51fb57800000000 +480507567                 
>   R5: Zero    0x00000000000000000000 +0                         
>   R4: Zero    0x00000000000000000000 +0                         
>   R3: Zero    0x00000000000000000000 +0                         
>   R2: Zero    0x00000000000000000000 +0                         
>   R1: Zero    0x00000000000000000000 +0                         
> =>R0: Special 0xffff0000000004f5dc90 Unsupported

Here is the problem. FPREM chokes on invalid input in R0.

[1] Says that IA (invalid arithmetic) exception is generated for unsupported
format, and this is what happened above:

#IA     Source operand is an SNaN value, modulus is 0, dividend is ∞, or
unsupported format.

[1] https://www.felixcloutier.com/x86/fprem

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #40 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #38)
> At the moment unfortunately too busy to provide a smaller reproducer (which
> also still has a small dependency on a dynamic library),

I have just commented out the references to dlopen, dlclose, dlsym, dlerror
in os_interface_sub.f90, removed the -ldl and can still reproduce the failure.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #39)
> (In reply to anlauf from comment #36)
> > Breakpoint 2, rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
> > x2=4294967087) at rng_stream_sub.f90:336
> > 336         res = mod (x1, x2)
> > (gdb) info float
> >   R7: Valid   0x401be51fb57800000000 +480507567                 
> >   R6: Valid   0x401be51fb57800000000 +480507567                 
> >   R5: Zero    0x00000000000000000000 +0                         
> >   R4: Zero    0x00000000000000000000 +0                         
> >   R3: Zero    0x00000000000000000000 +0                         
> >   R2: Zero    0x00000000000000000000 +0                         
> >   R1: Zero    0x00000000000000000000 +0                         
> > =>R0: Special 0xffff0000000004f5dc90 Unsupported

0xffff0000000004f5dc90 is pseudo NaN:
Pseudo Not a Number. The sign bit is meaningless. The 8087 and 80287 treat this
as a Signaling Not a Number. The 80387 and later treat this as an invalid
operand.
So, if that comes from some random number generator, I'd say that random number
generator should be fixed not to create the erroneous cases for
https://en.wikipedia.org/wiki/Extended_precision

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #42 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Jakub Jelinek from comment #41)
> 
> 0xffff0000000004f5dc90 is pseudo NaN:
> Pseudo Not a Number. The sign bit is meaningless. The 8087 and 80287 treat
> this as a Signaling Not a Number. The 80387 and later treat this as an
> invalid operand.
> So, if that comes from some random number generator, I'd say that random
> number generator should be fixed not to create the erroneous cases for
> https://en.wikipedia.org/wiki/Extended_precision

Hm, the example provided does not use extended precision.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #43 from anlauf at gcc dot gnu.org ---
Mabye the fprem issue was a red herring from the beginning, pointing to a
problem in a different place.

I recompiled each module in a loop with -O0 until the FPE went away.

instances_sub.f90 seems the file someone wants to look at.

Works at -O0, -O1, -Os, -O2 -fno-tree-vectorize
Fails at -O2, -O3

on x86_64-pc-linux-gnu.

Jürgen: can you reduce this even more with this information?

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #44 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to anlauf from comment #43)
> Mabye the fprem issue was a red herring from the beginning, pointing to a
> problem in a different place.
> 
> I recompiled each module in a loop with -O0 until the FPE went away.
> 
> instances_sub.f90 seems the file someone wants to look at.
> 
> Works at -O0, -O1, -Os, -O2 -fno-tree-vectorize
> Fails at -O2, -O3
> 
> on x86_64-pc-linux-gnu.
> 
> Jürgen: can you reduce this even more with this information?

Thanks, this info is helpful. So it is the setting up of the full process via
the instances module, which is in agreement with the fact that the simple test
with only the RNG did not fail. I will be busy for several days, but hopefully
in a week from now, I'll know more.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #45 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 55492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55492&action=edit
Smaller stand-alone reproducer

I will give more information in a comment, this contains 3 files and a
Makefile.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #46 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Jürgen Reuter from comment #45)
> Created attachment 55492 [details]
> Smaller stand-alone reproducer
> 
> I will give more information in a comment, this contains 3 files and a
> Makefile.

This is a standalone reproducer with a total of 8k lines. It needs to be in
three different files, as fusing the 2nd and 3rd file eliminates the optimizer
problem of this issue, while fusing the 1st and the 2nd leeds to an ICE in
trans-array.c (reported separately) and is independent of this problem here.
The issue goes away with -O0, with -O1 and with -O2 -fno-tree-vectorize. 
I might want to find the offending commit in the week of June 12-19 in the
tree-optimizer, but I don't know whether I have time to do so. Hopefully, with
this 
smaller reproducer you can figure out what happens (and help solving it)

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #47 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #46)
> The issue goes away with -O0, with -O1 and with -O2 -fno-tree-vectorize. 
> I might want to find the offending commit in the week of June 12-19 in the
> tree-optimizer, but I don't know whether I have time to do so. Hopefully,
> with this 
> smaller reproducer you can figure out what happens (and help solving it)

I recommend adding -ffpe-trap=zero,overflow,invalid to the flags.

It is code2.f90 that is sensible to -ftree-vectorize; the two other files
can be compiled even with -O3.

However, when I use -O2 together with an -march= flag, the code works.
I've tested -march=sandybridge, -march=haswell, -march=skylake, -march=native.
It FPEs without.

Do you see the same?

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #48 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #47)
> However, when I use -O2 together with an -march= flag, the code works.
> I've tested -march=sandybridge, -march=haswell, -march=skylake,
> -march=native.
> It FPEs without.

And it FPEs with core2,nehalem,westmere!

Next I tried:

-march=sandybridge -mno-avx  # FPE!
-march=sandybridge           # OK.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #49 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to anlauf from comment #48)
> (In reply to anlauf from comment #47)
> > However, when I use -O2 together with an -march= flag, the code works.
> > I've tested -march=sandybridge, -march=haswell, -march=skylake,
> > -march=native.
> > It FPEs without.
> 
> And it FPEs with core2,nehalem,westmere!
> 
> Next I tried:
> 
> -march=sandybridge -mno-avx  # FPE!
> -march=sandybridge           # OK.

Yes, I can fully confirm your findings, also the ones from comment #47. I was
looking at the commits in the period June 12-18 which could have caused this,
some which seem potential candidates are:
2023-06-18  Honza  <jh@ryzen3.suse.cz>
        PR tree-optimization/109849
2023-06-16  Jakub Jelinek  <jakub@redhat.com>
        PR tree-optimization/110271
        * tree-ssa-math-opts.cc (math_opts_dom_walker::after_dom_children)
        <case PLUS_EXPR>: Ignore return value from match_arith_overflow,
        instead call match_uaddc_usubc only if gsi_stmt (gsi) is still stmt.
(This one sounds pretty suspicious to me)
2023-06-16  Richard Biener  <rguenther@suse.de>
        PR tree-optimization/110269
        * fold-const.cc (fold_binary_loc): Merge x != 0 folding
2023-06-13  Alexandre Oliva  <oliva@adacore.com>
        * range-op-float.cc (frange_nextafter): Drop inline.
        (frelop_early_resolve): Add static.
        (frange_float): Likewise
2023-06-12  Andrew MacLeod  <amacleod@redhat.com>
        PR tree-optimization/110205
        * range-op-float.cc (range_operator::fold_range): Add default FII
        fold routine.
        * range-op-mixed.h (class operator_gt): Add missing final overrides.
        * range-op.cc (range_op_handler::fold_range): Add RO_FII case.
2023-06-12  Andrew MacLeod  <amacleod@redhat.com>
        * gimple-range-gori.cc (gori_compute::condexpr_adjust): Do not
        pass type.
        [...]
(there is a long list of commits by Andrew on June 12)
2023-06-12  Andre Vieira  <andre.simoesdiasvieira@arm.com>
        PR middle-end/110142
        * tree-vect-patterns.cc (vect_recog_widen_op_pattern): Don't pass
        subtype to vect_widened_op_tree and remove subtype parameter, also
        remove superfluous overloaded function definition.
        (vect_recog_widen_plus_pattern): Remove subtype parameter and dont pass
        to call to vect_recog_widen_op_pattern.
        (vect_recog_widen_minus_pattern): Likewise.
(^^^ this one also looks suspicious to me)

Any ideas which could have caused the changes?

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #50 from Jürgen Reuter <juergen.reuter at desy dot de> ---
How to proceed here? Since almost exactly a month the current gcc git master
doesn't show this problem anymore, from our CI I can deduce that the version on
July 3rd still failed, while the version on July 10th worked again. Since then
the problem didn't show up again. My guess is that something has changed in the
optimizer again (maybe because of a different problem/regression). Is it worth
to find the offending commit and see when and how it was fixed (maybe even
accidentally), or shall we add a gcc testsuite for regression testing, and
close this issue?

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #51 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The easiest would be to bisect gcc in the suspected ranges, that way you'd know
for sure which git commit introduced the problem and which fixed/"fixed" it.
If it is about what the compiler emits, one doesn't have to build whole gcc
from scratch each time, but can just --disable-bootstrap build it and during
bisection
whenever git is updated just ./config.status --recheck; ./config.status; make
-jN in libcpp, libiberty and gcc subdirectories and use f951/gfortran binariers
from that instead of the ones from the initial build to build your project.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #52 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Jakub Jelinek from comment #51)
> The easiest would be to bisect gcc in the suspected ranges, that way you'd
> know for sure which git commit introduced the problem and which
> fixed/"fixed" it.
> If it is about what the compiler emits, one doesn't have to build whole gcc
> from scratch each time, but can just --disable-bootstrap build it and during
> bisection
> whenever git is updated just ./config.status --recheck; ./config.status;
> make -jN in libcpp, libiberty and gcc subdirectories and use f951/gfortran
> binariers from that instead of the ones from the initial build to build your
> project.

This was the offending commit by Richard Sayle, on Saturday June 17:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=96c3539f2a38134cb76d8ab2e924e0dc70b2ccbd

=================================
i386: Two minor tweaks to ix86_expand_move.

This patch splits out two (independent) minor changes to i386-expand.cc's
ix86_expand_move from a larger patch, given that it's better to review
and commit these independent pieces separately from a more complex patch.

The first change is to test for CONST_WIDE_INT_P before calling
ix86_convert_const_wide_int_to_broadcast.  Whilst stepping through
this function in gdb, I was surprised that the code was continually
jumping into this function with operands that obviously weren't
appropriate.

The second change is to generalize the optimization for efficiently
moving a TImode value to V1TImode (via V2DImode), to cover all 128-bit
vector modes.

Hence for the test case:

typedef unsigned long uv2di __attribute__ ((__vector_size__ (16)));
uv2di foo2(__int128 x) { return (uv2di)x; }

we'd previously move via memory with:

foo2:   movq    %rdi, -24(%rsp)
        movq    %rsi, -16(%rsp)
        movdqa  -24(%rsp), %xmm0
        ret

with this patch we now generate with -O2 (the same as V1TImode):

foo2:   movq    %rdi, %xmm0
        movq    %rsi, %xmm1
        punpcklqdq      %xmm1, %xmm0
        ret

and with -O2 -msse4 the even better:

foo2:   movq    %rdi, %xmm0
        pinsrq  $1, %rsi, %xmm0
        ret

The new test case is unimaginatively called sse2-v1ti-mov-2.c given
the original test case just for V1TI mode was called sse2-v1ti-mov-1.c.

2023-06-17  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_expand_move): Check that OP1 is
CONST_WIDE_INT_P before calling ix86_convert_wide_int_to_broadcast.
Generalize special case for converting TImode to V1TImode to handle
all 128-bit vector conversions.

gcc/testsuite/ChangeLog
* gcc.target/i386/sse2-v1ti-mov-2.c: New test case.
===========================================================

Now the question is, was this commit later reverted? Or changed in a different
manner

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #53 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Additional comment: the commit which fixed/"fixed" this offending commit came
between July 3 and July 10.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #54 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Jürgen Reuter from comment #53)
> Additional comment: the commit which fixed/"fixed" this offending commit
> came between July 3 and July 10.

Wildly speculating, it would be this commit maybe,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bdf2737cda53a83332db1a1a021653447b05a7e7
???

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #55 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Actually, according to my testing, the last commit where the gfortran produced
failing code,
ishttps://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c496d15954cdeab7f9039328f94a6f62cf893d5f
(Aldy Hernandez A singleton irange etc.)
and the first one working again is
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1f7e5a7b91862b999aab88ee0319052aaf00f0f1
(Vladimir Makarov)
that seems to have fixed it. 
The commit from Vladimir fixed an issue in RTL, but I am not sure what to
conclude from this.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #56 from Jürgen Reuter <juergen.reuter at desy dot de> ---
What do we do now? We know the offending commit, and the commit that fixed (or
"fixed") it. Closing? Do we understand what happened here, so why it went wrong
and why it got fixed?

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #57 from Richard Biener <rguenth at gcc dot gnu.org> ---
It might be not ideal but it seems unless somebody finds the time to analyze
the difference the "fix" did and thereby identifies the problem itself closing
the bug is the most efficient way of dealing with it :/

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #58 from Richard Biener <rguenth at gcc dot gnu.org> ---
Thus fixed.