search for: dynamic_casts

...ing class. I'm looking for a better solution with llvm; I know about -Wweak–vtables, but compiling with it gives me hundreds of errors, and some of them are false positives. So is there any legal way of catching dynamic_cast problems? Maybe dyld_interposing? I'd like to avoid replacing all dynamic_casts with another call if possible (because there are several hundreds of those calls). Thanks in advance, Akos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120830/37581d64/attachment.html>

...39;m looking for a better solution with llvm; I know about -Wweak–vtables, but > compiling with it gives me hundreds of errors, and some of them are false positives. > So is there any legal way of catching dynamic_cast problems? Maybe > dyld_interposing? I'd like to avoid replacing all dynamic_casts with another > call if possible (because there are several hundreds of those calls). > > Thanks in advance, Akos > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lis...

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.

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

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

HI Stefan, CC'ing Reid Kleckner, who might have some insight here, and llvm-dev as this may be of interest to other windows JIT users. I am facing the issue that C++ dynamic_cast doesn't work for types > loaded from object files with RuntimeDyLd. <snip> Do you think it is possible that RuntimeDyLd misses type info data in > the COFF file or doesn't wire it up

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

Hi all, I'm sure that the last thing that you want to think about is TableGen's guts, but I'm pursuing a course in bringing TableGen up to snuff with the rest of LLVM. Basically, I would like to introduce a "TGContext" class (by analogy with LLVMContext) to harbor a proper unique'd type system and BumpPtr allocate all of TableGen's data (RecTy's, Record's,

As far as I can tell, exceptions work just fine without RTTI when using gcc 3.4.2. dynamic_cast, on the hand, crashes without RTTI (no compilation error or warning is generated). Jeff Cohen wrote: > This may be the case with GCC, but VC++ allows exception handling to > be enabled while RTTI is disabled. According to VC++ documentation, > RTTI is needed only to support

Hi, I'm trying to use the Java front-end (which, based on svn commits, appears to be three-years-dead), and I'm running into some build errors. In that time did llvm change from building with exception handling and rtti to building without? I remember reading somewhere that llvm code should use dyn_cast instead of dynamic_cast. Do these need to be changed here? A little background:

I have a similar build tree to what you describe on Windows, but I get this: $ clang -c -emit-llvm repro_input.cpp -std=c++11 -o t.bc $ lli t.bc LLVM ERROR: Program used external function '??_7type_info@@6B@' which could not be resolved! It looks like people have already reported similar issues. Have you done anything to get past this kind of problem? On Sat, Oct 22, 2016 at 7:18 AM,

<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 couldn't find any discussion on llvm-dev pertaining to this optimization.<br>...

Why do you want to eliminate dynamic_cast and exceptions from tablegen? This is just a tool run over a few thousand lines of td files. You can't measure the difference in performance if you eliminate dynamic_cast and exceptions. I think it was a huge mistake to not use RTTI and exceptions in the compiler itself but I'm sure that old horse has been beaten to death long ago. But for

I see a bunch of definitions scattered throughout LLVM, and I could not find good documentation on them. I don't understand why they exist when LLVM is being compiled with RTTI enabled. It seems to me that: isa<T>(x) is a substitute for (dynamic_cast<T>(x) != NULL) and there are some other similar casting tools defined in Casting.h. Why should I use these instead of C++'s

I want to detect bad casts in C++ code by using the Clang compiler. The approach is similar to what Caver and TypeSan do but without using the compiler-rt. Caver and TypeSan: https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-lee.pdf https://nebelwelt.net/publications/files/16CCS2.pdf For example if I have the following C++ code snippet where I want to cast object b into

Hello, Following statement from LLVM Programmer's Manual is not compiling. CallInst* callInst = dyn_cast<CallInst>(&*basic_block_iterator_1); The gcc version is : gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8) ============ Error message ============ llvm/include/llvm/Support/Casting.h: In function 'bool llvm::isa_impl(const From&) [with To = llvm::CallInst, From =

On Oct 3, 2012, at 7:07 PM, Sean Silva <silvas at purdue.edu> wrote: > Hi all, I'm sure that the last thing that you want to think about is > TableGen's guts, but I'm pursuing a course in bringing TableGen up to > snuff with the rest of LLVM. > > Basically, I would like to introduce a "TGContext" class (by analogy > with LLVMContext) to harbor a

My understanding is that EH works fine without RTTI. However, we use typeid in LLVM in a few limited spots like lib/VMCore/Pass.cpp Reid. On Sat, 2005-04-23 at 20:12 -0700, Jeff Cohen wrote: > As far as I can tell, exceptions work just fine without RTTI when using > gcc 3.4.2. dynamic_cast, on the hand, crashes without RTTI (no > compilation error or warning is generated). > >