GCC Bugzilla Bug 25908

I use gcc (GCC) 4.2.0 20060120 to compile Cactus, a large piece of code
combining C, C++, and Fortran.  I receive many errors from the linker like

/usr/bin/ld: multiple definitions of symbol typeinfo for MPI::Op
/Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_Carpet.a(helpers.cc.o)
definition of typeinfo for MPI::Opin section (__DATA,__const)
/Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_CarpetAdaptiveRegrid.a(CAR.cc.o)
definition of typeinfo for MPI::Opin section (__DATA,__const)

or

/usr/bin/ld: multiple definitions of symbol vtable for MPI::Op
/Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_Carpet.a(helpers.cc.o)
definition of vtable for MPI::Opin section (__DATA,__const)
/Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_CarpetAdaptiveRegrid.a(CAR.cc.o)
definition of vtable for MPI::Opin section (__DATA,__const)

(Note that the error messages seem run-together; e.g. "MPI::OPin" seems to
refer to the class "MPI::Op", which is located IN a certain section.)

These errors are not there with gcc (GCC) 4.2.0 20051129.  The code also works
fine on many other architectures.  But with C++, I am not sure what the reason
is.

I have looked on the web, and the gcc PR "[Bug c++/16218] Link problems with
inline virtual function in multiple translation units" seems similar.  At that
time, it apparently was an error in gcc that caused this problem.



I use the linker /usr/bin/ld
Apple Computer, Inc. version cctools-590.18.obj~10

and these C++ classes are defined in LAM MPI 7.0.6-11, which I installed via
fink.

Do you have a simple example?

Here is a way to reproduce the error with very little source code, but still
depending on the LAM MPI library.  The actual source code I used consists of
two files, main.cc and sub.cc, which I include here for completeness:

main.cc:
#include <mpi.h>

int
main (int argc, char * argv[])
{
  return 0;
}

sub.cc:
#include <mpi.h>

void
sub ()
{
}



I preprocessed these with "g++ -E", and I attach the results.  When I compile
the preprocessed sources, I get:

$ ~/gcc-new/bin/g++ -o lamtest main.ii sub.ii
/usr/bin/ld: multiple definitions of symbol typeinfo for MPI::Op
/var/tmp//ccFSbBVd.o definition of typeinfo for MPI::Opin section
(__DATA,__const)
/var/tmp//cc8Rm38U.o definition of typeinfo for MPI::Opin section
(__DATA,__const)
/usr/bin/ld: multiple definitions of symbol typeinfo for PMPI::Op
/var/tmp//ccFSbBVd.o definition of typeinfo for PMPI::Opin section
(__DATA,__const)
/var/tmp//cc8Rm38U.o definition of typeinfo for PMPI::Opin section
(__DATA,__const)
/usr/bin/ld: multiple definitions of symbol typeinfo for PMPI::Comm
/var/tmp//ccFSbBVd.o definition of typeinfo for PMPI::Commin section
(__DATA,__const)
/var/tmp//cc8Rm38U.o definition of typeinfo for PMPI::Commin section
(__DATA,__const)

(and many more warnings like that).

Created an attachment (id=10715) [edit]
Gzipped preprocessed failing source code, part 1

Created an attachment (id=10716) [edit]
Gzipped preprocessed failing source code, part 2

I think that is enough to reproduce it for now.

Thanks, when my computer (laptop) gets back up and working, I will look into
this.

I think this was caused by the section changes.

Trying to reduce this failure.  (I can reproduce it on today's compiler).

Reduced testcase:
file1.cc:
class f
{
  virtual void g();
};
inline void f::g()
{}
int sub(void)
{}
file2.cc:
class f
{
  virtual void g();
};
inline void f::g()
{}
int main(void)
{}


------

Now why does this work if I add inline to the method inside the declaration of
the class.

Hmm, this testcase works correctly on x86_64-linux-gnu, in that the vtable is
marked as weak.

Just to clarify with "gcc (GCC) 4.2.0 20051129", you were able to compile the
example you gave in comment #2?

Yes, I am able to compile the code with that version:

$ ~/gcc/bin/g++ --version
g++ (GCC) 4.2.0 20051129 (experimental)

$ ~/gcc/bin/g++ -o lamtest *.ii -L/sw/lib -llammpio -llammpi++ -lmpi -llam

It was broken before "20051231".  So we are done to a month.

It worked in "20051203".

It was broken in "20051217". so only two weeks now.

Nathan sorry for CCing you (that was accident).

Fails in "20051210".

Before the breakage:
        .globl __ZTV1f
        .weak_definition __ZTV1f
        .section __DATA,__const_coal,coalesced

After:
        .globl __ZTV1f
        .const_data

We are doing two things wrong, not marking this as weak and then not putting it
into the coalesced section.

Caused by:
        (machopic_select_section): Return the selected section rather than
        emitting assembly code.  Replace the static function table with
        inline conditional expressions.  Update the tests of last_text_section
        and move them into the FUNCTION_DECL block.


I have to figure out why.

Or maybe not.  More likely the TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT changes.

I might need some C++ help on this one but I think this is valid as the virtual
function is marked as inline so it is vague but can that be a key function?

Found the problem and a way to fix it.  The problem is that the key function
needs to be changed to the  arm-eabi way and not the IA64 C++ ABI way.

See http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02645.html for the ARM-eabi
way.

To remind me, I should enable g++.dg/abi/key1.C on *-darwin.

Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01843.html

I am no longer going to work on this, it is too much hassle for me to get this
fixed.

Submitted patch to fix this
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01705.html

Subject: Bug 25908

Author: mrs
Date: Thu Mar  2 02:20:54 2006
New Revision: 111632

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111632
Log:
        PR darwin/25908
        * decl2.c (import_export_decl): Fix ABI breakage on darwin.

        * g++.dg/abi/key2.C: Add.

Added:
    trunk/gcc/testsuite/g++.dg/abi/key2.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl2.c
    trunk/gcc/testsuite/ChangeLog

Fixed, thanks Mike for fixing this one.