[llvm-dev] [LLVMdev] Ideas for making llvm-config --cxxflags more useful

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 7 10:32:51 PDT 2015

On Fri, Aug 7, 2015 at 10:22 AM, Hans Wennborg via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Thu, Aug 6, 2015 at 12:04 PM, David Chisnall via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > [Ooops, sent to the old list address by mistake]
> >
> > On 30 Jul 2015, at 21:04, tom at stellard.net wrote:
> >>
> >> For flags like -fno-rtti (are there others?) that are required in some
> cases
> >> (I think -fno-rtti is required only if you sub-class LLVM objects), I
> would propose
> >> adding a separate flag like --uses-rtti.  This would give users more
> fine-grained
> >> control over which flags they use, and also would let them choose the
> correct
> >> flag since, for example, -fno-rtti is not understood by MSVC.
> >
> > There appears to be a regression in LLVM 3.7, which means that you must
> compile with -fno-rtti if you include llvm’s Instructions.h.  The issue is
> that a few of the classes (ICmpInst, GetElementPtrInst and PHINode) are now
> defined entirely in the header, so every compilation unit that includes the
> header will emit them.  These classes all inherit from Instruction
> (indirectly via CmpInst in the case of ICmpInst) and so fail to link if
> compiled with -fno-rtti, because they can’t find the vtable for ICmpInst.
> I looked at the file, and this didn't seem true (e.g.
> GetElementPtrInst::init is still out-of-line). But then I realized you
> mean virtual functions, so these classes no longer have a key
> function.
> This is probably Pete's r240588. I suppose we could add key functions
> to these classes (even if they're not used for anything). I'm not sure
> how we'd prevent this from regressing though :-/

In theory the LLVM style guide mandates key functions for all dynamic
classes (under the claim of build performance - avoiding duplicate vtable
emission, etc). We've never strongly enforced it though - if we really
wanted to, we could do so as Clang has a warning that triggers whenever a
vtable is emitted weakly (which is what happens when there isn't a key

- David

>  - Hans
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150807/39d33b4c/attachment.html>

More information about the llvm-dev mailing list