diff mbox

[Fortran,pr64589,v1,OOP] Linking error due to undefined integer symbol with unlimited polymorphism

Message ID 20150713110301.68c90b82@vepi2
State New
Headers show

Commit Message

Andre Vehreschild July 13, 2015, 9:03 a.m. UTC 
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 <mikael.morin@sfr.fr> 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
diff mbox

Patch

Index: gcc/fortran/ChangeLog
===================================================================
--- gcc/fortran/ChangeLog	(Revision 225729)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,9 @@ 
+2015-07-13  Andre Vehreschild  <vehre@gcc.gnu.org>
+
+	PR fortran/64589
+	* class.c (find_intrinsic_vtab): Put/Search vtabs for intrinsic
+	types in the top-level namespace.
+
 2015-07-12  Aldy Hernandez  <aldyh@redhat.com>
 
 	* 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  <vehre@gcc.gnu.org>
+
+	PR fortran/64589
+	* gfortran.dg/pr64589.f90: New test.
+
 2015-07-13  Renlin Li  <renlin.li@arm.com>
 
 	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  <damian@sourceryinstitute.org>
+
+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
+