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))
