similar to: [LLVMdev] compiling clang with rtti

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 >

On 01/29/2010 12:11 AM, Chris Lattner wrote: > On Jan 28, 2010, at 12:45 PM, Thomas B. Jablin wrote: > > >> Hi, >> Lately LLVM has been adding -fno-rtti to most of the compiler. I >> have a pass which uses LoopPass and which inherits from FunctionPass >> and a class of my own. If I compile my code with ENABLE_RTTI=1, I >> can't dynamically load

On Jan 28, 2010, at 12:45 PM, Thomas B. Jablin wrote: > Hi, > Lately LLVM has been adding -fno-rtti to most of the compiler. I > have a pass which uses LoopPass and which inherits from FunctionPass > and a class of my own. If I compile my code with ENABLE_RTTI=1, I > can't dynamically load the shared object since it won't be able to > find the symbol for

Hi, Lately LLVM has been adding -fno-rtti to most of the compiler. I have a pass which uses LoopPass and which inherits from FunctionPass and a class of my own. If I compile my code with ENABLE_RTTI=1, I can't dynamically load the shared object since it won't be able to find the symbol for LoopPass's typeinfo. undefined symbol: _ZTIN4llvm8LoopPassE $ c++filt _ZTIN4llvm8LoopPassE

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 Feb 17, 2010, at 3:15 AM, Heikki Kultala wrote: > LLVM 2.7 is dropping rtti on default build, which is a problem to us. > We are using Boost libraries on many places in our code, and Boost has > some heavy usage of type info tricks, which cannot be compiled without > rtti, so we have to keep rtti on for our code. > > But our code also implements the llvm backend framework

On 02/17/2010 09:58 PM, Chris Lattner wrote: > You should be able to get this by doing "make REQUIRES_RTTI=1" when building LLVM. What is the main reason RTTI is now disabled by default? We discussed this briefly in IRC but could not reach a proper conclusion and I was directed to ask here for the proper reason against it. Having RTTI support in should not have execution speed

We at Tampere University of technology are using LLVM for high-level optimizations in the compiler for our TTA processor toolkit(TCE) We have a llvm backend which creates our own intermediate code, and our own instruction selector after that (as LLVM's machine code cannot represent the actual machine codes of our processors). This makes our llvm backend quite different from the ordinary

Please commit... Best Olaf Krzikalla -- Olaf Krzikalla Technische Universitaet Dresden Zentrum fuer Informationsdienste und Hochleistungsrechnen Abteilung Verteiltes und Datenintensives Rechnen Zellescher Weg 12, 01069 Dresden Willersbau, Zimmer A105 Telefonnr.: +49 351 463-32442 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: twine.patch

Sorry, I was too fast. There is more... But now all compiles fine. However I'm not very satisfied with the Constants.patch since I don't know for 100% sure what's going on. OK, I know that MSVC tries to instantiate the virtual member function FoldingSet<MDNode>::GetNodeProfile where gcc seems to be more relaxed on the instantiation of template functions. But I have no idea

On Feb 18, 2010, at 1:54 AM, Pekka Jääskeläinen wrote: > On 02/17/2010 09:58 PM, Chris Lattner wrote: >> You should be able to get this by doing "make REQUIRES_RTTI=1" when building LLVM. > > What is the main reason RTTI is now disabled by default? We discussed > this briefly in IRC but could not reach a proper conclusion and I was > directed to ask here for the

Hi Trevor, > I've written a CallGraphSCCPass that compiles successfully, but when I > try to run it with opt, it fails: > > Symbol not found: __ZTIN4llvm16CallGraphSCCPassE $ c++filt _ZTIN4llvm16CallGraphSCCPassE typeinfo for llvm::CallGraphSCCPass LLVM TOT has RTTI turned off as far as I know (not sure about 2.7). Are you making use of RTTI? Ciao, Duncan.

Hi @llvm, below is a copy of a message I sent to clang a hour before. I guess it's more appropriate here. --snip-- While trying to eleminate as much std::tr1::function as possible I stumbled over a design flaw in llvm::df_iterator. Consider the following code: void for_all_stmts(Stmt* S, const std::tr1::function<void(Stmt*)>& fn) { if (S) { fn(S); for

Hi @llvm, what I have here is a library named clangAddons which is tightly coupled to clang and LLVM. This lib provides a single external function only which is then used by my actual application (a QT project). Of course the clangAddons lib needs to be compiled using the LLVM build infrastructure to get all the compiler flags right (you can see it as a lib similiar to clangAST aso.).

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 get RTTI for LLVM symbols? -- Pekka

Hi all, I'm having trouble when trying to reuse some functions that use Boost::Exception into my LLVM-based application. As far as I know, LLVM turns off Exception handling (apparently for performance reasons), so I get the following link-time error in a few places: "undefined reference to `boost::throw_exception(std::exception const&)" When I compile the external code from

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 get RTTI for LLVM symbols? > No. If this is a hack to get the command 'g++ -shared -o libLLVM-2.7.so -lXXX -lXXX

Hi, I've written a CallGraphSCCPass that compiles successfully, but when I try to run it with opt, it fails: Symbol not found: __ZTIN4llvm16CallGraphSCCPassE If I simply change the pass to be a FunctionPass or a ModulePass, opt can run it just fine. I'm on Mac OS X, so I thought perhaps I was running into bug #2771 [1], but I'm getting the same error on Ubuntu Linux:

On Thu, Feb 18, 2010 at 3:42 PM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: >  From now on these users need to recompile LLVM from sources with non-default > flags to make TCE (or other external projects using both LLVM and RTTI) to > be able to link with it. I think this should matter something in comparison to > a 5% disk size reduction which can be still achieved

Thanks! Yes, we are trying to avoid that situation as much as possible. Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)? Currently I don't know any better way than runtime logging and asserting. Also, what shall we do we external source libraries (like Teigha from Open Design Alliance), where