similar to: [LLVMdev] Bug Report -- Possible optimizer bug with thread_local variables

Hi Tom, On Wed, Nov 7, 2012 at 11:43 PM, Tom Bergan <tbergan at cs.washington.edu> wrote: > 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".

On Fri, Nov 9, 2012 at 11:23 AM, Hans Wennborg <hans at chromium.org> wrote: > Hi Tom, > > On Wed, Nov 7, 2012 at 11:43 PM, Tom Bergan <tbergan at cs.washington.edu> > wrote: > > 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

On Fri, Nov 9, 2012 at 4:54 PM, Tom Bergan <tbergan at cs.washington.edu> > The bug manifests > more simply if the variables "Ptr" and "Foo" are declared static -- in this > case, the bug is demonstrated directly with "clang -O3". > > Attached are three files: > * test.c, which is the same as the old test.c, but with "Ptr" and

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

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) {

> 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

Hi, 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: ========= Cannot yet select: 0x56059f0: i32 = GlobalTLSAddress <i32* @a> 0 Abort trap ========= This is the example code: ========= ; ModuleID = 'test.o' target datalayout =

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

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

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

To play with RJS I just made a "rake freeze edge". But this copies only the libs into vendor/rails and any attempt of "rake update_javascripts" fails. But all the he required javascripts are there, at: BASEPATH/vendor/rails/actionpack/lib/action_view/helpers/javascripts/ Except of prototype, they seem to have no version number, so I am asking whether I should take those

target triple = "i386-pc-linux-gnu" On 13/05/2010, at 9:25 PM, Anton Korobeynikov wrote: >> int (*FP)() = (int (*)())FPtr; >> int res = FP(); >> >> when the function executes correctly in the case of instead having created a standard global variable. > What is the platform you're running the code on? > > -- > With best regards, Anton

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

I tried using it on x86 and ended up with the global variable resolving to an invalid pointer.

> int (*FP)() = (int (*)())FPtr; > int res = FP(); > > when the function executes correctly in the case of instead having created a standard global variable. What is the platform you're running the code on? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi everyone, I’m working on adding multithreading support to our programming language (http://crystal-lang.org <http://crystal-lang.org/>) and I’m facing an issue with thread local variables. Since the language relies heavily on coroutines, basically the problem is that a function could start running on a thread, get suspended and continue running on a different thread. So, for example, if

For everyone understand which code must be emitted to implement TLS, I will paste the code generated by gcc for a simple function: __thread int a = 1; int f(){ return a; } gcc teste.c -o teste.s -S -O2 (arm-linux-gnueabi): .global a .section .tdata,"awT",%progbits <== special section for tls symbols .align 2 .type a, %object

Hi Lauro, On Wed, 2007-04-11 at 15:15 -0300, Lauro Ramos Venancio wrote: > For everyone understand which code must be emitted to implement TLS, I > will paste the code generated by gcc for a simple function: ... snip ... This proposal sounds really good to me. I only have a couple comments. We have a "section" keyword already developed in LLVM assembly. Perhaps instead of