On Wed, Sep 7, 2016 at 6:44 PM, Richard Smith <rich...@metafoo.co.uk> wrote:
> On 7 Sep 2016 6:23 pm, "Peter Collingbourne" <pe...@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. Thanks, -- -- Peter
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
