search for: tu2

...sion to the following testcase: struct S { static const int x; }; template<typename T> struct U { static const int k; }; template<typename T> const int U<T>::k = T::x; #ifdef TU1 extern int 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 = we...

...{ static const int x; }; > template<typename T> struct U { static const int k; }; > template<typename T> const int U<T>::k = T::x; > > #ifdef TU1 > extern int 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...

...te<typename T> struct U { static const int k; }; >> template<typename T> const int U<T>::k = T::x; >> >> #ifdef TU1 >> extern int 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.....

...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 0, comdat _ZN1UI1SE1kE > ... > @llvm.global_ctors = .... > define internal void @_GLOBAL__I_a() nounwind section ".text.startup...

...with some toy examples and got stuck on the very beginning not being able to figure out where the unused functions are actually getting removed. Here is what I did: tu1.cpp: int unused(int a); int probably_inlined(int a); int main(int argc, const char *argv[]) { return probably_inlined(argc); } tu2.cpp: int unused(int a) { return a + 1; } int probably_inlined(int a) { return a + 2; } I produced two object files with bitcode: clang -c -flto tu1.cpp -o tu1.o And I run LTO and attempted to dump the IR before each pass: clang -O2 -Wl,-mllvm -Wl,-print-before-all tu1.o tu2.o -o optimized In...

...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 0, comdat _ZN1UI1SE1kE ... @llvm.global_ctors = .... define internal void @_GLOBAL__I_a() nounwind section ".text.startup" .... ------------------...

...nstant 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. Unfortunately, making the comdat be for the entire function is not conformant with the ABI, which says that you either put the variable and its guard in different comdats or you put them in a single comdat named for the variable. It also doesn't actually help unless we disable inlining. So...

...unused functions are >> actually getting removed. >> >> Here is what I did: >> tu1.cpp: >> int unused(int a); >> int probably_inlined(int a); >> int main(int argc, const char *argv[]) { >> return probably_inlined(argc); >> } >> >> tu2.cpp: >> int unused(int a) { >> return a + 1; >> } >> int probably_inlined(int a) { >> return a + 2; >> } >> >> I produced two object files with bitcode: >> clang -c -flto tu1.cpp -o tu1.o >> >> And I run LTO and attempted to dump...

...struct S { static const int x; }; template<typename T> struct U { static const int k; }; template<typename T> const int U<T>::k = T::x; #ifdef TU1 extern int f(); const int S::x = 42; int main() { return f() + reinterpret_cast<long>(&U<S>::k); } #endif #ifdef TU2 int f() { return U<S>::k; } #endif and it crashes with gcc too :-( The original testcase works because gcc folds the value into main even at -O0. If we are going to support it for real, I think Richard patch is going on the right direction, but we should completely drop the idea of a "...

...t; 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 anything like COMDAT, but the Darwin linker > apparently gives significantly stronger guarantees about which object > files it will take symbols from, as long as all objects have all of the > symbols. > > John. Cheers, Rafael

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

...> struct U { >  static const int k; > }; > template<typename T> const int U<T>::k = T::x; > > #ifdef TU1 > extern int f(); > const int S::x = 42; > int main() { >  return f() + reinterpret_cast<long>(&U<S>::k); > } > #endif > #ifdef TU2 > int f() { return U<S>::k; } > #endif > > and it crashes with gcc too :-( The original testcase works because > gcc folds the value into main even at -O0. > > If we are going to support it for real, I think Richard patch is going > on the right direction, but we shoul...

Hi, I have server with multiple virtual domains and this server also accepts mail for the local domain. I'm using postfix and have the following setup for a virtual sales at domain.com mapped to custsales at localhost I was wondering if there is a way to login with the virtual email address, for example sales at domain.com? I would also like to still be able to login with the local user

...or 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 0, comdat _ZN1UI1SE1kE > ... > @llvm.global_ctors = .... > define internal void @_GLOBAL__I_a() nounwind section ".text.startup...

...ic const int k; >> }; >> template<typename T> const int U<T>::k = T::x; >> >> #ifdef TU1 >> extern int f(); const int S::x = 42; int main() {  return f() + >> reinterpret_cast<long>(&U<S>::k); >> } >> #endif >> #ifdef TU2 >> int f() { return U<S>::k; } #endif >> >> >> and it crashes with gcc too :-( The original testcase works because gcc >> folds the value into main even at -O0. Indeed, I filed gcc bug#50968 for this last week. >> If we are going to support it for real, I...

> >> On 2016-Apr-15, at 17:12, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> >> On Fri, Apr 15, 2016 at 4:04 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> >> > On 2016-Apr-15, at 14:53, David Blaikie <dblaikie at gmail.com> wrote: >> > >> > >> > >> >> On Fri, Apr