similar to: [LLVMdev] thread_local

Hello, Bram > This weekend, I've noticed that GlobalVariable's could be declared as > thread-local in LLVM 2.0. However, when using it on a small example > (OSX), I got the following error: Unfortunately, TLS stuff is currently only (probably) supported on X86 and ARM. Nobody tried to implement it on PPC. -- With best regards, Anton Korobeynikov. Faculty of Mathematics

Hi all, I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise? Thanks in advance. Details are as

On Mon, Feb 22, 2016 at 3:32 PM Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Jan 25, 2016 at 07:57:43PM +0000, Tim Shen via llvm-dev wrote: > > A cleaner solution could be adding an IR intrinsic llvm.get_tcb_address() > > and hard code the offset of stack_guard member, since they aren't > supposed > > to change. > > It

Hello, I apologize if this has already been fixed or reported. I believe there is a bug in the way the optimizer deals with thread_local variables. The attached program, test.c, has a thread-local variable "int Foo" and a global variable "int *Ptr". The program takes the following steps: 1) The main thread spawns a new thread and waits 2) The new thread writes Foo = 50 and

Hi LLVM, I am using 3.0, and I have a question about the __thread in c and thread_local in LLVM IR: O1-O4 and the final linked code behave differently. //////////////////////////////////// The following C code is from the LLVM testcase (SingleSource/UnitTests/Threads/2010-12-08-tls.c) #include <stdio.h> __thread int a = 4; int foo (void) { return a; } int main (void) {

On Mon, Feb 22, 2016 at 5:00 PM Eric Christopher <echristo at gmail.com> wrote: > Yeah, for most of the architectures listed there it's not particularly > useful as they support direct access to TLS variables (as Joerg says > later). That grep isn't representative of how the data is actually > accessed. If the current address space way of specifying isn't doable on

Hi, Op 18-mei-07, om 10:10 heeft Tanya M. Lattner het volgende geschreven: >> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build >> with the header files using uintptr_t (not recognised as a type). >> Putting "#include <stdint.h>" in include/llvm/BasicBlock.h (llvm) >> and in "include/llvm/ValueSymbolTable.h" (frontend)

Do you have a verify option in your loaded module? Reid. On Sun, 2006-08-20 at 22:04 +0200, Bram Adams wrote: > Hi, > > Op 20-aug-06, om 21:18 heeft Reid Spencer het volgende geschreven: > > > I looked over your patch and it looks good. I applied a patch based on > > yours. The llvm-ld tool now uses the PluginLoader just like the opt > > tool. It will also run

> I note also that this is not a currently unsupported target case where an error should/could/would be produced on attempting to emit code with thread local references. I say this because clang is able to compile both c source with __thread on a global and bc containing a @variable = thread_local global ... and a function that references the thread local global variable to both assembly and

Hello > I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise? Thanks for the report. Should be

Thanks for the quick reply and fix. Now it just means I have to hunt further in exploring why, in my simple test program, replacing the following line of code: GlobalVariable* global = new GlobalVariable(*MyModule, IntegerType::get(getGlobalContext(), 32), false, GlobalValue::ExternalLinkage, 0, "global"); with the following line of code: GlobalVariable* global = new

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Tom Bergan > Subject: [LLVMdev] Bug Report -- Possible optimizer bug with thread_local variables > my current workaround is to declare Ptr volatile: >    int * volatile Ptr; > Note that if the volatile is moved under the pointer, as in the following: >    volatile int * Ptr; >

hi guys, i wrote a small program that can load the *.ll file, parse it and execute it. but there is a thread_local global variable. during execution, it says: Cannot allocate thread local storage on this arch! UNREACHABLE executed at /root/llvm/lib/Target/X86/X86JITInfo.cpp:585!. it seems that i did not initialize the executionEngine right or i shouldnot use InitializeNativeTarget()? i

Hi, There is a typo in $LLVM_SRC/Makefile.rules on line 750 where it says : SharedLibKindMessage := "Lodable Module" instead of SharedLibKindMessage := "Loadable Module" Op 15-nov-06, om 15:54 heeft Bram Adams het volgende geschreven: > Didn't check > LLVM's test suite. Doing the simple LLVM-tests (on Slackware 10.2) gets: === Summary ===

Hi, Op 20-aug-06, om 21:18 heeft Reid Spencer het volgende geschreven: > I looked over your patch and it looks good. I applied a patch based on > yours. The llvm-ld tool now uses the PluginLoader just like the opt > tool. It will also run some cleanup passes after the loaded plugins > run > to ensure cruft is removed. OK, thanks. Your patch seems to work, although I also get

Hi, Today I managed to link ioquake3, but generating a binary does not work yet. 1) On OSX, I get: Error: Code generator does not support intrinsic function 'llvm.ppc.altivec.lvsl'! when I do: llc file.bc -march=c -o file.c 2) On Linux X86, llc does not give any problem, but I get this while compiling the generated .c file: error: unknown register name 'S' in

I note also that this is not a currently unsupported target case where an error should/could/would be produced on attempting to emit code with thread local references. I say this because clang is able to compile both c source with __thread on a global and bc containing a @variable = thread_local global ... and a function that references the thread local global variable to both assembly and machine

Hi Bram, Could you submit bug reports for all of these problems? Thanks! -bw On 5/29/07, Bram Adams <bram.adams at ugent.be> wrote: > Hi, > > Today I managed to link ioquake3, but generating a binary does not > work yet. > > > 1) On OSX, I get: > > Error: Code generator does not support intrinsic function > 'llvm.ppc.altivec.lvsl'! > > when I

Hi, Op 20-aug-06, om 22:26 heeft Reid Spencer het volgende geschreven: > Do you have a verify option in your loaded module? What exactly do you mean by "verify option"? Anyway, I did a grep on "verify" in my code, but found nothing. Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium)

Hi, Op 15-nov-06, om 03:26 heeft Tanya M. Lattner het volgende geschreven: > I'm able to reproduce this if I skip doing a "make" and directly do a > "make install" after configuring. I believe we require people to do > a full > build before attempting to install. So I don't think its really a bug. > Could you try doing a make first and then install?