similar to: [LLVMdev] What's the state of thread_local support?

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

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

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

> 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

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

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

> 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

1. Is there already a push underway to get it in? 2. If not, how's this change sound: ECX is not a callee-saved register, so callers assume it gets nuked anyway. So for LLVM functions, ECX gets a flag indicating whether unwinding is taking place. At each callsite for "call", check ECX and bail out if the unwind flag is set. At the callsite for "invoke", check ECX and

1. Which ones? I know that Windows uses it for the "this" pointer. Anyway, unless the callee is required to preserve it in a given calling convention, that doesn't preclude us using it for a *return* value. It would be checked after calls return, and wouldn't affect the use of the register for passing values in before the call is made. The callee would set it right before

On Thu, Nov 25, 2010 at 3:05 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Kenneth Uildriks wrote: >> >> On Wed, Nov 24, 2010 at 2:50 PM, Nick Lewycky<nicholas at mxc.ca>  wrote: >> >> I thought analysis passes just rebuilt their state after they got >> invalidated.  Shouldn't that happen with an AA pass as well?  Or is AA >> special? >

> I can't find any release_32 branch at http://llvm.org/git/llvm.git or http://llvm.org/git/clang.git. Unfortunately, this requires manual grafting, since git-svn does really bad job here. I'm going to work on this tonight. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello, Scott. > Checking the assembly from llc, the first alloca call is to allocate > local vars in _main. Is this just the state of the code at 2.0 when > built with vs.net, or is there something that I've managed to > mis-build locally? _alloca is used to probe the stack, if you asks for locals of size more that 4k. This is pretty ugly, but the names of this functions differs

Anton, please add release_32 also in; clang-tools-extra compiler-rt dragonegg libcxxabi lldb They have release_32 in svn. I don't know they might be released, though. And, could you suppress generating refs/heads/svn-tags and prune them for now? I am sure that orphan branches will stress the llvm.org server to begin git-pack-ing whole tree. ...Takumi 2012/11/15 Anton Korobeynikov

Should be there. Please let me know if there are any problems with them On Wed, Nov 14, 2012 at 9:19 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> I can't find any release_32 branch at http://llvm.org/git/llvm.git or http://llvm.org/git/clang.git. > Unfortunately, this requires manual grafting, since git-svn does > really bad job here. > > I'm going

I'm trying to change the Endian of X86 from little to big in the TargetData. I only care about the way in which this effects the LLVM IR, not the actual backend code. I've changed the "e-" to "E-" in X86TargetMachine.cpp (where it sets the DataLayout) with no luck. Are there any other obvious places that I need to change this? The TargetData docs were somewhat helpful

Please email llvmdev, not me directly. On Aug 19, 2009, at 9:37 AM, Kenneth Uildriks wrote: > So things like type mismatches, missing return statements, and whatnot > count as "internal errors"? I guess that makes sense... I'll just > have to do those check on my side then. Yes. The IR has to be well formed by your frontend. -Chris > > On Wed, Aug 19, 2009 at

Thanx for a prompt reply. I will definitely try llvm 2.8 as per your suggestion. However Step 1 and Step 2 are working for me in case of a simple hello world program on arm processor . Similarly I am able to run a GTK application on arm. However while running wxGTKwidget app it crashes while allocation of memory. As I mentioned earlier, If I explicitly allocate memory using new operation then

Hello Anton, While we have been discussing this, my partner discovered the source of where the sj/lj stuff is coming from. Does this mean that the LLVM libraries we're using are broken? Type.cpp ..\..\..\..\llvm\lib/libLLVMCore.a(Type.cpp.obj):Type.cpp.text+0x722): undefined reference to `__gxx_personality_sj0' ..\..\..\..\llvm\lib/libLLVMCore.a(Type.cpp.obj):Type.cpp.text+0x750):

Hi, On Fri, Nov 14, 2008 at 10:55 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hi, Edd > >> Are you aware of this? Is there a fix? > gcc 3.3 ? Indeed. 3.3.5. Im guessing I need 4 then :) -- Best Regards Edd http://students.dec.bournemouth.ac.uk/ebarrett

On Jun 2, 2011, at 9:11 AM, Jim Grosbach wrote: > > On Jun 2, 2011, at 6:20 AM, Rafael Ávila de Espíndola wrote: > >> On 11-06-02 6:56 AM, Anton Korobeynikov wrote: >>> Hi Chip, >>> >>>> Because of all this, it's hard to reconstruct the SEH information from >>>> the MachineMove array. I have thought about adding a new array specific