[Bug fortran/58771] [Regression] ICE in transfer_expr, at fortran/trans-io.c:2164

["kargl at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58771

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-10-17
                 CC|                            |kargl at gcc dot gnu.org
      Known to work|                            |4.3.6, 4.4.7, 4.5.4
            Summary|ICE in transfer_expr, at    |[Regression] ICE in
                   |fortran/trans-io.c:2164     |transfer_expr, at
                   |                            |fortran/trans-io.c:2164
     Ever confirmed|0                           |1
      Known to fail|                            |4.6.4, 4.7.4, 4.8.2, 4.9.0

--- Comment #1 from kargl at gcc dot gnu.org ---
Confirmed.  On trunk, the problem is caused by the assert in line
2152 of transfer_expr() in trans-io.c.

      for (c = ts->u.derived->components; c; c = c->next)
    {
      field = c->backend_decl;
      gcc_assert (field && TREE_CODE (field) == FIELD_DECL);

Here, backend_decl = 0x0.

If the code is modified to something approaching legal Fortran to

module m
   type t
      integer g, h
   end type
end module m

type(t) function f() result(ff)
   use m
   ! Actually assign something to components of the derived type
   ff%g = 42
   ff%h = 43
end function f

program foo
   use m
   type(t) :: f
   type(t) e
   e = f()
   print *, f()
end program foo

then the reference via 'e = f90' seems to have gfortran go through
a code path that assign c->backend_decl to a non-null pointer.