* [Bug fortran/58771] [Regression] ICE in transfer_expr, at fortran/trans-io.c:2164
2013-10-17 19:14 [Bug fortran/58771] New: ICE in transfer_expr, at fortran/trans-io.c:2164 zeccav at gmail dot com
@ 2013-10-17 20:46 ` kargl at gcc dot gnu.org
2013-11-02 17:44 ` pault at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: kargl at gcc dot gnu.org @ 2013-10-17 20:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/58771] [Regression] ICE in transfer_expr, at fortran/trans-io.c:2164
2013-10-17 19:14 [Bug fortran/58771] New: ICE in transfer_expr, at fortran/trans-io.c:2164 zeccav at gmail dot com
2013-10-17 20:46 ` [Bug fortran/58771] [Regression] " kargl at gcc dot gnu.org
@ 2013-11-02 17:44 ` pault at gcc dot gnu.org
2013-11-02 18:13 ` pault at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: pault at gcc dot gnu.org @ 2013-11-02 17:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/58771] [Regression] ICE in transfer_expr, at fortran/trans-io.c:2164
2013-10-17 19:14 [Bug fortran/58771] New: ICE in transfer_expr, at fortran/trans-io.c:2164 zeccav at gmail dot com
2013-10-17 20:46 ` [Bug fortran/58771] [Regression] " kargl at gcc dot gnu.org
2013-11-02 17:44 ` pault at gcc dot gnu.org
@ 2013-11-02 18:13 ` pault at gcc dot gnu.org
2013-11-04 20:21 ` [Bug fortran/58771] [4.7/4.8/4.9 Regression] " pault at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: pault at gcc dot gnu.org @ 2013-11-02 18:13 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/58771] [4.7/4.8/4.9 Regression] ICE in transfer_expr, at fortran/trans-io.c:2164
2013-10-17 19:14 [Bug fortran/58771] New: ICE in transfer_expr, at fortran/trans-io.c:2164 zeccav at gmail dot com
` (2 preceding siblings ...)
2013-11-02 18:13 ` pault at gcc dot gnu.org
@ 2013-11-04 20:21 ` pault at gcc dot gnu.org
2013-11-17 8:11 ` pault at gcc dot gnu.org
2013-11-17 8:12 ` pault at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: pault at gcc dot gnu.org @ 2013-11-04 20:21 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/58771] [4.7/4.8/4.9 Regression] ICE in transfer_expr, at fortran/trans-io.c:2164
2013-10-17 19:14 [Bug fortran/58771] New: ICE in transfer_expr, at fortran/trans-io.c:2164 zeccav at gmail dot com
` (3 preceding siblings ...)
2013-11-04 20:21 ` [Bug fortran/58771] [4.7/4.8/4.9 Regression] " pault at gcc dot gnu.org
@ 2013-11-17 8:11 ` pault at gcc dot gnu.org
2013-11-17 8:12 ` pault at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: pault at gcc dot gnu.org @ 2013-11-17 8:11 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/58771] [4.7/4.8/4.9 Regression] ICE in transfer_expr, at fortran/trans-io.c:2164
2013-10-17 19:14 [Bug fortran/58771] New: ICE in transfer_expr, at fortran/trans-io.c:2164 zeccav at gmail dot com
` (4 preceding siblings ...)
2013-11-17 8:11 ` pault at gcc dot gnu.org
@ 2013-11-17 8:12 ` pault at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: pault at gcc dot gnu.org @ 2013-11-17 8:12 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread