Bug 46448 - [4.6 Regression] [OOP] symbol `__copy_...' is already defined
Summary: [4.6 Regression] [OOP] symbol `__copy_...' is already defined
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P4 normal
Target Milestone: 4.6.0
Assignee: janus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-12 09:26 UTC by janus
Modified: 2011-01-04 13:05 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-01-03 12:12:22


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description janus 2010-11-12 09:26:20 UTC
Simple test case:


module m0
  type :: t
  end type
end module 

module m1
  use m0
  class(t), pointer :: c1
end module

module m2
  use m0
  class(t), pointer :: c2
end module

end


This currently fails with:

/tmp/cciKD2sS.s: Assembler messages:
/tmp/cciKD2sS.s:72: Error: symbol `__copy_m0_t_' is already defined


The test case works with 4.5. The error is a regression of my recent "polymorphic deep copy" patch:

http://gcc.gnu.org/viewcvs?view=revision&revision=166368


I think this is the same issue as the one reported by Salvatore here:

http://gcc.gnu.org/ml/fortran/2010-11/msg00205.html
Comment 1 Salvatore Filippone 2010-11-12 10:05:38 UTC
(In reply to comment #0)
>
> /tmp/cciKD2sS.s: Assembler messages:
> /tmp/cciKD2sS.s:72: Error: symbol `__copy_m0_t_' is already defined
> 
> 
> The test case works with 4.5. The error is a regression of my recent
> "polymorphic deep copy" patch:
> 
> http://gcc.gnu.org/viewcvs?view=revision&revision=166368
> 
> 
> I think this is the same issue as the one reported by Salvatore here:
> 
> http://gcc.gnu.org/ml/fortran/2010-11/msg00205.html


Yup, it's the same kind of problem.
Comment 2 Tobias Burnus 2010-11-12 12:49:47 UTC
I think you should check whether the symbol is already there using the "gsym" (assuming that -fwhole-file is used - but I think that can be assumed ;-).

There should be only one such function per translation unit; it should use everywhere the same decl (UID) and - of course - it should be not exported ('static') such that you can have the same function in multiple translation units. (Which is ugly - best would be to have only once per program, but I think the .mod file is emitted before the CLASS is encountered.)
Comment 3 Salvatore Filippone 2010-12-31 22:52:03 UTC
(In reply to comment #2)
> I think you should check whether the symbol is already there using the "gsym"
> (assuming that -fwhole-file is used - but I think that can be assumed ;-).
> 
> There should be only one such function per translation unit; it should use
> everywhere the same decl (UID) and - of course - it should be not exported
> ('static') such that you can have the same function in multiple translation
> units. (Which is ugly - best would be to have only once per program, but I
> think the .mod file is emitted before the CLASS is encountered.)

I just discovered that changing the order of some USE statements in one intermediate module makes the extra __copy symbol disappear. 
While it's a nice workaround, it's a bit suspicious.....
Comment 4 janus 2011-01-03 12:12:22 UTC
Got a patch. Regtesting right now ...
Comment 5 janus 2011-01-04 12:59:26 UTC
Author: janus
Date: Tue Jan  4 12:59:23 2011
New Revision: 168464

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168464
Log:
2011-01-04  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46448
	* class.c (gfc_find_derived_vtab): Set the module field for the copying
	routine to make sure it receives module name mangling.


2011-01-04  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46448
	* gfortran.dg/class_34.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/class_34.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/class.c
    trunk/gcc/testsuite/ChangeLog
Comment 6 janus 2011-01-04 13:05:47 UTC
Fixed with r168464. Closing.