[Bug fortran/94386] New: [10 Regression] FAIL: gfortran.dg/pr93365.f90

[Bug fortran/94386] New: [10 Regression] FAIL: gfortran.dg/pr93365.f90

[hjl.tools at gmail dot com]

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

            Bug ID: 94386
           Summary: [10 Regression] FAIL: gfortran.dg/pr93365.f90
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: pault at gcc dot gnu.org
  Target Milestone: ---

commit 7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65
Author: Paul Thomas <pault@pc30.home>
Date:   Sat Mar 28 19:11:35 2020 +0000

    Patch for PR94246

caused:

FAIL: gfortran.dg/pr93365.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/pr93600_1.f90   -O  (internal compiler error)
FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 6)
FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 7)
FAIL: gfortran.dg/pr93600_1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -Os  (test for excess errors)

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-03-29

--- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
The error is here:

Program received signal SIGSEGV, Segmentation fault.
match_data_constant (result=0x7fffffffd628) at ../../gcc/gcc/fortran/decl.c:426
426           if ((*result)->symtree->n.sym->attr.save
(gdb) l
421              attribute. ...  If data-stmt-constant is initial-data-target
422              the corresponding data statement object shall be
423              data-pointer-initialization compatible (7.5.4.6) with the
initial
424              data target; the data statement object is initially associated
425              with the target.  */
426           if ((*result)->symtree->n.sym->attr.save
427               && (*result)->symtree->n.sym->attr.target)
428             return m;
429           gfc_free_expr (*result);
430         }
(gdb) p  (*result)->symtree
$1 = (gfc_symtree *) 0x0

(gdb) call debug(*result)
(/  /) (INTEGER 4)

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |seurer at linux dot vnet.ibm.com

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
*** Bug 94390 has been marked as a duplicate of this bug. ***

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #0)
> commit 7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65
> Author: Paul Thomas <pault@pc30.home>
> Date:   Sat Mar 28 19:11:35 2020 +0000
> 
>     Patch for PR94246

Since the ICE occurs in primary.c, I was highly skeptical that the patch for
PR94246 caused it. To be sure though, I reverted the patch and found that the
ICE remains.

That said, I will take a look tomorrow to understand and try to fix this -
unless Thomas beats me to it.

Paul

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[seurer at linux dot vnet.ibm.com]

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

--- Comment #4 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
The problem is definitely caused by

g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444

I built it before and no problems, errors after.

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.0

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Bill Seurer from comment #4)
> The problem is definitely caused by
> 
> g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444
> 
> I built it before and no problems, errors after.

I am utterly perplexed by this. I have reverted once again. The errors reported
by HJ remain and bessel_5.f90 once more segfaults.

I will investigate this PR in its own right.

Regards

Paul

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[seurer at linux dot vnet.ibm.com]

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

--- Comment #6 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
git g:3fb7f2fbd5f109786922deb5af8fd8dd594a7ba6, r10-7443

make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90
# of expected passes            3


git g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444

make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90

# of unexpected failures        3
FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 6)
FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 7)
FAIL: gfortran.dg/pr93600_1.f90   -O  (test for excess errors)


These were both clean builds run on a powerpc64 power8 LE machine.

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Bill Seurer from comment #6)
> These were both clean builds run on a powerpc64 power8 LE machine.

I can confirm this on x86-64-gnu-linux; if I use the current trunk and undo
this commit, it works – with the patch, it fails.

 * * *

Looking it at in the debugger, one has:

   logical, parameter :: a(0) = .true.
   data d /a%kind/

In gfc_match_varspec, one has:

      if (tmp && tmp->type == REF_INQUIRY)

At this point, primary is "a" and primary->ref->next == tmp == tail while
primary->ref is the (full) array spec. Now one calls:

          gfc_simplify_expr (primary, 0);

