similar to: [LLVMdev] Out-of-source subclassses vs. LLVM's RTTI system

Hi Tobias On Wed, Jun 24, 2015 at 12:43 PM, Tobias Grosser <tobias at grosser.es> wrote: > Maybe have a look at Polly's lib/Analysis/ScopDetectionDiagnostic.cpp and > lib/Analysis/ScopDetection.cpp. We use LLVM's diagnostics in a loadable > module without modifying LLVM's DiagnosticKind enum. > Thanks very much for the suggestion. It looks like Polly's

Hello, I was thinking about printing SCEV into DiagnosticInfo messages, an example would be to print the loop trip count of loops, or the stride of memory accesses. I ran into two problems: - DiagnosticInfo is in Core, SCEV is in Analysis, so it is a little bit weird (I declare the operator<< overload for SCEV* in DiagnosticInfo, but only define it in ScalarEvolution) - I would like to

I get a crash when I try to link multiple modules registered in their individual contexts. Documentation for Linker::LinkModules doesn't mention anything about contexts, and the first link succeeds. But the second link crashes. Is this not the right way to merge such modules? If not, then what is the right way? In any case, documentation for Linker::LinkModules should say if contexts are

> Currently what debugger has to do is to demangle RTTI name and try to > match it to DW_AT_name attribute to find type. As you can see it does > not work for any of 3 examples. > > I've asked about the problem on G++ maillist, and one of the proposed > solutions is to emit DW_AT_linkage_name for types.  > > Can this solution be also implemented in LLVM?  It could, but

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/19/2010 12:54 PM, Chandler Carruth wrote: > IMO, if you wish to preserve the ability to ever turn off RTTI, you > must turn it off by default for the developers' builds so that any > code which might depend on RTTI breaks immediately. Otherwise, it > seems only a matter of time before dependencies slowly creep back into > the code base. This has certainly proven true with

Pekka Jääskeläinen wrote: > Mainly this is about a nuisance to need to ask users of TCE to recompile > LLVM (which might be even installed from a precompiled binary for their > distro) to be able to compile TCE. I highly recommend that any packagers turn on RTTI for their shipping builds of LLVM, in order to increase the chance of the library being reusable. Nick

On Fri, Feb 26, 2010 at 5:37 AM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > On 02/19/2010 07:55 AM, Nick Lewycky wrote: >> I highly recommend that any packagers turn on RTTI for their shipping >> builds of LLVM, in order to increase the chance of the library being >> reusable. > > Seems Ubuntu 10.04 LTS is going to ship LLVM 2.7. I sent a request

Hi, I'm trying to port a piece of code using LLVM as a library to the latest SVN version. One difference between 2.6 and 2.7svn is that `llvm-config --cxxflags` now include -fno-rtti. Since my code does use RTTI information (in non-trivial dynamic_cast), my code can't compile with this. Same goes for -fexceptions. I've tried setting my CXXFLAGS to `llvm-config --cxxflags` -frtti

Hi Al, > It's good that llvm/lib builds with exceptions and RTTI disabled as it > supports doing optimization and codegen on very constrained platforms. > Judging by REQUIRES_EH in makefiles, only a few bits like TableGen, llvm-ar > and llvm-ranlib need them, and I doubt these would need to run on a target. > It's unlikely exceptions would get in in a random patch, because

On Thu, Oct 14, 2010 at 4:09 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Francois, > >> In that case, RTTI and exception should also be disabled from CMake >> generated projects right? >> Currently they are enabled all over my MSVC projects. > > I'm not sure what you are asking.  The goal is for LLVM to not require > RTTI or exception handling.

Just wondering if rtti will be gone in 3.0? I'd like to port llvm to my OS, where the gcc runtime env has rtti turned off. Thanks.

Forgot to CC the list, sorry. ----- Forwarded Message ----- > From: Samuel Crow <samuraileumas at yahoo.com> > To: FlyLanguage <flylanguage at gmail.com> > Cc: > Sent: Monday, July 18, 2011 10:40 AM > Subject: Re: [LLVMdev] RTTI gone in 3.0? > > Hi FlyLanguage, > > I thought LLVM disabled RTTI a long time ago.  It was just too slow. > > --Sam >

Den 18.07.2011 17:40, skrev Samuel Crow: > Hi FlyLanguage, > > I thought LLVM disabled RTTI a long time ago. It was just too slow. > > --Sam No, it was used a few places until fairly recently at least, and I'm not sure if it's totally gone yet. The custom rtti stuff didn't catch quite all the cases I think. Anyone?

On Oct 5, 2011, at 3:10 AM, Somorjai, Akos wrote: > The version from the Xcode 4.2 GM package (Apple clang version 3.0 (tags/Apple/clang-211.10.1)) still has the same problem. Which version should I use? It looks like you'll have to compile your own from trunk if you want this warning improvement, sorry. Obviously, that's not an Apple-supported option, but it's a

On May 1, 2012, at 11:47 PM, Somorjai, Akos wrote: > Is there any progress regarding RTTI handling in the newer builds? When you're resurrecting six-month-old threads, it's polite to quote some history. :) I don't know offhand what the state of this warning is in Xcode 4.3, and I can't comment on potential future releases. If this matters a lot to you, please just try it and

On 02/19/2010 07:55 AM, Nick Lewycky wrote: > I highly recommend that any packagers turn on RTTI for their shipping > builds of LLVM, in order to increase the chance of the library being > reusable. Seems Ubuntu 10.04 LTS is going to ship LLVM 2.7. I sent a request for enabling RTTI on the package, I hope it's not too late for that:

Pekka Jääskeläinen wrote: > Jeffrey Yasskin wrote: >> I've put together http://llvm.org/docs/Packaging.html to document >> these kinds of requests for all packagers in one place. Let me know if >> any of the advice I've put there is wrong. (At the moment, > > Looks good to me. BTW exception support for LLVM is not required > to link with code that uses

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

Hi Francois, > In that case, RTTI and exception should also be disabled from CMake > generated projects right? > Currently they are enabled all over my MSVC projects. I'm not sure what you are asking. The goal is for LLVM to not require RTTI or exception handling. Thus these can be disabled by the build system (by specifying -fno-rtti etc), since they won't be used anyway. Not