similar to: [LLVMdev] cannot compile 3.2, ScalarEvolutionTest fails to link

I'm having some troubles building LLVM 3.3 (previously I was using 3.2). I'm getting a lot of errors in the various architecture support: In file included from PPCFrameLowering.h:17:0, from PPCTargetMachine.h:17, from PPCSelectionDAGInfo.cpp:15: PPCSubtarget.h:60:49: error: expected class-name before ‘{’ token PPCSubtarget.h:196:30: error:

> Looks like your shared library is not being compiled with symbols. > Did you verify that your sources are compiled with -g? I think so, this is the makefile (based on the one in the Hello pass): > LEVEL = ../../.. > LIBRARYNAME = CGF > LOADABLE_MODULE = 1 > USEDLIBS = > > ifneq ($(REQUIRES_RTTI), 1) > ifneq ($(REQUIRES_EH), 1) > EXPORTED_SYMBOL_FILE =

On Jun 24, 2011, at 10:34 AM, Carlo Alberto Ferraris wrote: > >> Looks like your shared library is not being compiled with symbols. Did you verify that your sources are compiled with -g? > I think so, this is the makefile (based on the one in the Hello pass): >> LEVEL = ../../.. >> LIBRARYNAME = CGF >> LOADABLE_MODULE = 1 >> USEDLIBS = >> >>

Antony Blakey wrote: > SVN head LLVM and Clang built out of the box for me a week ago on > MSYS/MINGW, using the following files: Ok, I tried to do the same. The compilations stops with the following error message (actually, I got to the same point in my attempt to build LLVM with the MinGW compiler shipped with Cygwin): llvm[1]: Compiling MachineLoopInfo.cpp for Debug build

Building of llvm with gcc-4.5.2-1 gives these warnings: 1) Building FileManagerTest "llvm[4]: Compiling FileManagerTest.cpp for Debug+Asserts build C:/Programming/VersionControl/llvm/tools/clang/unittests/Basic/FileManagerTest.cpp: In member function 'virtual void<unnamed>::FileManagerTest_NoVirtualDirectoryExistsBeforeAVirtualFileIsAdded_Test::TestBody()':

Hi Olaf, On Fri, Sep 11, 2009 at 5:24 AM, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de> wrote: > Hi @clang, > > I'm somewhat puzzled about using rtti when building clang under gcc (gcc > 4.3.3, linux/ubuntu). > (There is no problem under MSVC since rtti seems to be active there anyway). > The appropriate line 348 in llvm/makefile.rules is commented out meaning >

Hi @llvm, I've already asked the following questions to the clang dev list but got no response. Maybe there is a wider audience at llvmdev and someone here can help me. The question actually boils down to: How can I compile clang with rtti enabled? And this was my original mail (with some points now better explained) to clang: <--BEGIN--> Hi @clang, I'm somewhat puzzled about

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall

Wow, commenting those two lines worked out fine for me, thanks! On 9 May 2013 09:34, Giacomo Tagliabue <giacomo.tag at gmail.com> wrote: > Thanks, > Also, every method inherited by LoopBase causes the same error, while Loop > methods go smooth. > > > On 9 May 2013 01:05, Andrew Trick <atrick at apple.com> wrote: > >> >> On May 8, 2013, at 7:43 PM,

Thanks, Also, every method inherited by LoopBase causes the same error, while Loop methods go smooth. On 9 May 2013 01:05, Andrew Trick <atrick at apple.com> wrote: > > On May 8, 2013, at 7:43 PM, Giacomo Tagliabue <giacomo.tag at gmail.com> > wrote: > > Hello, > I am building a loop pass following these instructions: >

Hi all, I'm having problems compiling LLVM 3.2 with RTTI enabled. Since my code makes heavy use of the Boost libraries, RTTI is a must. This is the script I use to compile (as root): SRC_ROOT=$PWD OBJ_ROOT=/export/apps/llvm INSTALL_ROOT=/usr/local mkdir -p $OBJ_ROOT cd $OBJ_ROOT $SRC_ROOT/configure --prefix=$INSTALL_ROOT \

On 01/08/10 14:20, ether wrote: > sorry that i forgot to change the subjuect Hi ether, sounds interesting. Actually is/may be some kind of region. If you want you can have a look at the analysis, that I wrote. It is not yet finished, not completely documented and work in progress. However the first big comment might be interesting for you. Or seeing the results of opt -regions -analyze

Why not use the "standard" algorithm for detecting SESE-regions and building a program structure tree? It should handle everything you want. It also becomes much simpler to specify a connected SESE-region by entry/exit edges, while a disconnected region is specified by entry/exit blocks. Only defining regions on blocks is not enough to be able to quickly determine how to replace/move a

On May 8, 2013, at 7:43 PM, Giacomo Tagliabue <giacomo.tag at gmail.com> wrote: > Hello, > I am building a loop pass following these instructions: http://llvm.org/docs/WritingAnLLVMPass.html > Everything works fine, I did it many times for Function Passes, but in the runOnLoopmethod, whenever I call a method of the loop L passed as argument, for example L->begin(), I get the

hi all, On 2010-1-7 0:11, John Mosby wrote: > In LLVM we could add support for generalized CFG regions and > RegionPasses. A region is a part of the CFG. The only information we > have is, that it has one entry and one exit, this it can be optimized > separately. > I think this is the best way to add region analysis. I must admit > this approach > helps me on another,

On 30 June 2014 16:16, Shankar Easwaran <shankare at codeaurora.org> wrote: > I think you are hitting a bug, the Observer pattern was added a few weeks > back, and may be there is some sort of uninitialized variable ? This is my back-trace at "-O2 -g" (since -O1 pass): operator() (file=<optimized out>, __closure=0x7fffffffde40) at

$(llvm-config --libs | tr " " "\n" | grep gtest) returns: -lgtest_main -lgtest instead of non-valid: -lLLVMgtest_main -lLLVMgtest It also fixes: $(ld): cannot find -lLLVMgtest $(ld): cannot find -lLLVMgtest_main --- unittests/Makefile.unittest | 2 +- utils/llvm-build/llvmbuild/componentinfo.py | 4 ++-- utils/llvm-build/llvmbuild/main.py |

Hi, I was reading some loop related code and I don’t quite understand an assertion in LoopBase<BlockT, LoopT>::getLoopPredecessor(). /// getLoopPredecessor - If the given loop's header has exactly one unique /// predecessor outside the loop, return it. Otherwise return null. /// This is less strict that the loop "preheader" concept, which requires /// the predecessor to have

On Apr 19, 2012, at 10:43 PM, xiaoming gu <xiaoming.gu at gmail.com> wrote: > Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all > exit blocks for a loop. The problem I find with this API is that it returns repetitive basic blocks in certain > situations. Should repetitive basic blocks be removed? Users

On Wed, Apr 28, 2010 at 9:23 AM, Yuri <yuri at tsoft.com> wrote: > Pekka Jääskeläinen wrote: >> >> On 04/28/2010 11:42 AM, Yuri wrote: >>> >>> Looks like this is platform dependent. >> >> Yep, works fine here on Debian 5.0/x86_64 with gcc 4.3.2. >> >> Did you build with make REQUIRES_RTTI=1 which is required >> as of LLVM 2.7 to