After a fresh fortran-dev checkout, configure, make, and make install, the first two modules below compile correctly, while the third produces the the compile-time errors shown. The two offending lines are the "allocate" statement and the subsequent pointer assignment, both in the "new_bar" function. Based on the error message, this is related to vtabs. Apparently the error is platform-dependent since Janus reports compiling similar code with no problem. Damian $ cat foo.f03 module foo_module implicit none type foo end type end module $ cat bar.f03 module bar_module use foo_module implicit none type ,extends(foo) :: bar end type contains function bar_() type(bar) ,pointer :: bar_ bar_ => null() end function end module $ cat bar_factory.f03 module bar_factory_module implicit none type bar_factory contains procedure :: new_bar end type contains function new_bar(this) use bar_module use foo_module class(bar_factory), intent(in) :: this class(foo) ,pointer :: new_bar allocate(bar :: new_bar) new_bar => bar_() end function end module $ gfortran -c foo.f03 $ gfortran -c bar.f03 $ gfortran -c bar_factory.f03 /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:37:non-relocatable subtraction expression, "_vtab$bar.1525" minus "L00000000001$pb" /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:37:symbol: "_vtab$bar.1525" can't be undefined in a subtraction expression /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:35:non-relocatable subtraction expression, "_vtab$bar.1525" minus "L00000000001$pb" /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:35:symbol: "_vtab$bar.1525" can't be undefined in a subtraction expression
(In reply to comment #0) > After a fresh fortran-dev checkout, configure, make, and make install, the > first two modules below compile correctly, while the third produces the the > Well, for me it works under linux (fedora 11) on both i686 (32 bits) and x86_64, on a fresh checkout of fortran-dev.
On darwin, the errors appear only in 32 bit mode. I am sure that I have already seen such errors in the past, but I cannot remember where or when!-(
(In reply to comment #2) > On darwin, the errors appear only in 32 bit mode. I am sure that I have already > seen such errors in the past, but I cannot remember where or when!-( > Thanks for all of your help. So how do I switch to 64-bit mode? Damian
(In reply to comment #2) > On darwin, the errors appear only in 32 bit mode. Yes, I can confirm this on x86_64-apple-darwin10.2.0. Also, I just ran the fortran testsuite for the fortran-dev branch on darwin, but saw no failures. Here is a reduced test case: module m implicit none type foo end type type ,extends(foo) :: bar end type contains function new_bar() class(foo) ,pointer :: new_bar allocate(bar :: new_bar) end function end module Important: This only happens inside a module. If I remove the "module m/end module" in the example, the error goes away.
(In reply to comment #3) > So how do I switch to 64-bit mode? On x86_64-apple-darwin* it is the default, so I assume you are using i686-apple-darwin*. In this case you need a "multlib" build and you compile with -m64.
(In reply to comment #5) > (In reply to comment #3) > > So how do I switch to 64-bit mode? > > On x86_64-apple-darwin* it is the default, so I assume you are using > i686-apple-darwin*. In this case you need a "multlib" build and you compile > with -m64. > Switching to x86_64-apple-darwin9 worked! What does the "9" mean? Since I'm running OS X 10.5.8, I first tried "10.5.8" and "10", but neither worked. Damian
Janus, Although the new reduced case compiles fine in 64-bit mode, I run into linking problems as soon as I add "program main; end program" to the end of it: Undefined symbols: "_vtab$bar.1550", referenced from: ___m_MOD_new_bar in ccQEi2ET.o ld: symbol(s) not found collect2: ld returned 1 exit status Looking back through my e-mails, I see that you told me on 11/21 that Paul's TBP patch had not yet been applied to the branch or the trunk. From the above results, I assume that's still the case. Damian (In reply to comment #4) > (In reply to comment #2) > > On darwin, the errors appear only in 32 bit mode. > > Yes, I can confirm this on x86_64-apple-darwin10.2.0. Also, I just ran the > fortran testsuite for the fortran-dev branch on darwin, but saw no failures. > > Here is a reduced test case: > > > module m > > implicit none > > type foo > end type > > type ,extends(foo) :: bar > end type > > contains > > function new_bar() > class(foo) ,pointer :: new_bar > allocate(bar :: new_bar) > end function > > end module > > > Important: This only happens inside a module. If I remove the "module m/end > module" in the example, the error goes away. >
If I run the code in comment 4 with an appended "end" (to make it a complete program), I (still) get link errors: /tmp/cc3J3Ygi.o: In function `__m_MOD_new_bar': aa3.f90:(.text+0x2c): undefined reference to `vtab$bar.1527' That's with trunk 4.6.0 20100803 (Rev. 162828) x86_64-unknown-linux-gnu with both -m32 and -m64 - thus I do not think that this is target dependent. The problem is also obvious: No vtable is created - as mentioned the other day, I think generating the vtable only when using the a polymorphic type - but then initializing it several times - seems to be the wrong approach.
(In reply to comment #8) > If I run the code in comment 4 with an appended "end" (to make it a complete > program), I (still) get link errors: > > /tmp/cc3J3Ygi.o: In function `__m_MOD_new_bar': > aa3.f90:(.text+0x2c): undefined reference to `vtab$bar.1527' > > That's with trunk 4.6.0 20100803 (Rev. 162828) x86_64-unknown-linux-gnu with > both -m32 and -m64 - thus I do not think that this is target dependent. Well, what is target dependent are the funny messages in comment #0, which are only seen on darwin with -m32. For the 'undefined reference' errors we have other PRs in fact (e.g. PR44065).
> Well, what is target dependent are the funny messages in comment #0, which are > only seen on darwin with -m32. I think it is a bogus way to "report" the 'undefined reference'.
(In reply to comment #9) > Well, what is target dependent are the funny messages in comment #0, which are > only seen on darwin with -m32. I have to admit that the -fdump-tree-original-all looks strange to me (third file of comment 0): (struct vtype$foo *) __result_new_barD.1574.$vptrD.1556 = (struct vtype$foo *) &vtab$barD.1584; (struct vtype$foo *) __result_new_barD.1574.$vptrD.1556 = (struct vtype$foo *) &vtab$barD.1584; Why is there a cast on the LHS? (The code might be valid though - am not really a tree expert.)
(In reply to comment #8) > If I run the code in comment 4 with an appended "end" (to make it a complete > program), I (still) get link errors: > > /tmp/cc3J3Ygi.o: In function `__m_MOD_new_bar': > aa3.f90:(.text+0x2c): undefined reference to `vtab$bar.1527' This error can be fixed by: Index: match.c =================================================================== --- match.c (revision 162839) +++ match.c (working copy) @@ -2902,6 +2902,9 @@ gfc_match_allocate (void) &tail->expr->where); goto cleanup; } + + if (ts.type == BT_DERIVED) + gfc_find_derived_vtab (ts.u.derived); } if (tail->expr->ts.type == BT_DERIVED) Disclaimer: I haven't checked this for regressions. And I'm not sure yet if it really is the proper fix for this issue.
(In reply to comment #12) > Disclaimer: I haven't checked this for regressions. And I'm not sure yet if it > really is the proper fix for this issue. The patch fixes the tests in this pr, but not those in pr44065. So far I have regtested the *.f03 files without regression. Further testing in progress. Thanks.
(In reply to comment #12) > > This error can be fixed by: > [...] You may need to change the recently added gfc_commit_symbols in gfc_find_derived_vtabs into a per symbol gfc_commit_symbol (symbol). Otherwise one can error out, but yet commit the symbols. Who knows what can happen then ? ;-)
I don't know if this related to comment #14, but with the patch of comment #12 the errors for the test pr37425#0 has changed from pr37425.f90:7.13: PROCEDURE :: assign_t_from_int 1 Error: Non-polymorphic passed-object dummy argument of 'assign_t_from_int' at (1) pr37425.f90:8.13: PROCEDURE :: equals_t_int 1 Error: Non-polymorphic passed-object dummy argument of 'equals_t_int' at (1) pr37425.f90:22.31: LOGICAL FUNCTION equals_t_int (me, i) 1 Error: First argument of operator interface at (1) must be INTENT(IN) to pr37425.f90:7.13: PROCEDURE :: assign_t_from_int 1 Error: Non-polymorphic passed-object dummy argument of 'assign_t_from_int' at (1) pr37425.f90:8.13: PROCEDURE :: equals_t_int 1 Error: Non-polymorphic passed-object dummy argument of 'equals_t_int' at (1) pr37425.f90:10.30: GENERIC :: OPERATOR(==) => equals_t_int 1 Error: Undefined specific binding 'equals_t_int' as target of GENERIC '==' at (1) pr37425.f90:9.31: GENERIC :: ASSIGNMENT(=) => assign_t_from_int 1 Error: Undefined specific binding 'assign_t_from_int' as target of GENERIC '=' at (1)
(In reply to comment #15) > I don't know if this related to comment #14, but with the patch of comment #12 > the errors for the test pr37425#0 has changed from The patch in comment #12 is actually not the best thing to do. Here is a better patch: Index: gcc/fortran/resolve.c =================================================================== --- gcc/fortran/resolve.c (revision 162840) +++ gcc/fortran/resolve.c (working copy) @@ -6508,6 +6508,9 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code } } + if (code->ext.alloc.ts.type == BT_DERIVED) + gfc_find_derived_vtab (code->ext.alloc.ts.u.derived); + if (pointer || (dimension == 0 && codimension == 0)) goto success;
With the patch in comment #16 (and the patches for pr44065 and pr44857) gfortran.dg/typebound_operator_4.f03 fails: 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 and /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_4.f03:89.14: x = x .PLUS. 5 ! { dg-error "Unknown operator" } 1 Error: Unknown operator 'plus' at (1) at the end. I also see the change reported in comment #15.
Two mistakes in comment #17: (1) The extra errors are due to the patch in comment #5 of pr44065. (2) There are only two extra errors at the beginning.
(In reply to comment #16) > Here is a better patch: This patch also fixes the error messages in comment #0 on darwin with -m32.
Subject: Bug 42207 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
Fixed with r162879. Closing.