This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[Patch, fortran] PR29820 - ICE in fold_convert, at fold-const.c:2146
- From: Paul Thomas <paulthomas2 at wanadoo dot fr>
- To: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 15 Nov 2006 18:44:08 +0100
- Subject: [Patch, fortran] PR29820 - ICE in fold_convert, at fold-const.c:2146
:ADDPATCH fortran:
This time I am embarrassed!
The final stage in gfc_get_derived_type scans across the containing and
sibling derived types to ensure that the backend declaration is the same
for identical derived types. As writen, the code started from the
derived types own namespace and looked at its siblings. This of course
assumes that the translation of the contained procedures proceeds in the
order by which they are linked as siblings, which is the case. However,
a call to a sibling, with a derived type actual, causes a module symbol
to be made for the derived type and can break this ordering. The only
recourse is to scan all the contained procedures for each derived type,
if the containing namespace has a parent; ie. we refer up to the parent
and down to contained and then scan the siblings from there. It had
occurred to me that this might be a problem but it so happened that I
did not think through the tests adequately.
The patch implements what is described in the previous paragraph and
the testcase is that from the reporter.
Regtested on Cygwin_NT/amd64 - OK for trunk, 4.2 and 4.1?
Paul
2006-11-14 Paul Thomas <pault@gcc.gnu.org>
PR fortran/29820
* trans-array.c (gfc_get_derived_type): Once done, spread the
backend_decl
to all identical derived types in all sibling namespaces.
2006-11-14 Paul Thomas <pault@gcc.gnu.org>
PR fortran/29820
* gfortran.dg/used_types_13.f90: New test.
Index: gcc/fortran/trans-types.c
===================================================================
*** gcc/fortran/trans-types.c (revision 118704)
--- gcc/fortran/trans-types.c (working copy)
*************** gfc_get_derived_type (gfc_symbol * deriv
*** 1592,1602 ****
other_equal_dts:
/* Add this backend_decl to all the other, equal derived types and
their components in this and sibling namespaces. */
!
! for (dt = derived->ns->derived_types; dt; dt = dt->next)
! copy_dt_decls_ifequal (derived, dt->derived);
!
! for (ns = derived->ns->sibling; ns; ns = ns->sibling)
for (dt = ns->derived_types; dt; dt = dt->next)
copy_dt_decls_ifequal (derived, dt->derived);
--- 1592,1599 ----
other_equal_dts:
/* Add this backend_decl to all the other, equal derived types and
their components in this and sibling namespaces. */
! ns = derived->ns->parent ? derived->ns->parent->contained : derived->ns;
! for (; ns; ns = ns->sibling)
for (dt = ns->derived_types; dt; dt = dt->next)
copy_dt_decls_ifequal (derived, dt->derived);
Index: gcc/testsuite/gfortran.dg/used_types_13.f90
===================================================================
*** gcc/testsuite/gfortran.dg/used_types_13.f90 (revision 0)
--- gcc/testsuite/gfortran.dg/used_types_13.f90 (revision 0)
***************
*** 0 ****
--- 1,28 ----
+ ! { dg-do compile }
+ ! Tests the fix for PR29820, which was another problem with derived type
+ ! association. Not all siblings were being searched for identical types.
+ !
+ ! Contributed by Harald Anlauf <anlauf@gmx.de>
+ !
+ module geo
+ type geodetic
+ real :: h
+ end type geodetic
+ end module geo
+ module gfcbug44
+ implicit none
+ contains
+ subroutine point ( gp)
+ use geo
+ type(geodetic), intent(out) :: gp
+ type(geodetic) :: gpx(1)
+ gp = gpx(1)
+ end subroutine point
+ subroutine plane ()
+ use geo
+ type(geodetic) :: gp
+ call point ( gp)
+ end subroutine plane
+ end module gfcbug44
+ ! { dg-final { cleanup-modules "geo gfcbug44" } }
+