[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #9)
> It appears that all testcases in this PR give more or less meaningful
> error messages for >= 9.5.0, and error recovery is clean under valgrind.
> 
> I think this one can be closed.

Finally closing.

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
  Known to work||10.5.0, 11.4.1, 12.3.1,
   ||13.2.1, 14.0, 9.5.0
  Known to fail||7.5.0, 8.5.0
 Status|NEW |WAITING

--- Comment #9 from anlauf at gcc dot gnu.org ---
It appears that all testcases in this PR give more or less meaningful
error messages for >= 9.5.0, and error recovery is clean under valgrind.

I think this one can be closed.

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
The ICE for the test in comment 0 disappeared at r254605.

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
The ICEs have been replaced with the error

Error: 'from' argument of 'move_alloc' intrinsic at (1) must be the same type
and kind as 'to'

between revisions r254498 and r254660, except for the test in comment 1.

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
Extending the check in comment #5 to

  if (from->ts.type == BT_CLASS && to->ts.type != BT_CLASS ||
  to->ts.type == BT_CLASS && from->ts.type != BT_CLASS)
{
  gfc_error ("The FROM and TO arguments at %L are incompatible",
>where);
  return false;
}

also avoids the ICE for

program p
   class(*), allocatable :: a, b
   call move_alloc (a, b)
contains
   subroutine b
   end
end

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
Besides the lack of diagnosing the conflicting definitions,
I think there is a missing check in gfc_check_move_alloc().

The test case

program p
   class(*), allocatable :: a, b
   call move_alloc (a, b)
contains
   subroutine a
   end
end

hits near the end of the function

  /* CLASS arguments: Make sure the vtab of from is present.  */
  if (to->ts.type == BT_CLASS && !UNLIMITED_POLY (from))
gfc_find_vtab (>ts);

However, for that case I get

 (gdb) print from->ts.type
$7 = BT_PROCEDURE

which should never happen, and is not expected.
To avoid an ICE, one might add a check just before this block, like:

  if (to->ts.type == BT_CLASS && from->ts.type != BT_CLASS)
{
  gfc_error ("The FROM and TO arguments at %L are incompatible",
>where);
  return false;
}

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #4 from Harald Anlauf  ---
There appears to be a difference between class(*) and e.g. type(*)
in the detection of clashes.

% cat pr77517-3.f90
  class(*), allocatable :: a
  type(*),  allocatable :: c
contains
  subroutine a
  end
  subroutine c
  end
end

% gfc-trunk -c pr77517-3.f90
pr77517-3.f90:6:14:

   subroutine c
  1
Error: SUBROUTINE attribute conflicts with ALLOCATABLE attribute in 'c' at (1)
pr77517-3.f90:1:28:

   class(*), allocatable :: a
1
pr77517-3.f90:8:3:

 end
   2 
Error: Two main PROGRAMs at (1) and (2)


Also try commenting out one of the declarations.

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-09
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed. The ICE for the test in comment 0 appeared between revisions r229946
(2015-11-08, error) and r229946 (2015-11-08, ICE) and has been back ported to
gcc-5, but not gcc-4.9. The only candidates I have found are r229992 (pr68053)
and r229955 (pr68224).

Any objection to mark this PR as a [5/6/7 Regression]?

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---

For completeness, older versions below 5 give :


$ gfortran-4.9 z1.f90
z1.f90:3.20:

   call move_alloc (a, b)
1
Error: 'from' argument of 'move_alloc' intrinsic at (1) must be the same type
and kind as 'to'


$ gfortran-4.9 z2.f90
z2.f90:1.9:

program p
 1
Internal Error at (1):
Invalid expression in gfc_element_size.


$ gfortran-4.8 z2.f90
z2.f90: In function 'p':
z2.f90:1:0: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1136
 program p
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

---


Backup, now silently accepted :

program p
   class(*), allocatable :: a, b
contains
   subroutine b
   end
end

program p
   class(*), allocatable :: a, b
contains
   subroutine a
   end
end

program p
   class(*), allocatable :: a, b
contains
   function b()
   end
end

program p
   class(*), allocatable :: a, b
contains
   function a()
   end
end

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

Similar with subroutine named "a" :


$ cat z2.f90
program p
   class(*), allocatable :: a, b
   call move_alloc (a, b)
contains
   subroutine a
   end
end


$ gfortran-7-20160904 z2.f90
f951: internal compiler error: Invalid expression in gfc_element_size.
0x68953f gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1317
0x71304b gfc_element_size(gfc_expr*)
../../gcc/fortran/target-memory.c:126
0x671517 find_intrinsic_vtab
../../gcc/fortran/class.c:2583
0x671517 gfc_find_vtab(gfc_typespec*)
../../gcc/fortran/class.c:2725
0x66703d gfc_check_move_alloc(gfc_expr*, gfc_expr*)
../../gcc/fortran/check.c:3347
0x6a4f87 gfc_intrinsic_sub_interface(gfc_code*, int)
../../gcc/fortran/intrinsic.c:4676
0x6f2972 resolve_unknown_s
../../gcc/fortran/resolve.c:3356
0x6f2972 resolve_call
../../gcc/fortran/resolve.c:3472
0x6ef8c0 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10733
0x6f1cb2 resolve_codes
../../gcc/fortran/resolve.c:15697
0x6f1dae gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15732
0x6dce7a resolve_all_program_units
../../gcc/fortran/parse.c:5850
0x6dce7a gfc_parse_file()
../../gcc/fortran/parse.c:6102
0x71f602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198