similar to: [LLVMdev] dynamic_cast error detection

Hi Akos, you should send this to the clang mailing list instead. Ciao, Duncan. > I'm trying to convert our code base from GCC 4.0 to LLVM (on mac OS X), and ran > into a problem. In the past we used mach_override and the dynamic_cast source to > override the built-in dynamic_cast operator to detect shared library issues > (http://gcc.gnu.org/faq.html#dso). Basically we'd

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

<font face="Verdana,Arial,Helvetica,sans-serif" size="2"> <span><div>Hi,<br>There was a mention of optimizing away C++ dynamic_casts in LTO in this presentation: <a href="https://www.youtube.com/watch?v=Fd3afoM3UOE&t=1306" target="_blank">https://www.youtube.com/watch?v=Fd3afoM3UOE&t=1306</a><br>I

On Nov 12, 2010, at 5:57 PM, Óscar Fuentes wrote: >> Could someone >> please explain why I should use dyn_cast instead of dynamic_cast? (I >> thought all classes have v-tables...) Thanks, > > For reducing executable size, LLVM builds with RTTI disabled where > possible. Right, but how does that relate to dyn_cast? I thought v-tables were present even when RTTI is not

On Oct 3, 2011, at 4:42 AM, Somorjai, Akos wrote: > I'm trying to use this warning to check the vtable problem. Here's an example > > In mem.hpp > > class > AA { > // Construction / destruction: > protected: > AA (); > AA (const AA&); // Disabled > public: > virtual ~AA (); > }; > > In mem.cpp > > #include "mem.hpp" >

Thanks, John. I'll experiment with both the warning and the nm-weak external tool, and let you know the results. Best, Akos From: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Date: Fri, 30 Sep 2011 15:24:33 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev

LLVM has a relatively large number of proprietary replacements for standard C++ functions and classes. One of these is dyn_cast to replace dynamic_cast. The two calls appear to be semantically equivalent; the only difference that I can see is that dyn_cast reportedly works on classes that have no v-table [1]. Could someone please explain why I should use dyn_cast instead of dynamic_cast?

Trevor Harmon <Trevor.W.Harmon at nasa.gov> writes: [snip] > Could someone > please explain why I should use dyn_cast instead of dynamic_cast? (I > thought all classes have v-tables...) Thanks, For reducing executable size, LLVM builds with RTTI disabled where possible.

Apple clang version 3.0 (tags/Apple/clang-211.9) (based on LLVM 3.0svn) Target: x86_64-apple-darwin10.8.0 It's part of the Xcode 4.2b7 package. Shall I try to compile it on my own? Thanks, Akos From: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Date: Mon, 3 Oct 2011 10:19:04 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at

On Sep 30, 2011, at 9:15 AM, Somorjai, Akos wrote: > I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dso This is really a Clang question and so belongs on cfe-dev. > Is it using name or address comparison? Clang strives for interoperability with GCC, which means we use address comparison on targets where GCC does.

Hi everyone, I just had a question - I am aware that LLVM supports it's own form of RTTI ( using dyn_cast<>() ,etc) but I wish to use C++ RTTI currently. I have tried building with "cmake -G "Unix Makefiles" -LLVM_ENABLE_RTTI=ON" but that doesnt seem to remove the "fno-rtti" flag from llvm-config and I still get an error when I try using

On Sep 30, 2011, at 3:04 PM, Somorjai, Akos wrote: > 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)? There's a -Wweak-vtables which will point out a lot of these cases. I have to warn you that in previous

John, I'm trying to use this warning to check the vtable problem. Here's an example In mem.hpp class AA { // Construction / destruction: protected: AA (); AA (const AA&); // Disabled public: virtual ~AA (); }; In mem.cpp #include "mem.hpp" AA::~AA() { } And I still get the following warning: warning: 'AA' has no out-of-line virtual method

Il giorno 18/mar/2013, alle ore 15:14, Óscar Fuentes <ofv at wanadoo.es> ha scritto: > Nicola Gigante <nicola.gigante at gmail.com> writes: > >> The error I get is the following: >> Undefined symbols for architecture x86_64: >> "typeinfo for llvm::FoldingSetImpl", referenced from: >> typeinfo for llvm::FoldingSet<Type> in Program.o

Hello all, I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dso Is it using name or address comparison? We have an architecture with several frameworks and plug-ins; some of the latter are being loaded and unloaded runtime. In the past that issue caused crashes in our app, so at the moment we are overriding __dynamic_cast to

Nicola Gigante <nicola.gigante at gmail.com> writes: > Il giorno 18/mar/2013, alle ore 15:14, Óscar Fuentes <ofv at wanadoo.es> ha scritto: > >> Nicola Gigante <nicola.gigante at gmail.com> writes: >> >>> The error I get is the following: >>> Undefined symbols for architecture x86_64: >>> "typeinfo for

Hi, I've had problem with a program using LLVM that tried to dynamic_cast objects created in the JIT execution engine, from the native part of the program (for the curious, the program is PinaVM http://gitorious.org/pinavm/pages/Home). I've narrowed down the issue to the linkage of weak_odr and linkonce_odr symbols, used for the vtables, and that _must_ be unique for dynamic_cast to

It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory. -Chris On Oct 3, 2012, at 9:39 PM, Sean Silva <silvas at purdue.edu> wrote: > Thanks for the feedback! > >>> Does anybody have anything else they think should go into TGContext or >>> any other responsibilities it should have? Or any

> It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory. Ok, here's the first batch. It converts the RecTy hierarchy over to use LLVM-style RTTI. Along the way, I also wrote up a new doc "How to set up LLVM-style RTTI for your class hierarchy", which covers the previously undocumented (albeit not that

Thanks for the feedback! >> Does anybody have anything else they think should go into TGContext or >> any other responsibilities it should have? Or any feedback about the >> idea in general? > > All memory allocations should go into its bump pointer, RecordKeeper should as well. Any other global state that exist should also. Sounds good. >> I'm also hoping