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 +