[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #26 from anlauf at gcc dot gnu.org ---
Should be fixed on trunk, 8-branch and 7-branch.

Closing.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #25 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Wed Apr 10 21:02:02 2019
New Revision: 270268

URL: https://gcc.gnu.org/viewcvs?rev=270268&root=gcc&view=rev
Log:
2019-04-10  Harald Anlauf  

Backport from trunk
PR fortran/89904
* check.c (gfc_check_transfer): Reject procedures as actual
arguments for SOURCE and MOLD of TRANSFER intrinsic.

PR fortran/89904
* gfortran.dg/pr85797.f90: Adjust testcase.

Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/check.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85797.f90

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #24 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Wed Apr 10 20:26:44 2019
New Revision: 270265

URL: https://gcc.gnu.org/viewcvs?rev=270265&root=gcc&view=rev
Log:
2019-04-10  Harald Anlauf  

Backport from trunk
PR fortran/89904
* check.c (gfc_check_transfer): Reject procedures as actual
arguments for SOURCE and MOLD of TRANSFER intrinsic.

PR fortran/89904
* gfortran.dg/pr85797.f90: Adjust testcase.

Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/check.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr85797.f90

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||srinath.parvathaneni at arm 
dot co
   ||m

--- Comment #23 from Thomas Koenig  ---
*** Bug 89987 has been marked as a duplicate of this bug. ***

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #22 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Sun Apr  7 19:42:05 2019
New Revision: 270192

URL: https://gcc.gnu.org/viewcvs?rev=270192&root=gcc&view=rev
Log:
2019-04-07  Harald Anlauf  

PR fortran/89904
* ChangeLog: Correct ChangeLog entry.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #21 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #20)
> Patch here:
> 
> https://gcc.gnu.org/ml/fortran/2019-04/msg3.html

Patch applied to trunk so far.

Unfortunately, I had the wrong PR in the ChangeLog (PR89004).  :-(

Sorry for that.  I should get that right for the backports.

Will wait for a couple of days to see if there is further fallout.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #20 from anlauf at gcc dot gnu.org ---
Patch here:

https://gcc.gnu.org/ml/fortran/2019-04/msg3.html

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #17)
> > So shall I resubmit my original patch, or is Steve's comment#11 better?
> 
> I'ld take Steve's conditions, but your wording for the errors!-)

Steve's patch would not reject:

subroutine f
  use, intrinsic :: iso_c_binding
  integer(c_intptr_t) :: b, c
  procedure(), pointer :: a
  c = transfer (a, b)
  c = transfer (transfer (b, a), b)
end

so this is probably what Thomas had in mind.

I'll package the patch and submit.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[tkoenig at netcologne dot de]

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

--- Comment #18 from tkoenig at netcologne dot de  ---
Am 02.04.19 um 20:48 schrieb anlauf at gcc dot gnu.org:
> I had rejected procedure arguments to TRANSFER in my initial patch, see
> 
> https://gcc.gnu.org/ml/fortran/2019-03/msg00099.html
> 
> but Thomas persuaded me to be less strict.

I guess I had it wrong, then.

Procedure pointer arguments to functions should be OK and take
their type etc. information from the type of the pointer.
Also, functions returning pointers should be permitted.
This is what I orignally had in mind.

I agree that mysel a subroutine argument or pure function argument
makes no sense.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[dominiq at lps dot ens.fr]

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

--- Comment #17 from Dominique d'Humieres  ---
> So shall I resubmit my original patch, or is Steve's comment#11 better?

I'ld take Steve's conditions, but your wording for the errors!-)

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
I had rejected procedure arguments to TRANSFER in my initial patch, see

https://gcc.gnu.org/ml/fortran/2019-03/msg00099.html

but Thomas persuaded me to be less strict.

So shall I resubmit my original patch, or is Steve's comment#11 better?

Of course the testcase needs adjustments.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[dominiq at lps dot ens.fr]

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

