Removing "fno-rtti" flag from llvm-config --cxxflags

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 “dynamic_cast<>” from C++ RTTI.

Is there any way to remove the “fno-rtti” flag from the llvm-config ( seen on running “llvm-config --cxxflags” ) ?

Thanks ,

Malhar

You missed the D. All CMake definition flags need this. Try:

-DLLVM_ENABLE_RTTI=ON

Also, I’d recommend using Ninja not Unix Makefiles.

Note that LLVM did work quite well with programs using RTTI without enabling RTTI for LLVM until someone broke IR/Instructions.h about a year ago to remove the out-of-line definitions and force the vtable for several instructions to be emitted in every compilation unit including this file (i.e. a lot of them). This means that any file using RTTI that includes this header tries to emit a vtable with type info that refers to superclass objects defined elsewhere. Fixing this would make LLVM significantly more useful as a library.

David

Well, i removed the vtable from Value and Instruction recently, so that shouldn’t be a problem anymore.

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 “dynamic_cast<>” from C++ RTTI.

You missed the D. All CMake definition flags need this. Try:

-DLLVM_ENABLE_RTTI=ON

Also, I’d recommend using Ninja not Unix Makefiles.

Note that LLVM did work quite well with programs using RTTI without enabling RTTI for LLVM until someone broke IR/Instructions.h about a year ago to remove the out-of-line definitions and force the vtable for several instructions to be emitted in every compilation unit including this file (i.e. a lot of them).

FWIW that is inconsistent with the LLVM coding conventions (which ask that every class with a vtable have a non-inline anchor function) so patches I think would be welcome to fix any case where it comes up - though LLVM’s far from -Wweak-vtable clean (but if it were made clean, and then the warning were enabled - it’d probably stay fairly clean, I think).

Thank you! Next year hopefully I’ll be able to use a release build from packages and only provide a debug build from sources for my course.

On a related note, I just updated my teaching materials from 3.9 to 4.0 and found that there were almost not API changes in anything that I was using. I had to add an explicit qualification for a StringLiteral class (LLVM now has one, as does the AST in one example), replace one include with a different one, and change one call to handle an Expected return instead of ErrorOr. This is, by far, the smallest amount that I’ve had to do to update between LLVM releases ever. Thanks to everyone for keeping APIs more or less stable.

David