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

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

[zeccav at gmail dot com]

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

            Bug ID: 58771
           Summary: ICE in transfer_expr, at fortran/trans-io.c:2164
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zeccav at gmail dot com

With gfortran 4.8.2, the following produces an ICE in transfer_expr:

      module m
      type t
       integer g
      end type
      end
      type(t) function f() result(ff)
      use m
      end
      use m
      type(t)  f
      print *,f()
      end
!gfbug106.f: In function ‘MAIN__’:
!gfbug106.f:12:0: internal compiler error: in transfer_expr, at
fortran/trans-io.c:2164
!       print *,f()
! ^
!0x5cf016 transfer_expr
!        ../../gcc-4.8.2/gcc/fortran/trans-io.c:2164
!0x5d1ff5 gfc_trans_transfer(gfc_code*)
!        ../../gcc-4.8.2/gcc/fortran/trans-io.c:2312
!0x591a87 trans_code
!        ../../gcc-4.8.2/gcc/fortran/trans.c:1625
!0x5cfee7 build_dt
!        ../../gcc-4.8.2/gcc/fortran/trans-io.c:1835
!0x591aa7 trans_code
!        ../../gcc-4.8.2/gcc/fortran/trans.c:1597
!0x5af122 gfc_generate_function_code(gfc_namespace*)
!        ../../gcc-4.8.2/gcc/fortran/trans-decl.c:5397
!0x552a10 translate_all_program_units
!        ../../gcc-4.8.2/gcc/fortran/parse.c:4474
!0x552a10 gfc_parse_file()
!        ../../gcc-4.8.2/gcc/fortran/parse.c:4688
!0x58e155 gfc_be_parse_file
!        ../../gcc-4.8.2/gcc/fortran/f95-lang.c:189
!Please submit a full bug report,
!with preprocessed source if appropriate.
!Please include the complete backtrace with any bug report.
>From gcc-bugs-return-432067-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 17 19:37:49 2013
Return-Path: <gcc-bugs-return-432067-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25384 invoked by alias); 17 Oct 2013 19:37:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25341 invoked by uid 48); 17 Oct 2013 19:37:46 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/51542] bootstrap failure due to uninitialized variable use in c-parser
Date: Thu, 17 Oct 2013 19:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-51542-4-6cVe5AsVKk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-51542-4@http.gcc.gnu.org/bugzilla/>
References: <bug-51542-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-10/txt/msg01211.txt.bz2
Content-length: 520

http://gcc.gnu.org/bugzilla/show_bug.cgi?idQ542

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mpolacek at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed a long time ago.

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

[kargl at gcc dot gnu.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.

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

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
This one is going to drive me mad! It appears that the derived type is not
being built as Steve reported in comment #1.  If I force it to be built by
using a type 't' variable, the ICE goes away.  However, I have not found the
offending point where it is not being built... if you see what I mean.

A slightly more elaborate and legal testcase to illustrate this:
module m
  type t
    integer g
  end type
end

function f() result(ff)
  use m
  type(t) :: ff
  ff%g = 1
end

  use m
  type(t) :: z
  interface
    function f() result(ff)
      use m
      type(t) :: ff
    end function
  end interface
  print *,f()
!  z = t(1)       ! Does not ICE if this is uncommented
end

Paul

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

[pault at gcc dot gnu.org]

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

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 #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 31142
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31142&action=edit
Tentative patch

No sooner did I send comment #2 than I tried an obvious fix.  It looks a bit
kludgey but it really does no harm :-)

It's regtesting now.

Cheers

Paul

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

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Mon Nov  4 20:19:40 2013
New Revision: 204358

URL: http://gcc.gnu.org/viewcvs?rev=204358&root=gcc&view=rev
Log:
2013-11-04  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/58771
    * trans-io.c (transfer_expr): If the backend_decl for a derived
    type is missing, build it with gfc_typenode_for_spec.

2013-11-04  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/58771
    * gfortran.dg/derived_external_function_1.f90 : New test

Added:
    trunk/gcc/testsuite/gfortran.dg/derived_external_function_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-io.c
    trunk/gcc/testsuite/ChangeLog

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

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Sun Nov 17 08:11:33 2013
New Revision: 204913

URL: http://gcc.gnu.org/viewcvs?rev=204913&root=gcc&view=rev
Log:
2013-11-17  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/58771
    * trans-io.c (transfer_expr): If the backend_decl for a derived
    type is missing, build it with gfc_typenode_for_spec.

2013-11-17  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/58771
    * gfortran.dg/derived_external_function_1.f90 : New test

Added:
   
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/derived_external_function_1.f90
Modified:
    branches/gcc-4_7-branch/gcc/fortran/ChangeLog
    branches/gcc-4_7-branch/gcc/fortran/trans-io.c
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

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

[pault at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Paul Thomas <pault at gcc dot gnu.org> ---
Fixed on 4,7,4,8 and 4.9.

Thanks for the report.

Paul