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

2023-06-22 Thread juergen.reuter at desy dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #9 from Jürgen Reuter  ---
(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] gfortran 14.0 regression

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #8 from Andrew Pinski  ---
(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

2023-06-21 Thread juergen.reuter at desy dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #7 from Jürgen Reuter  ---
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

2023-06-21 Thread manolis.tsamis at vrull dot eu via Gcc-bugs
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

2023-06-20 Thread juergen.reuter at desy dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #5 from Jürgen Reuter  ---
(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

2023-06-20 Thread anlauf at gcc dot gnu.org via Gcc-bugs
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

2023-06-20 Thread juergen.reuter at desy dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #3 from Jürgen Reuter  ---
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

2023-06-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

Richard Biener  changed:

   What|Removed |Added

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