--- Comment #15 from Dominique d'Humieres  ---
Note that the patch in comment 11 is quite close to the Harald's original patch
at

https://gcc.gnu.org/ml/fortran/2019-03/msg00099.html

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> Note that r270046 introduced the same thing into gcc 8.

Yes, and r270047 into gcc 7.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[seurer at gcc dot gnu.org]

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

--- Comment #13 from seurer at gcc dot gnu.org ---
Note that r270046 introduced the same thing into gcc 8.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[kargl at gcc dot gnu.org]

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

--- Comment #12 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #11)
> (In reply to Thomas Koenig from comment #10)
> > (In reply to anlauf from comment #9)
> > 
> > > If you start from the full testcase, and remove - starting from the end -
> > > block for block: first module m, then subroutine f, then subroutine e,
> > > then subroutine d, what does trigger the ICE?
> > 
> > This segfaults on gcc135 (POWER9):
> > 
> > [tkoenig@gcc135 ~]$ cat a.f90
> > recursive subroutine e
> >   k = transfer (transfer (e, e), 1)
> > end
> > [tkoenig@gcc135 ~]$ gfortran -O a.f90
> > Im Durchlauf GIMPLE: ccp
> > a.f90:3:0:
> > 
> > 3 | end
> >   | 
> > interner Compiler-Fehler: in fold_convert_loc, bei fold-const.c:2552
> >
> 
> This is solved by
> 
> Index: gcc/fortran/check.c
> ===
> --- gcc/fortran/check.c   (revision 270064)
> +++ gcc/fortran/check.c   (working copy)
> @@ -5551,6 +5551,20 @@ gfc_check_transfer (gfc_expr *source, gfc_expr *mold, 
>return false;
>  }
>  
> +  if (mold->ts.type == BT_PROCEDURE
> +  && mold->symtree->n.sym->attr.subroutine == 1)
> +{
> +  gfc_error("Stupidity occurring at %L", &mold->where);
> +  return false;
> +}
> +
> +  if (source->ts.type == BT_PROCEDURE
> +  && source->symtree->n.sym->attr.subroutine == 1)
> +{
> +  gfc_error("Stupidity occurring at %L", &source->where);
> +  return false;
> +}
> +
>if (size != NULL)
>  {
>if (!type_check (size, 2, BT_INTEGER))

For full context, F2018, 16.9.193

SOURCE shall be a scalar or array of any type.
MOLD   shall be a scalar or array of any type.

A subroutine is neither a scalar, an array, nor has a type.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #10)
> (In reply to anlauf from comment #9)
> 
> > If you start from the full testcase, and remove - starting from the end -
> > block for block: first module m, then subroutine f, then subroutine e,
> > then subroutine d, what does trigger the ICE?
> 
> This segfaults on gcc135 (POWER9):
> 
> [tkoenig@gcc135 ~]$ cat a.f90
> recursive subroutine e
>   k = transfer (transfer (e, e), 1)
> end
> [tkoenig@gcc135 ~]$ gfortran -O a.f90
> Im Durchlauf GIMPLE: ccp
> a.f90:3:0:
> 
> 3 | end
>   | 
> interner Compiler-Fehler: in fold_convert_loc, bei fold-const.c:2552
>

This is solved by

Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 270064)
+++ gcc/fortran/check.c (working copy)
@@ -5551,6 +5551,20 @@ gfc_check_transfer (gfc_expr *source, gfc_expr *mold, 
   return false;
 }

+  if (mold->ts.type == BT_PROCEDURE
+  && mold->symtree->n.sym->attr.subroutine == 1)
+{
+  gfc_error("Stupidity occurring at %L", &mold->where);
+  return false;
+}
+
+  if (source->ts.type == BT_PROCEDURE
+  && source->symtree->n.sym->attr.subroutine == 1)
+{
+  gfc_error("Stupidity occurring at %L", &source->where);
+  return false;
+}
+
   if (size != NULL)
 {
   if (!type_check (size, 2, BT_INTEGER))

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #10 from Thomas Koenig  ---
(In reply to anlauf from comment #9)

> If you start from the full testcase, and remove - starting from the end -
> block for block: first module m, then subroutine f, then subroutine e,
> then subroutine d, what does trigger the ICE?

This segfaults on gcc135 (POWER9):

[tkoenig@gcc135 ~]$ cat a.f90
recursive subroutine e
  k = transfer (transfer (e, e), 1)
end
[tkoenig@gcc135 ~]$ gfortran -O a.f90
Im Durchlauf GIMPLE: ccp
a.f90:3:0:

3 | end
  | 
interner Compiler-Fehler: in fold_convert_loc, bei fold-const.c:2552
0x10648633 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../trunk/gcc/fold-const.c:2552
0x10e9df87 build_zero_cst(tree_node*)
../../trunk/gcc/tree.c:2382
0x10c36297 evaluate_stmt
../../trunk/gcc/tree-ssa-ccp.c:1997
0x10c38403 visit_assignment
../../trunk/gcc/tree-ssa-ccp.c:2352
0x10cf266f ssa_propagation_engine::simulate_stmt(gimple*)
../../trunk/gcc/tree-ssa-propagate.c:230
0x10cf2acb ssa_propagation_engine::simulate_block(basic_block_def*)
../../trunk/gcc/tree-ssa-propagate.c:337
0x10cf4a63 ssa_propagation_engine::ssa_propagate()
../../trunk/gcc/tree-ssa-propagate.c:802
0x10c2ab27 do_ssa_ccp
../../trunk/gcc/tree-ssa-ccp.c:2471
0x10c2ab27 execute
../../trunk/gcc/tree-ssa-ccp.c:2515
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
inclusive vorverarbeitetem Quellcode, wenn es dienlich ist.
Please include the complete backtrace with any bug report.
Weitere Hinweise finden Sie unter »«.

-fdump-tree-original shows

e ()
{
  integer(kind=4) k;

  {
integer(kind=8) D.2240;
integer(kind=8) D.2241;
integer(kind=8) D.2242;
integer(kind=8) D.2243;
void  (void) transfer.0;
void  (void) D.2245;
static integer(kind=4) C.2246 = 1;
integer(kind=8) D.2247;
integer(kind=8) D.2248;
integer(kind=4) transfer.1;

D.2241 = 4;
D.2242 = 4;
__builtin_memcpy ((void *) &transfer.0, (void *) e, (unsigned long)
MAX_EXPR , 0>);
D.2245 = transfer.0;
D.2240 = 4;
D.2247 = 4;
__builtin_memcpy ((void *) &transfer.1, (void *) &D.2245, (unsigned long)
MAX_EXPR , 0>);
k = transfer.1;
  }
}

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to seurer from comment #8)
> With no f:  ICE
> 
> With only subroutine a and subroutine f: no ICE

Now it gets really mysterious.

If you start from the full testcase, and remove - starting from the end -
block for block: first module m, then subroutine f, then subroutine e,
then subroutine d, what does trigger the ICE?

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[seurer at gcc dot gnu.org]

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

--- Comment #8 from seurer at gcc dot gnu.org ---
With no f:  ICE

With only subroutine a and subroutine f: no ICE

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to seurer from comment #6)
> Actually, it is the opposite.

Oh, that is surprising.

So if you comment out subroutine f, there's no ICE?
And if you keep only subroutine a and subroutine f, it ICEs?

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[seurer at gcc dot gnu.org]

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

--- Comment #6 from seurer at gcc dot gnu.org ---
Actually, it is the opposite.

With 24-33 commented out:

seurer@makalu-lp1:~/gcc/build/gcc-test$ cat
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/pr85797.f90
. . .
! module m
! contains
!   function f () result (z)  ! { dg-warning "Return value" }
! class(*), pointer :: z
!   end function f
!   recursive subroutine s (q)
! procedure(f) :: q
! call s (q)
!   end subroutine s
! end
seurer@makalu-lp1:~/gcc/build/gcc-test$
/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/pr85797.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O -Wall -S -o pr85797.s
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/pr85797.f90:7:16: Warning:
Non-RECURSIVE procedure 'a' at (1) is possibly calling itself recursively. 
Declare it RECURSIVE or use '-frecursive'
during GIMPLE pass: ccp
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/pr85797.f90:22:0: internal
compiler error: in fold_convert_loc, at fold-const.c:2552
0x106a8b87 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/home/seurer/gcc/gcc-test/gcc/fold-const.c:2552
0x10e9e8fb build_zero_cst(tree_node*)
/home/seurer/gcc/gcc-test/gcc/tree.c:2382
0x10c592fb evaluate_stmt
/home/seurer/gcc/gcc-test/gcc/tree-ssa-ccp.c:1997
0x10c5aa63 visit_assignment
/home/seurer/gcc/gcc-test/gcc/tree-ssa-ccp.c:2352
0x10c5acfb ccp_propagate::visit_stmt(gimple*, edge_def**, tree_node**)
/home/seurer/gcc/gcc-test/gcc/tree-ssa-ccp.c:2430
0x10d13433 ssa_propagation_engine::simulate_stmt(gimple*)
/home/seurer/gcc/gcc-test/gcc/tree-ssa-propagate.c:230
0x10d138cb ssa_propagation_engine::simulate_block(basic_block_def*)
/home/seurer/gcc/gcc-test/gcc/tree-ssa-propagate.c:337
0x10d159a3 ssa_propagation_engine::ssa_propagate()
/home/seurer/gcc/gcc-test/gcc/tree-ssa-propagate.c:802
0x10c5399f do_ssa_ccp
/home/seurer/gcc/gcc-test/gcc/tree-ssa-ccp.c:2471
0x10c5399f execute
/home/seurer/gcc/gcc-test/gcc/tree-ssa-ccp.c:2515


With the rest commented out but not lines 24-33:

seurer@makalu-lp1:~/gcc/build/gcc-test$ cat
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/pr85797.f90
. . .
! subroutine a
!   c = transfer (a, b)   ! { dg-warning "Non-RECURSIVE procedure" }
! end
! 
! recursive subroutine d
!   c = transfer (d, b)
! end
! 
! recursive subroutine e
!   k = transfer (transfer (e, e), 1)
! end
! 
! subroutine f
!   use, intrinsic :: iso_c_binding
!   integer(c_intptr_t) :: b, c
!   c = transfer (transfer (b, a), b)
! end

module m
. . .
seurer@makalu-lp1:~/gcc/build/gcc-test$
/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/pr85797.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O -Wall -S -o pr85797.s
a->name=='(null)'
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/pr85797.f90:26:26: Warning:
Return value 'z' of function 'f' declared at (1) not set [-Wreturn-type]
seurer@makalu-lp1:~/gcc/build/gcc-test$

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> and if you keep only those lines (commenting lines 6-22),
> there's no ICE?

Sorry, I meant there an ICE here on your target.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to seurer from comment #3)
> Best I can tell from poking around in gdb is that it is happening at line 32
> 
>   end subroutine s
> 
> that's probably not much help.  Sorry!

So if you comment out lines 24-33 (the part "module m" until the final "end"),
there's no ICE, and if you keep only those lines (commenting lines 6-22),
there's no ICE?

This would mean that PR83515 either is not completely fixed,
or the fix exposes something else that doesn't show up on x86_64.

I see the following options:

- XFAIL the testcase where needed, until this PR gets fixed
  (maybe there's a related issue)
- reopen PR83515 and remove lines 24-33 from the testcase; the tests given
  that PR may succeed on x86_64, but lead to an ICE in a different place
  elsewhere

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
Best I can tell from poking around in gdb is that it is happening at line 32

  end subroutine s

that's probably not much help.  Sorry!

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-01
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Also seen on powerpc-ibm-aix7.2.0.0.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Can you find out which of the tests in file pr85797.f90 triggers the ICE?

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.0