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.mo...@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
--
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 ve...@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 al...@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 ve...@gcc.gnu.org
+
+ PR fortran/64589
+ * gfortran.dg/pr64589.f90: New test.
+
2015-07-13 Renlin Li renlin...@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 dam...@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
+
