search for: 2.9

Hey everyone, So I have an LLVM pass that appears to run completely and work fine, and then it aborts at the very end. When exiting the final runOnFunction call, I get the following error / stack dump. I cannot figure out why this is happening for the life of me - does anyone have any ideas? I'm not trying to do any crazy deallocation or anything, it just seems like a normal pass to me.

Hi Griffin, did your pass create a data structure that holds values somehow, and forgot to delete it? Also, try running under valgrind in case this is due to a memory error of some kind. Ciao, Duncan. > So I have an LLVM pass that appears to run completely and work fine, and > then it aborts at the very end. When exiting the final runOnFunction call, > I get the following error /

> Is there anything I can do to make the build more verbose so I can debug this? make VERBOSE=1

Hello all, I really, really, really need your help. This is my third email now, please don't ignore me! I understand this must be a trivial thing, but I've ground to a halt, and REALLY need some guidance. Please see below for the context of my problem. I'm not trying to be a waste of time, but I'm desperate here. I have a getAnalysisUsage method which does the following

Using Valgrind hasn't shown me anything terribly unusual. And I'm confused because its not even trying to delete a real instruction; deleting a void type with no name? That doesn't make any sense... Any other hints? I've seen a few posts in the past about this relating to some internal LLVM bugs... -Griffin On Thu, 12 Jan 2012 21:26:41 +0100, Duncan Sands <baldrick at

Yes, it is a pass. Here is a very general overview of the file structure as far as the AA is concerned. LLVM is not my strong-suit, I do hardware simulators, not compilers. using namespace llvm; char RelRecovery::ID = 0; static RegisterPass<RelRecovery> X("relRecovery", "Reliability transformation for lightweight recovery"); void

Griffin Wright wrote: > > Hello all, > > I really, really, really need your help. This is my third email now, > please don't ignore me! I understand this must be a trivial thing, but > I've ground to a halt, and REALLY need some guidance. Please see below for > the context of my problem. I'm not trying to be a waste of time, but I'm > desperate here.

Hello, I've been stuck with a problem for about a month, and it has stumped everyone in my lab. I have a function pass that runs, and when it finishes and opt goes to return, I get: While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! On a simple test case, the error becomes 'i32 %'

On Fri, Apr 08, 2011 at 01:58:10PM +0200, Duncan Sands wrote: >> Is there anything I can do to make the build more verbose so I can debug this? > > make VERBOSE=1 Duncan, Oddly this shows... GCC=/sw/lib/gcc4.5/bin/gcc-4 LLVM_CONFIG=/sw/bin/llvm-config make VERBOSE=1 CPPFLAGS="-DENABLE_LTO -I/sw/include" Compiling utils/TargetInfo.cpp g++ -c

hi all, I want access to all basic blocks of function in a loop, so I used the following code: *bool parallel::runOnLoop(Loop *L, LPPassManager &LPM) { for (Function::iterator bi= func->begin(); bi != func->end(); bi++){ // } }* First loop run without problem, but for second loop I get the following error: *0 libLLVM-2.9.so 0x0137d530 1 libLLVM-2.9.so 0x0137fa6c 2

Hello all, I am working with someone else's LLVM code, which is about 8 months old. Part of this pass involves AliasAnalysis, and I'm getting the above assertion when the pass completes. The dump is as follows: -------------------------------- Program received signal SIGABRT, Aborted. 0xf7fdf430 in __kernel_vsyscall () (gdb) bt #0 0xf7fdf430 in __kernel_vsyscall () #1 0xf602e921 in

Chen, see http://llvm.org/docs/GettingStarted.html#pf_12 ...Takumi ps. Excuse me, PE+ (aka pep) means "Executable file format for WIndows x64". 2011/5/16 陈晓宇 <xychen0921 at gmail.com>: > The stack trace: > > Starting program: > C:\MinGW\msys\1.0\home\xchen\llvm-obj\lib\Target\CellSPU/../.. > /../Debug/bin/tblgen.exe -I

I tried on a different machine x86_64 ( vs x86 ) and I don't have these issues anymore (the tests are failing on the x86 machine because of a segmentation fault) Both builds were done using: g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4) Something should be wrong with my environment... The only differences I noticed during the compilation are the following warnings (which appear several times, but

On 2011-03-14 18:14, Anton Korobeynikov wrote: > Hello Xerxes, > >> llvm 2.9rc1 test on Dualcore ARM running Ubuntu Natty > What is the gcc used for the compilation? Can you try to do the -O0 > build and see whether this changed the stuff? > xranby at panda:/media/dh0/llvm-2.9-build-O0$ gcc --version gcc (Ubuntu/Linaro 4.5.2-5ubuntu1) 4.5.2 Copyright (C) 2010 Free Software

Hello Xerxes, > llvm 2.9rc1 test on Dualcore ARM running Ubuntu Natty What is the gcc used for the compilation? Can you try to do the -O0 build and see whether this changed the stuff? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

I am testing the latest LLVM release (2.9). When I run the regression tests, I get many failures: cd llvm-2.9.build/test make Expected Passes : 2605 Expected Failures : 46 Unsupported Tests : 542 >>> Unexpected Failures: 2658 For info: - I was working with 2.8 so far and I didn't have these issues. - LLVM was build using: ../llvm-2.9/configure --enable-assertions

When migrating my project to 2.9, I've encountered a strange segfault where if a ModulePass's getAnalysisUsage adds LoopInfo and DominatorTree, then llvm::PMTopLevelManager::findAnalysisUsage will segfault. What's odd is that if I rearrange this (add required for DominatorTree before LoopInfo), it does not segfault. I realize that LoopInfo requires and preserves DominatorTree, but this

I was building llvm2.9 using MinGW64 on windows, msys was 32 bit so I specified --host option for a cross compiling. Following are my configure options: ../llvm2.9/configure --prefix=/home/AutoESL/llvm-obj --host=x86_64-w64-mingw32 --disable-multilib The error: make[1]: Entering directory `/home/AutoESL/llvm-obj/lib/VMCore' make[1]: ***

Eric, could you tell me which version of gcc you are using (According to http://llvm.org/docs/GettingStarted.html, gcc 3.4.2 should be used but I don't know if this document is up to date regarding the required software versions) Anyway I also tried with gcc version 3.4.6 (Ubuntu 3.4.6-6ubuntu5) And now, I get a bunch of errors like this one: llvm-2.9/lib/Support/regcomp.c: In function `cset*

On Apr 26, 2011, at 4:44 PM, Damien Vincent wrote: > > I am testing the latest LLVM release (2.9). > When I run the regression tests, I get many failures: > > cd llvm-2.9.build/test > make > Expected Passes : 2605 > Expected Failures : 46 > Unsupported Tests : 542 > >>> Unexpected Failures: 2658 > > For info: > - I was working with