which turns this into an EXPR_ARRAY and as this one cleans up, "tmp" now points
to undefined memory and fails.

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

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

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #6)
> git g:3fb7f2fbd5f109786922deb5af8fd8dd594a7ba6, r10-7443
> 
> make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90
> # of expected passes		3
> 
> 
> git g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444
> 
> make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90
> 
> # of unexpected failures	3
> FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 6)
> FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 7)
> FAIL: gfortran.dg/pr93600_1.f90   -O  (test for excess errors)
> 
> 
> These were both clean builds run on a powerpc64 power8 LE machine.

The patch committed to fix(?) PR94246 reverted the code that fixed
PR93665 and PR93600 without removing the now failing testcases and
re-opening the now unfixed PR93665 and PR93600.  %len and %kind 
need to be special cased.  See, Oh, I don't know maybe the removed
comments in the diff.

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> ---

> > These were both clean builds run on a powerpc64 power8 LE machine.
> 
> The patch committed to fix(?) PR94246 reverted the code that fixed
> PR93665 and PR93600 without removing the now failing testcases and
> re-opening the now unfixed PR93665 and PR93600.  %len and %kind 
> need to be special cased.  See, Oh, I don't know maybe the removed
> comments in the diff.

Aaaah! OK, this a sign of my complete and utter incompetence with using git.

Could somebody please point me to the prescription for fixing this?

g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444 points to my intended
commit and nothing else.

I would also like to know how I could have done this since git normally
complains vociferously if I try to violate HEAD by doing things in the wrong
order.

Est mea maxima culpa, sed nescio quomodo me fecit ...

Paul

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm marking the ICEs P1 since they clutter the testresults.

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 94430 has been marked as a duplicate of this bug. ***

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[markeggleston at gcc dot gnu.org]

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

--- Comment #12 from markeggleston at gcc dot gnu.org ---
Created attachment 48155
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48155&action=edit
Proposed fix

Sorry for the duplicate (PR94430) I missed this PR.

The cause of the errors messages is due to most of the code in expr.c
introduced by PR93600 being deleted.

I restored the code, the error went away, however, bessel_5_redux.f90 resulted
in an ICE.

When this bit of PR94246 is put back:

@@ -2314,9 +2296,8 @@ scalarize_intrinsic_call (gfc_expr *e, bool init_flag)
   gfc_constructor_base ctor;
   gfc_constructor *args[5] = {};  /* Avoid uninitialized warnings.  */
   gfc_constructor *ci, *new_ctor;
-  gfc_expr *expr, *old;
+  gfc_expr *expr, *old, *p;
   int n, i, rank[5], array_arg;
-  int errors = 0;

   if (e == NULL)
     return false;
@@ -2384,8 +2365,6 @@ scalarize_intrinsic_call (gfc_expr *e, bool init_flag)
       n++;
     }

-  gfc_get_errors (NULL, &errors);
-
   /* Using the array argument as the master, step through the array
      calling the function for each element and advancing the array
      constructors together.  */
@@ -2419,8 +2398,12 @@ scalarize_intrinsic_call (gfc_expr *e, bool init_flag)
       /* Simplify the function calls.  If the simplification fails, the
         error will be flagged up down-stream or the library will deal
         with it.  */
-      if (errors == 0)
-       gfc_simplify_expr (new_ctor->expr, 0);
+      p = gfc_copy_expr (new_ctor->expr);
+
+      if (!gfc_simplify_expr (p, init_flag))
+       gfc_free_expr (p);
+      else
+       gfc_replace_expr (new_ctor->expr, p);

       for (i = 0; i < n; i++)
        if (args[i])

bessel_5_redux.f90.

I think

      if (errors == 0)
        gfc_simplify_expr (new_ctor->expr, 0);

caused the ICE.

I'm preparing the patch for upstream, its commit message needs updating not
that I have a PR number.

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mark Eggleston
<markeggleston@gcc.gnu.org>:

https://gcc.gnu.org/g:0c9a8a8c1030d072d598880c07f4d6a8d9e7deed

