[llvmg++] explicit instantiation of static template var does not have weak linkage

[lattner]

Bugzilla Link	480
Resolution	FIXED
Resolved on	Feb 22, 2010 12:41
Version	1.0
OS	All

Extended Description

Take this testcase:

---

struct __Atomicity_lock {
static volatile int _S_atomicity_lock;
};
template
volatile int __Atomicity_lock<__inst>::_S_atomicity_lock = 0;
template volatile int __Atomicity_lock<0>::_S_atomicity_lock;

And compile it with llvmg++. The
_ZN16__Atomicity_lockILi0EE17_S_atomicity_lockE variable gets strong linkage
instead of weak linkage. It's not clear how, but this breaks the libstdc++
build on FreeBSD, but apparently not on other platforms.

-Chris

[llvmbot]

Per Chris' suggestion, simply removing the instantiations of __Atomicity_lock
from the beginning of .../libstdc++-v3/config/cpu/i386/atomicity.h has worked
around things, c.f. the "newly passing tests" section of
http://kinoko.c.u-tokyo.ac.jp/~builddonkey/2004-12-10-20:53:01.html

As for why this happened in the first place, though.. waits quietly 8)

[lattner]

A more interesting question to me is: why doesn't this break all other i386
platforms?

-Chris

[markus-oberhumer]

Note that this bug does indeed affect all i386 platforms, but it only shows up
when configuring for i386 because otherwise a different gcc-libstdc++ header is
used. The default comes from config.guess / uname -m, where most Linux machines
report i586 or i686, but FreeBSD might default to i386.

E.g on Linux, to reproduce configure llvm-gcc with "--build=i386-pc-linux-gnu
--host=i386-pc-linux-gnu --target=i386-pc-linux-gnu".

To work around configure llvm-gcc with "--build=i586-pc-linux-gnu
--host=i586-pc-linux-gnu --target=i586-pc-linux-gnu".

(Side note: if you are not building a cross compiler, it's best to pass 3
identical machine names to gcc's configure).

[markus-oberhumer]

Somewhat unrelated, are there any plans to add an atomic LLVM exchange_and_add
opcode? - it seems it might be needed for correct operation.

[lattner]

Yes, there definitely is. I'll ping the people who are supposed to be working
on it.

-Chris

[lattner]

This is fixed in llvmgcc4.