similar to: Help with segfault in llvm_shutdown with LLVM 5.0 Release build

On 9/18/2017 8:20 PM, Diptorup Deb via llvm-dev wrote: > Hi, > > We are upgrading an LLVM 4.0-based opt module to LLVM 5.0. After the > upgrade our module works when built with an LLVM Debug build, but > with an LLVM Release build we are encountering the following error. > > This happens after our passes have successfully run. I believe this > has to do with the way our

I ran into a similar problem a while ago; see https://reviews.llvm.org/D30107 and https://reviews.llvm.org/D33515 .  You get the unusual stack trace because it's trying to call a destructor in shared library which was already unloaded. I thought we had fixed that, but maybe not?  Looking again, it looks like the patch got reverted and I didn't notice. -Eli On 5/14/2018 10:18 PM,

It's working with trunk though. Do you think the patch will end up in 6.0.1? Thanks. Simone On Tue, May 15, 2018 at 11:18 AM, Friedman, Eli <efriedma at codeaurora.org> wrote: > I ran into a similar problem a while ago; see https://reviews.llvm.org/ > D30107 and https://reviews.llvm.org/D33515 . You get the unusual stack > trace because it's trying to call a destructor

Hi all, I was porting my pass from LLVM 4.0 to 6.0 and I am getting a segmentation fault. I was able to obtain only the info below from GDB. I tried to debug with some printf and the runOnFunction runs correctly. Any idea/suggestion about what is going on? The source code of the pass is here: https://github.com/PRUNERS/sword/blob/master/lib/Sword.cpp Any help is much appreciated, Thanks!

This is the correct path to the pass: https://github.com/PRUNERS/sword/blob/master/lib/Transforms/Instrumentation/InstrumentParallel.cpp On Mon, May 14, 2018 at 10:06 PM, Simone Atzeni <simone.at at gmail.com> wrote: > Hi all, > > I was porting my pass from LLVM 4.0 to 6.0 and I am getting a segmentation > fault. > I was able to obtain only the info below from GDB. > >

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

Hi, We have a research LLVM-based domain-specific code generator that we want to upgrade form LLVM 4.0 to 5.0. The code generator is written as an out-of-tree loadable module for opt. Till Clang 4.0 we were compiling the front-end code (annotated C++) using -O0. The generated bitcode was further processed using opt with our module loaded. In Clang 5.0 we see that using -O0 adds the optnone

Hello, I am working on a C++ expression templates based DSL where we are using LLVM for the code generation. I needed some help in understanding the behaviour of the LICM pass. In the following example code the "A" class is a custom container that defines various arithmetic operators using expression templates. We are defining three arrays of the "A" container and aggregating

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

Thanks, I tried calling ResetAllOptionOccurrences after the run like this… // Compile the module TimeCompilations times to give better compile time // metrics. for (unsigned I = TimeCompilations; I; --I) if (int RetVal = compileModule(argv, Context)) return RetVal; if (YamlFile) YamlFile->keep(); cl::ResetAllOptionOccurrences(); return 0; } Unfortunately

You can also add the -Xclang -disable-O0-optnone flag to your command line. This will disable the implicit optnone when compiling with O0. Cheers, Michael On Mon, Sep 18, 2017 at 7:27 AM +0200, "Craig Topper via llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: To prevent optnone from being added you can replace -O0 with "-O1 -Xclang

Hi Tobias, I am trying to move Polly later. LLVM provides some predefined ExtensionPointTy: EP_EarlyAsPossible, EP_ModuleOptimizerEarly, EP_LoopOptimizerEnd, EP_ScalarOptimizerLate, ... Currently Polly uses "EP_EarlyAsPossible" to run as early as possible. As what you suggested: >Instead of removing canonicalization passes, I believe we may want to >move

Ptr member of ManagedStaticBase is now atomic. In ManagedStaticBase::RegisterManagedStatic we have such code: void *Tmp = Creator(); Ptr.store(Tmp, std::memory_order_release); DeleterFn = Deleter; // Add to list of managed statics. Next = StaticList; StaticList = this; StaticList is not atomic and not guarded by any fence. The same applies to the members

Though it won't actually help to guard this: while (StaticList) - a fence here is needed... On Mon, Dec 26, 2016 at 9:20 AM, Viacheslav Nikolaev < viacheslav.nikolaev at gmail.com> wrote: > Ptr member of ManagedStaticBase is now atomic. > In ManagedStaticBase::RegisterManagedStatic we have such code: > > void *Tmp = Creator(); > > Ptr.store(Tmp,

On 09/19/2013 04:46 PM, Star Tan wrote: > Hi Tobias, > > > I am trying to move Polly later. > > > LLVM provides some predefined ExtensionPointTy: > EP_EarlyAsPossible, > EP_ModuleOptimizerEarly, > EP_LoopOptimizerEnd, > EP_ScalarOptimizerLate, > ... > > > Currently Polly uses "EP_EarlyAsPossible" to run as early as

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

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

Hi, We have been investigating an issue when running LTO with our proprietary linker, which links against libLTO dynamically. The issue is that when we pass -time-passes via the lto_codegen_debug_options function in the LTO C API, no time information is produced during compilation. The reason for this is that time information is stored in state owned by a ManagedStatic instance, and is only

Chris, I'm using a llvm_shutdown_obj object and it calls llvm_shutdown when I delete it. Do I need to call llvm_shutdown() again afterwards? It looks to me like the static object is being created after my program exits main(). From: Chris Lattner [mailto:clattner at apple.com] Sent: Friday, January 13, 2012 10:11 AM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev]

2017-05-02 8:42 GMT-07:00 Duncan P. N. Exon Smith <dexonsmith at apple.com>: > +Teresa, Mehdi > > On May 2, 2017, at 08:31, James Henderson <jh7370.2008 at my.bristol.ac.uk> > wrote: > > Hi, > > We have been investigating an issue when running LTO with our proprietary > linker, which links against libLTO dynamically. The issue is that when we > pass