commit r10-7495-g0c9a8a8c1030d072d598880c07f4d6a8d9e7deed
Author: Mark Eggleston <markeggleston@gcc.gnu.org>
Date:   Wed Apr 1 12:50:16 2020 +0100

    fortran : FAIL: gfortran.dg/pr93365.f90 PR94386

    Failures of pr93365.f90,  pr93600_1.f90 and pr93600_2.f90.
    Changes made by PR94246 delete and changed code from expr.c
    introduced by PR93600, the deleted code.  This broke the PR93600
    test cases.  Restoring the deleted code and leaving the changed
    code alone allows the cases for PR93600 and PR94246 to pass.

    gcc/fortran/ChangeLog:

            PR fortran/94386
            expr.c (simplify_parameter_variable): Restore code deleted
            in PR94246.

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

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

--- Comment #14 from markeggleston at gcc dot gnu.org ---
r10-7495-g0c9a8a8c1030d072d598880c07f4d6a8d9e7deed committed to master

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[pault at gcc dot gnu.org]

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

--- Comment #15 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to markeggleston from comment #12)
> Created attachment 48155 [details]
> Proposed fix
> 
> Sorry for the duplicate (PR94430) I missed this PR.
> 
> The cause of the errors messages is due to most of the code in expr.c
> introduced by PR93600 being deleted.
> 
> I restored the code, the error went away, however, bessel_5_redux.f90
> resulted in an ICE.
> 
> When this bit of PR94246 is put back:
> 
> @@ -2314,9 +2296,8 @@ scalarize_intrinsic_call (gfc_expr *e, bool init_flag)
>    gfc_constructor_base ctor;
>    gfc_constructor *args[5] = {};  /* Avoid uninitialized warnings.  */
>    gfc_constructor *ci, *new_ctor;
> -  gfc_expr *expr, *old;
> +  gfc_expr *expr, *old, *p;
>    int n, i, rank[5], array_arg;
> -  int errors = 0;
>  
>    if (e == NULL)
>      return false;
> @@ -2384,8 +2365,6 @@ scalarize_intrinsic_call (gfc_expr *e, bool init_flag)
>        n++;
>      }
>  
> -  gfc_get_errors (NULL, &errors);
> -
>    /* Using the array argument as the master, step through the array
>       calling the function for each element and advancing the array
>       constructors together.  */
> @@ -2419,8 +2398,12 @@ scalarize_intrinsic_call (gfc_expr *e, bool init_flag)
>        /* Simplify the function calls.  If the simplification fails, the
>  	 error will be flagged up down-stream or the library will deal
>  	 with it.  */
> -      if (errors == 0)
> -	gfc_simplify_expr (new_ctor->expr, 0);
> +      p = gfc_copy_expr (new_ctor->expr);
> +
> +      if (!gfc_simplify_expr (p, init_flag))
> +	gfc_free_expr (p);
> +      else
> +	gfc_replace_expr (new_ctor->expr, p);
>  
>        for (i = 0; i < n; i++)
>  	if (args[i])
> 
> bessel_5_redux.f90.
> 
> I think
> 
>       if (errors == 0)
>         gfc_simplify_expr (new_ctor->expr, 0);
> 
> caused the ICE.
> 


Hi Mark,

Yes, indeed that was the problem. The simplification of the scalar expression
was coming back with a false but no error, which then fed a broken array
expression to the next stage of simplification and this caused the segfault.

I have a real problem to understand how I was able to do this without git
throwing a wobbler. Previously I have been firmly and vociferously prevented
from doing such things but on this occasion was allowed to screw things up.

I am a total tyro with git and don't have over much time outside of my
professional commitments to study the documentation. I would be grateful, if
either you or one of the others in copy to this PR could point me to a set of
clearly described workflows. Compared to svn, git seems to me to be
unpleasantly ass-backwards.

Many thanks for fixing the mess that I made. Bizarrely, the COVID-19 crisis has
me busier than ever even though working from home. I was aware that there was
time pressure but just could not respond to it.

Thanks again

Paul