search for: _global__i_a

...oo = global %class.Foo zeroinitializer, align 4 @__dso_handle = external global i8* @.str = private unnamed_addr constant [6 x i8] c"~Foo\0A\00" @.str1 = private unnamed_addr constant [5 x i8] c"Foo\0A\00" @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @_GLOBAL__I_a }] define internal void @__cxx_global_var_init() nounwind section "__TEXT,__StaticInit,regular,pure_instructions" { call void @_ZN3FooC1Ev(%class.Foo* @foo) %1 = call i32 @__cxa_atexit(void (i8*)* bitcast (void (%class.Foo*)* @_ZN3FooD1Ev to void (i8*)*), i8* bitcast (%class.Foo* @foo...

...oo zeroinitializer, align 4 > @__dso_handle = external global i8* > @.str = private unnamed_addr constant [6 x i8] c"~Foo\0A\00" > @.str1 = private unnamed_addr constant [5 x i8] c"Foo\0A\00" > @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @_GLOBAL__I_a }] > > define internal void @__cxx_global_var_init() nounwind section "__TEXT,__StaticInit,regular,pure_instructions" { >  call void @_ZN3FooC1Ev(%class.Foo* @foo) >  %1 = call i32 @__cxa_atexit(void (i8*)* bitcast (void (%class.Foo*)* @_ZN3FooD1Ev to void (i8*)*), i8* bitcast...

...>> from the global ctor in this regard? > > .debug_frame is a non-load section. It is therefore an optimization to > emit it instead of .eh_frame. It is very likely not really a relevant > one, so it might be possible to just always use .eh_frame. > > Not adding uwtable for _GLOBAL__I_a might actually be a bug. I will > check what gcc does. In my experiments GCC /always/ produced eh_frame, never debug_frame, fwiw.

...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. 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 i...

Hi, I'd like to fix PR19590, which is about llvm.global_ctors containing functions that end up being empty after optimization (which causes the linker to add useless init_array entries to the output binary). globalopt removes empty functions from llvm.global_ctors, but by the time the function becomes empty globalopt has already run and it doesn't run again. I'm wondering what the

...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" .... ----------------------------------- > > John. Thanks, Rafael

...n 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 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 h...

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

While comparing debug info between GCC and Clang I found a section that only Clang produces and GCC never produces: debug_frame. It seems (though I haven't verified this with absolute certainty) as though GCC just always uses eh_frame. LLVM on the other hand sometimes uses eh_frame and sometimes uses debug_frame. Here's an example: int f1(); int i = f1(); void func() { } Compiled with

...> -------------------------------- > > 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" .... > ----------------------------------- Restarting a really old thread now that we have comdat support in the IR. While the above idea would work, there are two problems with it * Existing compilers (clang and gcc) produce a comdat with just the...

...Output (stderr): -- /Users/partigas/Desktop/src/llvm/test/Instrumentation/AddressSanitizer/instrument_initializer_metadata.ll:33:10: error: expected string not found in input ; CHECK: call void @__asan_before_dynamic_init ^ <stdin>:20:35: note: scanning from here define internal void @_GLOBAL__I_a() address_safety section ".text.startup" { ^ <stdin>:33:3: note: possible intended match here declare void @__asan_report_load1(i64) ^ -- I presume this is either a bug (as the ordering of the doInitialization/doFinalization per module should not mat...

...Output (stderr): -- /Users/partigas/Desktop/src/llvm/test/Instrumentation/AddressSanitizer/instrument_initializer_metadata.ll:33:10: error: expected string not found in input ; CHECK: call void @__asan_before_dynamic_init ^ <stdin>:20:35: note: scanning from here define internal void @_GLOBAL__I_a() address_safety section ".text.startup" { ^ <stdin>:33:3: note: possible intended match here declare void @__asan_report_load1(i64) ^ -- I presume this is either a bug (as the ordering of the doInitialization/doFinalization per module should not m...

...gt; -------------------------------- > > 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" .... > ----------------------------------- Exactly. To sketch out the proposed IR extension a bit more: 1. We add 'comdat "name"' to the global variable and function productions. I have the COMDAT name in quotes only because ther...

...Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff98ba8d46 __kill + 10 1 libsystem_c.dylib 0x00007fff99668df0 abort + 177 2 libsystem_c.dylib 0x00007fff9963c9b9 free + 392 3 libLLVM-3.3.dylib 0x000000010c06fb4c _GLOBAL__I_a + 412 4 dyld 0x00007fff6579b378 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 236 5 dyld 0x00007fff6579b762 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 46 6 dyld...

Looking at the existing flow of passes for LTO, it appears that most all passes are run on a per file basis, before the call to the gold linker. I'm looking to get people's feedback on whether there would be an advantage to waiting to run a number of these passes until the linking stage. For example, I believe I saw a post a little while back about postponing vectorization until the