[Bug fortran/104048] New: ICE with recursively defined derived type

[Bug fortran/104048] New: ICE with recursively defined derived type

[arjen.markus895 at gmail dot com]

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

            Bug ID: 104048
           Summary: ICE with recursively defined derived type
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arjen.markus895 at gmail dot com
  Target Milestone: ---

Created attachment 52205
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52205&action=edit
Source of the program in question

The attached program causes an ICE in the gfortran compiler. This is the error
report: 

$ gfortran -c chk_moa_view_ndim_alt.f90
chk_moa_view_ndim_alt.f90:57:31:

   57 |     new_view%left_view  = view1
      |                               1
internal compiler error: in fold_convert_loc, at fold-const.c:2552
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

Details of the compiler;

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/11/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.2.0/configure
--srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.2.0 --prefix=/usr
--exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--with-gcc-major-version-only --enable-shared --enable-shared-libgcc
--enable-static --enable-version-specific-runtime-libs --enable-bootstrap
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic --disable-bootstrap
--enable-languages=c,c++,fortran,lto,objc,obj-c++,jit --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath
--enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers
--with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
--enable-libstdcxx-filesystem-ts
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)

(The program may possibly be simplified further)

[Bug fortran/104048] ICE with recursively defined derived type

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |7.1.0
           Keywords|                            |ice-on-valid-code

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed, reduced testcase:
MODULE h
    TYPE :: tt
        TYPE(tt), ALLOCATABLE :: left_view
    END TYPE tt
CONTAINS
FUNCTION ff( arg ) result(res)
    CLASS(tt), INTENT(IN) :: arg
    CLASS(tt),  ALLOCATABLE :: res
    ALLOCATE( res )
    res%left_view  = arg
END FUNCTION ff
END MODULE

[Bug fortran/104048] ICE with recursively defined derived type

[arjen.markus895 at gmail dot com]

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

--- Comment #2 from Arjen Markus <arjen.markus895 at gmail dot com> ---
That reduced example is wonderfully compact! (I checked for similar reports but
probably missed bug report 79440, because it was not associated with
"recursive" data types)

[Bug fortran/104048] ICE with recursively defined derived type

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-01-17

[Bug fortran/104048] ICE with recursively defined derived type

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Arjen Markus from comment #2)
> That reduced example is wonderfully compact! (I checked for similar reports
> but probably missed bug report 79440, because it was not associated with
> "recursive" data types)

Because I don't think it is related at all to recursive data types at all take:
MODULE h
    TYPE :: tt
    END TYPE tt
    TYPE :: tt1
        TYPE(tt), ALLOCATABLE :: left_view
    END TYPE tt1
CONTAINS
FUNCTION ff( arg ) result(res)
    CLASS(tt), INTENT(IN) :: arg
    CLASS(tt1),  ALLOCATABLE :: res
    ALLOCATE( res )
    res%left_view  = arg
END FUNCTION ff
END MODULE

We get the same ICE.

[Bug fortran/104048] ICE with recursively defined derived type

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r7-4096-gbf9f15ee55f5b291, it was rejected before the revision
with:

Error: Derived type at (1) has not been previously defined and so cannot appear
in a derived type definition
pr104048.f90:10:17:

     res%left_view  = arg
                 1
Error: ‘left_view’ at (1) is not a member of the ‘tt’ structure

[Bug fortran/104048] ICE with recursively defined derived type

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #4)
> Started with r7-4096-gbf9f15ee55f5b291, it was rejected before the revision
> with:

The fix is (This chunk is lifted from a much bigger patch):

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 2e15a7e874c..3f786e91a2f 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -11419,6 +11562,8 @@ trans_class_assignment (stmtblock_t *block, gfc_expr
*lhs, gfc_expr *rhs,
        old_vptr = build_int_cst (TREE_TYPE (vptr), 0);

       size = gfc_vptr_size_get (vptr);
+      lse->expr = TREE_CODE (lse->expr) == INDIRECT_REF ?
+                 TREE_OPERAND (lse->expr, 0) : lse->expr;
       class_han = GFC_CLASS_TYPE_P (TREE_TYPE (lse->expr))
          ? gfc_class_data_get (lse->expr) : lse->expr;


with it this runs correctly:


MODULE moa_view_types

    IMPLICIT NONE

    TYPE moa_basic_view
        integer, allocatable :: shp(:)
    END TYPE moa_basic_view

    TYPE :: moa_view_type
        TYPE(moa_basic_view)             :: left_array
        TYPE(moa_basic_view)             :: right_array
        TYPE(moa_view_type), ALLOCATABLE :: left_view
        TYPE(moa_view_type), ALLOCATABLE :: right_view
    END TYPE moa_view_type

CONTAINS

FUNCTION catenate_view_view( view1, view2 ) result(new_view)
    CLASS(moa_view_type), TARGET, INTENT(IN) :: view1
    CLASS(moa_view_type), TARGET, INTENT(IN) :: view2
    CLASS(moa_view_type),  ALLOCATABLE        :: new_view

    ALLOCATE( new_view )

    new_view%left_view  = view1 ! Used to cause an ICE
    new_view%right_view = view2 !      -ditto-
END FUNCTION catenate_view_view

END MODULE moa_view_types

    use moa_view_types
    class(moa_view_type), allocatable :: view1, view2, new_view
    allocate (view1, view2)
    view1%left_array%shp = [1 , 2]
    view2%right_array%shp = [3 , 4]
    new_view = catenate_view_view( view1, view2 )
    select type (new_view)
      type is (moa_view_type)
        if (any (new_view%left_view%left_array%shp .ne. [1,2])) stop 1
        if (any (new_view%right_view%right_array%shp .ne. [3,4])) stop 2
    end select
end


Paul

[Bug fortran/104048] ICE with recursively defined derived type

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
The "fix" in comment 5 no longer does the job. It's on my TODO list.

Paul

[Bug fortran/104048] ICE with recursively defined derived type

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 58296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58296&action=edit
Fix for this PR

This does fix it :-)

It's a partial implementation that will require class components and array
components to be complete.

It will be done in a few days.

Paul