> On Sun, May 10, 2015 at 7:33 PM, Jan Hubicka <hubi...@ucw.cz> wrote: > > Hi, > > TREE_PUBLIC of TYPE_DECL is defined to say if the type is public: > > /* In a VAR_DECL, FUNCTION_DECL, NAMESPACE_DECL or TYPE_DECL, > > nonzero means name is to be accessible from outside this translation > > unit. > > In an IDENTIFIER_NODE, nonzero means an external declaration > > accessible from outside this translation unit was previously seen > > for this name in an inner scope. */ > > #define TREE_PUBLIC(NODE) ((NODE)->base.public_flag) > > > > This is properly honored by C++ FE but other FEs are bit random, which in > > turn > > confuses type_in_anonymous_namespace_p predicate that leads to flase > > poistives > > on type mismatch warnings. I used to be able to get around by checking only > > C++ types at LTO time, but with type checking in lto-symtab I can not, > > because > > I do want to compare type compatibility cross translation units and cross > > languages > > and we have no reliable way to say what type originated as C++ and what did > > not. > > The idea was you can walk up the context chain until you reach a > TRANSLATION_UNIT_DECL > where the source language is encoded in... of course most FEs are > quite lazy here and > eventually end up at NULL_TREE instead.
Yep, I can walk up and look for NAMESPACE_DECL without TREE_PUBLIC flag, too, or cleanup the flag in free_lang_data when I know if we do C++ (probably). The predicate for anonymous_namespace is called on few quite hot paths in devirt code, but that is not my main concern either. In general I think we ought to fix frontends to agree with each other (and docs) on how to represent semantics instead of adding special cases and workarounds to middle-end/LTO. I am trying to keep the anonymous namespace thing indepent of C++. While I am not sure we support other language with similar notion, it seems to make sense independently of C++. After all, it gives the type escape info for free :) Honza > > Richard.
