In the following testcase (tested against 4.6), a procedure bound to an attribute of a super class is not resolved in the subclass. The test case below doesn't go through the linker. The error message is: > gfortran -c -ffree-form module.f test.f > gfortran -o test test.o module.o module.o: In function `__module_mysubclass_MOD_init': module.f:(.text+0x19): undefined reference to `vtab$inner.1586' module.f:(.text+0x25): undefined reference to `vtab$inner.1586' module.f:(.text+0x2e): undefined reference to `vtab$inner.1586' collect2: ld a retourné 1 code d'état d'exécution (note that combining the two following files into a single one creates a segfault #44064) file module.f: module module_myclass implicit none type :: inner contains procedure :: set end type inner type :: myclass type(inner) :: slice end type myclass contains subroutine set(this) class(inner), intent(inout) :: this end subroutine set end module module_myclass module module_mysubclass use module_myclass, only : myclass implicit none type, extends(myclass) :: mysubclass contains procedure :: init end type mysubclass contains subroutine init(this) class(mysubclass), intent(inout) :: this call this%slice%set() ! XXX PROBLEM HERE this%slice not resolved end subroutine init end module module_mysubclass and file test.f: program test use module_mysubclass, only : mysubclass implicit none class(mysubclass), allocatable :: obs end program test
On x86_64-apple-darwin10, I do not see any difference between this PR and pr44064. On powerpc-apple-darwin9, I get the errors reported in pr44064#c2 when compiling the module file.
Confirmed. Compiling via ... gfortran-4.6 -c module.f90 gfortran-4.6 test.f90 ... works, though.
Here is a related test case (by Salvatore): module s_mat_mod implicit none type :: s_sparse_mat end type contains subroutine s_set_triangle(a) class(s_sparse_mat), intent(inout) :: a end subroutine end module module s_tester implicit none contains subroutine s_ussv_2 use s_mat_mod type(s_sparse_mat) :: a call s_set_triangle(a) end subroutine end module end This gives: /tmp/ccUws0SU.o: In function `__s_tester_MOD_s_ussv_2': testd17.f03:(.text+0x13): undefined reference to `vtab$s_sparse_mat.1564' (when compiled in one file)
Another failing example was reported by Andrew Benson in http://gcc.gnu.org/ml/fortran/2010-07/msg00222.html
Comment #3 is fixed by: Index: gcc/fortran/interface.c =================================================================== --- gcc/fortran/interface.c (revision 162839) +++ gcc/fortran/interface.c (working copy) @@ -1423,6 +1423,9 @@ compare_parameter (gfc_symbol *formal, gfc_expr *a && actual->ts.u.derived && actual->ts.u.derived->ts.is_iso_c) return 1; + if (formal->ts.type == BT_CLASS) + gfc_find_derived_vtab (formal->ts.u.derived); + if (actual->ts.type == BT_PROCEDURE) { char err[200];
(In reply to comment #5) > Comment #3 is fixed by: I think it also fixes comment #4.
At r162840, comment #0 seems to work already without any patching. Pierre, can you confirm that?
> At r162840, comment #0 seems to work already without any patching. Pierre, can > you confirm that? Not for me at -O0 (patch not applied), but it works at -O[123s] (probably _vtab$s_sparse_mat.1569 is optimized away?).
With the patch in comment #5 there is one regression: FAIL: gfortran.dg/typebound_operator_4.f03 -O (test for excess errors) the extra errors are: /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_4.f03:73.7: USE m 1 Error: Invalid expression in the derived type constructor for pointer component '$extends' at (1) in PURE procedure /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_4.f03:73.7: USE m 1 Error: Invalid expression in the derived type constructor for pointer component '$extends' at (1) in PURE procedure at the beginning of the error list.
(In reply to comment #9) > With the patch in comment #5 there is one regression: > > FAIL: gfortran.dg/typebound_operator_4.f03 -O (test for excess errors) > > the extra errors are: > > /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_4.f03:73.7: > > USE m > 1 > Error: Invalid expression in the derived type constructor for pointer component > '$extends' at (1) in PURE procedure This regression can be fixed by: Index: gcc/fortran/resolve.c =================================================================== --- gcc/fortran/resolve.c (revision 162842) +++ gcc/fortran/resolve.c (working copy) @@ -12320,6 +12323,10 @@ gfc_impure_variable (gfc_symbol *sym) gfc_symbol *proc; gfc_namespace *ns; + if (sym->attr.vtab) + return 0; + if (sym->attr.use_assoc || sym->attr.in_common) return 1;
Subject: Bug 44065 Author: janus Date: Wed Aug 4 19:49:19 2010 New Revision: 162879 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162879 Log: 2010-08-04 Janus Weil <janus@gcc.gnu.org> PR fortran/42207 PR fortran/44064 PR fortran/44065 * class.c (gfc_find_derived_vtab): Do not generate vtabs for class container types. Do not artificially increase refs. Commit symbols one by one. * interface.c (compare_parameter): Make sure vtabs are present before generating module variables. * resolve.c (resolve_allocate_expr): Ditto. 2010-08-04 Janus Weil <janus@gcc.gnu.org> PR fortran/42207 PR fortran/44064 PR fortran/44065 * gfortran.dg/class_25.f03: New. * gfortran.dg/class_26.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_25.f03 trunk/gcc/testsuite/gfortran.dg/class_26.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
r162879 seems to fix all the test cases for me. Can anyone confirm that comment #0 works now without any linking errors?
> r162879 seems to fix all the test cases for me. Can anyone confirm that comment > #0 works now without any linking errors? On x86_64-apple-darwin10.4.0 at r162881, I have tested all the codelets I have for the PRs fixed by r162879 with both -m32 and -m64 without linking error.
(In reply to comment #13) > On x86_64-apple-darwin10.4.0 at r162881, I have tested all the codelets I have > for the PRs fixed by r162879 with both -m32 and -m64 without linking error. Great. So I guess we can close this PR.