search for: __dynamic_cast

...M3UOE&t=1306</a><br>I couldn't find any discussion on llvm-dev pertaining to this optimization.<br><br>What is the optimization (TL;DR version):<br>The tranformation tries to convert a <font face="Default Monospace,Courier New,Courier,monospace">__dynamic_cast</font> function call, into an address comparison and VFT-like lookup, when the following conditions are met:<br> 1. the destination type is a leaf type, i.e. is never derived from (similar to C++ final semantics) in the entire program.<br> 2. the static type of the expression be...

...ssue 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 detect this problem, but that's kind of messy. I'm hoping for a better solution with llvm… (Mac OS X 10.6/10.7, clang 3.0) Thanks, Ákos Somorjai Developer Support Manager GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | asomorjai at graphisoft.com -----------...

...ference to 'typeinfo for std::type_info' ../projects/compiler-rt/lib/ubsan/ubsan_type_hash_itanium.cc:233: error: undefined reference to 'typeinfo for __cxxabiv1::__class_type_info' ../projects/compiler-rt/lib/ubsan/ubsan_type_hash_itanium.cc:233: error: undefined reference to '__dynamic_cast' [...] Looks like ubsan no longer links to libc++abi ? (I see -lgcc_s -lc -ldl -lrt -lpthread on the linker line.) This configuration has worked with r308719 so I am guessing this is a regression. Regards, ismail

...#39; >> ../projects/compiler-rt/lib/ubsan/ubsan_type_hash_itanium.cc:233: >> error: undefined reference to 'typeinfo for >> __cxxabiv1::__class_type_info' >> ../projects/compiler-rt/lib/ubsan/ubsan_type_hash_itanium.cc:233: >> error: undefined reference to '__dynamic_cast' >> [...] >> >> Looks like ubsan no longer links to libc++abi ? (I see -lgcc_s -lc >> -ldl -lrt -lpthread on the linker line.) >> >> This configuration has worked with r308719 so I am guessing this is a >> regression. > > This might have done it:...

...://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 detect this problem, but that's kind of messy. I'm hoping for a better solution with llvm… > > (Mac OS X 10.6/10.7, clang 3.0) > > Thanks, > Ákos Somorjai > Developer Support Manager > > GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | a...

...++ method to add my passes. When using this machinery with llvm-ld (Slackware 10.2, GCC 3.3.6 and LLVM 1.8a), my passes are indeed loaded in and the PassManager attempts to run on the processed module. Then, I get the following: Program received signal SIGSEGV, Segmentation fault. 0xb7f16abf in __dynamic_cast () from /usr/lib/libstdc++.so.5 #0 0xb7ea9abf in __dynamic_cast () from /usr/lib/libstdc++.so.5 #1 0x0843f19d in llvm::PMDebug::PrintArgumentInformation (P=0x85e3b00) at /.../llvm/lib/VMCore/Pass.cpp:132 #2 0x0843f1fc in llvm::PMDebug::PrintArgumentInformation (P=0x85ca030) at /.../llvm/lib/V...

.... Therefore yes, we have the same issues with symbol visibility and vague linkage. > 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 detect this problem, but that's kind of messy. I'm hoping for a better solution with llvm… The best solution, bar none, is to avoid the need for vague linkage on your RTTI objects. If they correspond to polymorphic class types, which presumably they do if your problems are with dynamic...

Hi Bram, On Wed, 2006-08-16 at 22:41 +0200, Bram Adams wrote: > Op 16-aug-06, om 18:59 heeft Reid Spencer het volgende geschreven: > Are there any workarounds (using other LLVM-tools) to link a native > library with LLVM-bytecode? Yes. The general approach is to use llvm-as, llvm-dis, opt and llvm-link to work with the bytecode. You can also use gccld and gccas to run some canned

Hi, Op 16-aug-06, om 18:59 heeft Reid Spencer het volgende geschreven: >> llvm-ld: warning: Supposed library 'SOME_OTHER_LIB' isn't a library. > > The -l option is used to link libraries into the resulting executable. > I'm hoping "SOME_OTHER_LIB" is not the actual name and you're just > paraphrasing the actual command line. Note that native

...> When using this machinery with llvm-ld (Slackware 10.2, GCC 3.3.6 and > LLVM 1.8a), my passes are indeed loaded in and the PassManager > attempts to run on the processed module. Then, I get the following: > > Program received signal SIGSEGV, Segmentation fault. > 0xb7f16abf in __dynamic_cast () from /usr/lib/libstdc++.so.5 > > #0 0xb7ea9abf in __dynamic_cast () from /usr/lib/libstdc++.so.5 > #1 0x0843f19d in llvm::PMDebug::PrintArgumentInformation > (P=0x85e3b00) at /.../llvm/lib/VMCore/Pass.cpp:132 > #2 0x0843f1fc in llvm::PMDebug::PrintArgumentInformation > (P=0...

I was trying to build llvm + clang with cmake cache PGO.cmake and ninja stage2. I used the 4.0.0 final tag vfrom svn. This seems to work for me. I added libcxx, libcxxabi, llld etc. And now I get the following cmake error. -- Performing Test LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG -- Performing Test LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG - Failed CMake Error at projects/libcxx/CMakeLists.txt:396

...e GCC does. Therefore yes, we have the same issues with symbol visibility and vague linkage. 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 detect this problem, but that's kind of messy. I'm hoping for a better solution with llvm… The best solution, bar none, is to avoid the need for vague linkage on your RTTI objects. If they correspond to polymorphic class types, which presumably they do if your problems are with dynamic...