This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C frontend] Fix construction of TYPE_STUB_DECL

> On 05/21/2015 04:32 PM, Jan Hubicka wrote:
> >I think at LTO time it is useful to have two things
> >   - be able to say what type comply C++ ODR rule, because we special case these
> >     for ODR warnings
> >   - be able to say at LTO time what types are anonymous, that is they are not
> >     compatible with any type from other unit.
> ...where the second group is a subset of the first; in languages
> that use structural compatibility, anonymous types can be
> compatible.
> >Either a special flag TYPE_ODR_P set by C++ FE on all types that comply ODR rule
> >or making TYPE_PUBLIC (TYPE_STUB_DECL (t)) to reliably identify that type is
> >anonymous (or an equivalent) would fix the two issues.
> It seems that we've been establishing which types have linkage by
> setting their DECL_ASSEMBLER_NAME.  It seems that the problem is
> coming from leaving it unset for types with internal (anonymous)
> linkage, so you're trying to check TREE_PUBLIC instead, which breaks
> with other front ends. Perhaps we should set DECL_ASSEMBLER_NAME for
> internal C++ types to some magic value?

This would also work, yes.  We can set it into something like "<anonymous>".
One problem would be that type_with_linkage_p/type_in_anonymous_namespace_p
would not work on non-C++ types without LTO (because then we do not produce the
type manglings). I suppose it is not really a problem because only
place I use them is the devirtualization machinery and that won't get any
polymorphic types for other languages.

I suppose I can drop type_in_anonymous_namespcae_p in tree.c and make
mangle_decl to set "anonymous" for those?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]