Hi Mikael, hi everyone,
thanks for the review, Mikael. Commited as r225730.
Regards,
Andre
On Fri, 10 Jul 2015 18:12:53 +0200
Mikael Morin <[email protected]> wrote:
> Le 10/07/2015 16:51, Andre Vehreschild a écrit :
> > Hi everyone,
> >
> > attached is a rather trivial patch to fix a linker issue when unlimited
> > polymorphism is used and the vtabs of intrinsic types are referenced from
> > two different locations (e.g. module and main program). Gfortran finds the
> > vtab defined in the scope of a module's subroutine and tries to link it to a
> > reference in a subroutine of the main program. Then name mangling takes
> > place (the module's name is prefixed to the vtab's identifier) and the
> > linker later on can not link the reference in the subroutine of the main
> > program to the module's entity. By putting the vtabs of all intrinsic types
> > into the top-level scope this is easily fixed. The linker now is able to
> > find the name (although it is mangled) and linking is fine.
> >
> > I rather don't understand why the decision to put intrinsic type's vtabs
> > into the local scope was choosen. There are not so many intrinsic types
> > that they can effectively clutter the top-level scope. Instead putting the
> > intrinsic types into local scope bloats the executable, because the same
> > entity is created over and over again. So this time removing two lines of
> > code did the trick.
> >
> > Bootstraps and regtests fine on x86_64-linux-gnu/f21.
> >
> > Ok for trunk?
> >
> OK. Thanks.
>
> Mikael
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===================================================================
--- gcc/fortran/ChangeLog (Revision 225729)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,9 @@
+2015-07-13 Andre Vehreschild <[email protected]>
+
+ PR fortran/64589
+ * class.c (find_intrinsic_vtab): Put/Search vtabs for intrinsic
+ types in the top-level namespace.
+
2015-07-12 Aldy Hernandez <[email protected]>
* trans-stmt.c: Fix double word typos.
Index: gcc/fortran/class.c
===================================================================
--- gcc/fortran/class.c (Revision 225729)
+++ gcc/fortran/class.c (Arbeitskopie)
@@ -2511,10 +2511,8 @@
sprintf (name, "__vtab_%s", tname);
- /* Look for the vtab symbol in various namespaces. */
- gfc_find_symbol (name, gfc_current_ns, 0, &vtab);
- if (vtab == NULL)
- gfc_find_symbol (name, ns, 0, &vtab);
+ /* Look for the vtab symbol in the top-level namespace only. */
+ gfc_find_symbol (name, ns, 0, &vtab);
if (vtab == NULL)
{
Index: gcc/testsuite/ChangeLog
===================================================================
--- gcc/testsuite/ChangeLog (Revision 225729)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2015-07-13 Andre Vehreschild <[email protected]>
+
+ PR fortran/64589
+ * gfortran.dg/pr64589.f90: New test.
+
2015-07-13 Renlin Li <[email protected]>
PR rtl/66556
Index: gcc/testsuite/gfortran.dg/pr64589.f90
===================================================================
--- gcc/testsuite/gfortran.dg/pr64589.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/pr64589.f90 (Arbeitskopie)
@@ -0,0 +1,30 @@
+! { dg-do compile }
+! Just need to check if compiling and linking is possible.
+!
+! Check that the _vtab linking issue is resolved.
+! Contributed by Damian Rouson <[email protected]>
+
+module m
+contains
+ subroutine fmt()
+ class(*), pointer :: arg
+ select type (arg)
+ type is (integer)
+ end select
+ end subroutine
+end module
+
+program p
+ call getSuffix()
+contains
+ subroutine makeString(arg1)
+ class(*) :: arg1
+ select type (arg1)
+ type is (integer)
+ end select
+ end subroutine
+ subroutine getSuffix()
+ call makeString(1)
+ end subroutine
+end
+
