r218141 - In the Itanium ABI, move stuff to the comdat of variables with static init.

[Rafael Espíndola]

On 17 December 2014 at 15:48, Reid Kleckner <rnk at google.com> wrote:
> Are we sure this is correct? In the motivating example, what if 'f' gets
> inlined? Then 'g' will have the code of 'f' embedded into it, but it will
> not be part of the comdat that statically initializes the guard variable.

I see. The issue is that we produce

$_Z1fv = comdat any
@_ZZ1fvE1y = linkonce_odr global i32 0, comdat $_Z1fv, align 4
@_ZGVZ1fvE1y = linkonce_odr global i64 0, comdat $_Z1fv
define linkonce_odr i32* @_Z1fv() #1 comdat $_Z1fv {

So if f is inlined, g will be using _ZZ1fvE1y and _ZGVZ1fvE1y. In the
TU with the definition of  S::x , the _Z1fv comdat has no guard
variable. If the linker selects that, we get "relocation refers to
discarded section"

Before the patch we would still produce crashing code for the attached
testcase (as does gcc). Just compile/run with

$CXX -c test2.cpp -fPIC
$CXX -c test.cpp -O2 -fPIC
$CXX test2.o test.o -o t
./t

In the end the difference of this case is that f is inlined. It the
case of the static member variable the static init function never is.

The only option I can think of that would wold work is to use comdas
like now, but to always produce a guard variable. So when the variable
is found to be a constant, we would have

@_ZGVZ1fvE1y = linkonce_odr constant i64 1, comadat $_Z1fv

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cpp
Type: text/x-c++src
Size: 158 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141217/6abc5cfe/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.cpp
Type: text/x-c++src
Size: 172 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141217/6abc5cfe/attachment-0001.cpp>