> On 06/30/2014 03:27 PM, Jan Hubicka wrote: > >This catches two cases in C++ FE and several other cases elsewhere. > >Does something like this make sense? I think bulitin_types are > >generally public, but I am not quite sure about templates. > > Template parms have no linkage, but they certainly don't prevent a > template from being public. So I guess setting TREE_PUBLIC makes > sense. > > >I also wonder if I should copy > >PUBLIC flag from component type in complex numbers - can we produce complex > >number from anonymous type? > > Only from built-in types I think, but it wouldn't hurt to copy > TREE_PUBLIC from component_type.
OK, I updated my copy of the patch. > > >Finally type_in_anonymous_namespace_p needs to be extended into two cases > >where > >the type is considered nonanonymous by lack of DECL_NAME. > > I would think the right fix is to avoid calling it for non-class types? I am trying to make LTO tree streaming to not unify types that are known to be local to a compilation unit. This allows better TBAA to be preserved, since two anonymous namespace types from two different unit are not the same. I want to avoid the overhead of SCC hashing and canonical type computation for these and here I want the concept of anonymous namespace types to be closed upwards. That is if I have type that is not considered anonymous it should not be built from non-anonymous types. So here I need to test anonymity of non-class types... Thanks for looking into this! Honza
