search for: _zn1ui1se1ke

...eeds to be extended. So far we just create trivial COMDATs in codegen > for weak objects. > > We also need the IL linker itself needs to work on COMDATs too > otherwise this bug would still exist when doing LTO. > > In the "extended" example we would output > > @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE > > for TU1 and > > @_ZN1UI1SE1kE = weak_odr global i32 0, align 4, comdat _ZN1UI1SE1kE > ... > define internal void @_GLOBAL__I_a() nounwind section ".text.startup" > comdat _ZN1UI1SE1kE { > .... > } &...

...fferent comdats or you put them in a single comdat > named for the variable.  It also doesn't actually help unless we disable > inlining. I see. Using two comdats would still cause the same problem for us, no? So the solution in the end is to emit: TU1: -------------------------------- @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE @_ZGVN1UI1SE1kE = weak_odr global i64 1, comdat _ZN1UI1SE1kE -------------------------------- TU2: ----------------------------------- @_ZN1UI1SE1kE = weak_odr global i32 0, align 4, comdat _ZN1UI1SE1kE @_ZGVN1UI1SE1kE = weak_odr global i64...

...basic support for COMDATs, but yes, it needs to be extended. So far we just create trivial COMDATs in codegen for weak objects. We also need the IL linker itself needs to work on COMDATs too otherwise this bug would still exist when doing LTO. In the "extended" example we would output @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE for TU1 and @_ZN1UI1SE1kE = weak_odr global i32 0, align 4, comdat _ZN1UI1SE1kE ... define internal void @_GLOBAL__I_a() nounwind section ".text.startup" comdat _ZN1UI1SE1kE { .... } for TU2. > Mach-O doesn't support any...

> I see. Using two comdats would still cause the same problem for us, > no? So the solution in the end is to emit: > > TU1: > -------------------------------- > @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE > @_ZGVN1UI1SE1kE = weak_odr global i64 1, comdat _ZN1UI1SE1kE > -------------------------------- > > TU2: > ----------------------------------- > @_ZN1UI1SE1kE = weak_odr global i32 0, align 4, comdat _ZN1UI1SE1kE > @_ZG...

...t f(); const int S::x = 42; int main() { return f() + U<S>::k; } #endif #ifdef TU2 int f() { return U<S>::k; } #endif /* Steps to repro: clang repro.cpp -DTU1 -c -o tu1.o clang repro.cpp -DTU2 -c -o tu2.o clang tu1.o tu2.o ./a.out */ This segfaults, because... in TU1, we get: @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4 and in TU2, we get: @_ZN1UI1SE1kE = weak_odr global i32 0, align 4 plus a global constructor which writes to @_ZN1UI1SE1kE. The linker then selects the symbol from TU1, which ends up in a read-only section, resulting in the binary crashing when TU2 tries to...

On Nov 7, 2011, at 9:47 AM, Richard Smith wrote: >> In cases where the C++ standard requires static initialization, >> introducing a write violates the guarantees of the C++ standard for static >> initialization. Therefore, I'm not sure the whole "make the constant >> writable" approach is actually viable. > > There is another problem which afflicts

...if > > #ifdef TU2 > int f() { return U<S>::k; } > #endif > > /* Steps to repro: > > clang repro.cpp -DTU1 -c -o tu1.o > clang repro.cpp -DTU2 -c -o tu2.o > clang tu1.o tu2.o > ./a.out > > */ > > This segfaults, because... in TU1, we get: > > @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4 > > and in TU2, we get: > > @_ZN1UI1SE1kE = weak_odr global i32 0, align 4 > > plus a global constructor which writes to @_ZN1UI1SE1kE. The linker then > selects the symbol from TU1, which ends up in a read-only section, resulting > in the...

...comdat >> named for the variable. It also doesn't actually help unless we disable >> inlining. > > I see. Using two comdats would still cause the same problem for us, > no? So the solution in the end is to emit: > > TU1: > -------------------------------- > @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE > @_ZGVN1UI1SE1kE = weak_odr global i64 1, comdat _ZN1UI1SE1kE > -------------------------------- > > TU2: > ----------------------------------- > @_ZN1UI1SE1kE = weak_odr global i32 0, align 4, comdat _ZN1UI1SE1kE > @_Z...

...::k; } >> #endif >> >> /* Steps to repro: >> >> clang repro.cpp -DTU1 -c -o tu1.o >> clang repro.cpp -DTU2 -c -o tu2.o >> clang tu1.o tu2.o >> ./a.out >> >> */ >> >> This segfaults, because... in TU1, we get: >> >> @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4 >> >> and in TU2, we get: >> >> @_ZN1UI1SE1kE = weak_odr global i32 0, align 4 >> >> plus a global constructor which writes to @_ZN1UI1SE1kE. The linker then >> selects the symbol from TU1, which ends up in a read-only se...