Bug 44065 - [OOP] Undefined reference to vtab$...
Summary: [OOP] Undefined reference to vtab$...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: 4.6.0
Assignee: janus
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2010-05-10 17:16 UTC by PierreC
Modified: 2016-11-16 13:26 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-08-03 16:37:14


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description PierreC 2010-05-10 17:16:51 UTC
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
Comment 1 Dominique d'Humieres 2010-05-10 17:32:28 UTC
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.
Comment 2 janus 2010-05-10 22:06:33 UTC
Confirmed.

Compiling via ...

gfortran-4.6 -c module.f90
gfortran-4.6 test.f90 

... works, though.
Comment 3 janus 2010-06-06 03:37:51 UTC
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)
Comment 4 janus 2010-07-17 08:49:14 UTC
Another failing example was reported by Andrew Benson in

http://gcc.gnu.org/ml/fortran/2010-07/msg00222.html
Comment 5 janus 2010-08-03 16:37:14 UTC
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];
Comment 6 janus 2010-08-03 16:44:03 UTC
(In reply to comment #5)
> Comment #3 is fixed by:

I think it also fixes comment #4.
Comment 7 janus 2010-08-03 16:54:10 UTC
At r162840, comment #0 seems to work already without any patching. Pierre, can you confirm that?
Comment 8 Dominique d'Humieres 2010-08-03 17:00:21 UTC
> 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?).
Comment 9 Dominique d'Humieres 2010-08-03 18:56:49 UTC
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.
Comment 10 janus 2010-08-04 08:32:04 UTC
(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;
 
Comment 11 janus 2010-08-04 19:49:39 UTC
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

Comment 12 janus 2010-08-04 20:05:11 UTC
r162879 seems to fix all the test cases for me. Can anyone confirm that comment #0 works now without any linking errors?
Comment 13 Dominique d'Humieres 2010-08-04 22:58:54 UTC
> 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.
Comment 14 janus 2010-08-05 11:58:14 UTC
(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.