similar to: [LLVMdev] LLVM is deleting an array pointer without using array notation

Hi llvmdev! In our project (Windows, Visual Studio compiler) we've got some frontend which generates LLVM IR. Now I'm observing strange *llvm_shutdown* behavior. If I called it when I was done using the LLVM APIs I saw that destructors of static objects created new ManagedStatic objects, which was never freed. Then I tried to use static global llvm_shutdown_obj to cause destruction

On Fri, Dec 5, 2008 at 1:58 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Fri, Dec 5, 2008 at 1:57 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >> On Fri, Dec 5, 2008 at 1:52 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >>> / * snip */ >> >> Actually, rebuilding it makes "debug tblgen" fail with the errors at >> the

On Sep 5, 2007, at 2:21 PM, Chuck Rose III wrote: > Hola LLVMers, > > > > I’m getting a crash when using ConstantFP::get. > > > > I can repro it by adding one line to the Fibonacci example program: > > > > int main(int argc, char **argv) { > > int n = argc > 1 ? atol(argv[1]) : 24; > > > > // Create some module to put our function

Hola LLVMers, I'm getting a crash when using ConstantFP::get. I can repro it by adding one line to the Fibonacci example program: int main(int argc, char **argv) { int n = argc > 1 ? atol(argv[1]) : 24; // Create some module to put our function into it. Module *M = new Module("test"); // We are about to create the "fib" function: Function

Hola Dale, I spent some time walking through what's going on with a friend of mine from VStudio. Category is given 2 bits in the APFloat class definition. It's sign extending the enum value for the comparisons when it loads it out of the class, so the 2 becomes a -2 and the comparison fails. He sent me a piece of code which I might be able to use to force the issue. I'll update

It's in debug. I'm having a look at the assembler it's producing right now and it's definitely a little odd for what should be a simple assignment in zeroSignificand. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dale Johannesen Sent: Wednesday, September 05, 2007 2:39 PM To: LLVM Developers Mailing

On Sep 5, 2007, at 5:08 PM, Chuck Rose III wrote: > Hola Dale, > > > > I spent some time walking through what’s going on with a friend of > mine from VStudio. Category is given 2 bits in the APFloat class > definition. It’s sign extending the enum value for the comparisons > when it loads it out of the class, so the 2 becomes a -2 and the > comparison fails.

On Monday 14 September 2009 13:07, Dan Gohman wrote: > MachineMemOperands for spill slots use FixedStack PseudoSourceValues > as their base. There's a unique FixedStack PseudoSourceValue for each > fixed frame object, so it's independent of whether frame pointer > elimination has been done, and it's independent of the actual frame > offsets. >From

On Monday 14 September 2009 15:28, David Greene wrote: > I don't see PseudoSourceValue::FPRel, etc. defined anywhere. How do I know > if a PseudoSourceValue is from the stack? Ok, the comment is misleading. I see the class defined in PseudoSourceValue.cpp now. I'll move it to the header. I have another question. Looking at the list of MachineMemOperands for an instruction, is

I am trying to figure out how to free up some memory that seems to be lost when running valgrind under our internal application. The stack traces I get are: ==19966== 4 bytes in 1 blocks are still reachable in loss record 1 of 12 ==19966== at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255) ==19966== by 0x5D9BBE8: void* llvm::object_creator<llvm::PassRegistry>()

Right, I'm suggesting we keep llvm_shutdown() for users who want this control, but also destroy still-live ManagedStatic instances if llvm_shutdown() is not called. This helps in the case where there is not a clear time when llvm_shutdown() can be called, especially given that LLVM cannot be resurrected in the same process due to current limitations in the pass registry, and perhaps

Based on a recent discussion[1], I started trying to remove the functions llvm_start_multithreaded() and llvm_stop_multithreaded() from the codebase. It turns out this is a little bit tricky. Consider the following scenario: During program initialization, a global static object's constructor dereferences a ManagedStatic. During dereferencing of the ManagedStatic, it needs to know whether

I just installed the pre-compiled binaries for Clang 3.4.1, which was the latest version I could find to download. Starting a new 'blank' project in MSVC I was easily able to change the tool set from MS Visual Studio 2013 (v120) to LLVM-vs2013. However, trying to compile a simple 'hello world' program resulted in the following compiler errors. Is there something simple I am

Hi, I found that building LLVM in single-threaded mode with CMake is failing because some object files still have references to pthread routines. There are two instances of the build failure happening. $ cmake .../llvm/ -DLLVM_ENABLE_THREADS=0 $ make -j8 check-all % Linking CXX executable IRTests ../../lib/libgtest.a(gtest.cc.o): In function

On Sep 14, 2009, at 10:32 AM, David Greene wrote: > On Monday 14 September 2009 12:22, Dan Gohman wrote: > >> Hi Dave, >> >> >> >> On Sep 11, 2009, at 3:31 PM, David Greene wrote: >> >>> Attached is a patch to print asm comments for spill information. >>> >>> We've discussed the mechanisms before but I wanted to run the

The mutex could be made an actual global static instead of a ManagedStatic. This guarantees it would be constructed before main, and live until the end of main. So even in PassRegistry's destructor, which would get call during llvm_shutdown(), it would always have the same mutex. Ideally I'd like to just delete the mutex, as it doesn't seem like anyone is using it in a

+cc original authors of these changes. Is PassRegistry intended to be thread-safe? The header file explicitly says that PassRegistry is not thread-safe, but there are mutexes and locking used in the code. This is actually creating a problem, because of a subtle bug involving static initialization order and shutdown. In particular, the RegisterPass<> static template will get invoked

I'm curious about the design rationale for how ManagedStatic instances are cleaned up, and I'm hoping someone can shed some light on it. Currently, ManagedStatic objects are cleaned up when llvm_shutdown() traverses the global list of initialized objects and calls destroy() on each. This leads to two questions: 1. An assertion enforces that the objects are deleted in reverse order of

Hi Akira, did anything happen with this patch? Ciao, Duncan. On 09/05/13 04:04, Akira Hatanaka wrote: > The following code snippet taken from StackColoring::remapInstructions clears a > mem operand if it can't guarantee whether the memoperand's underlying value > aliases with the merged allocas: > > // Update the MachineMemOperand to use the new alloca. > 522

That is one evil bug! I just tested it against tip-of-trunk clang and it appears to be fixed there (just fyi for everyone). Howard On Sep 27, 2012, at 7:17 PM, Adam Peterson <alpha.eta.pi at gmail.com> wrote: > Is this a relevant location to provide information about what I > believe is a compiler bug in clang? If not, please forgive me for > posting it here. (Perhaps you can