[PATCH] D22642: CodeGen: Clean up implementation of vtable initializer builder. NFC.
Peter Collingbourne via cfe-commits
cfe-commits at lists.llvm.org
Wed Sep 7 18:59:23 PDT 2016
On Wed, Sep 7, 2016 at 6:44 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On 7 Sep 2016 6:23 pm, "Peter Collingbourne" <peter at pcc.me.uk> wrote:
> pcc marked 4 inline comments as done.
> Comment at: lib/CodeGen/CGVTables.cpp:588
> @@ +587,3 @@
> + if (auto *F = dyn_cast<llvm::Function>(Cache))
> + F->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
> + Cache = llvm::ConstantExpr::getBitCast(Cache, CGM.Int8PtrTy);
> rsmith wrote:
> > Do you have any idea why we're doing this? It looks wrong to me. These
> ABI entry points are exposed and could certainly have their addresses taken
> and used in this translation unit.
> I introduced this in D18071. Although a translation unit can take the
> address of one of these functions, that would involve declaring a function
> with a reserved name, so I believe we'd be allowed to impose restrictions
> such as `unnamed_addr` on the address.
> These are declared by <cxxabi.h>, and thus presumably intended to be
> useable by programs, so I'm not convinced that reasoning applies.
cxxabi.h isn't part of the standard, is it? So whatever it does shouldn't
have an effect on the standard.
> Do we gain anything from this?
Not at present (the relative ABI is the only user I know of and that isn't
fully implemented yet on trunk), although something like this may be
required if we ever fully implement the relative ABI.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits