Re: False ODR violation positives on anonymous namespace types

[Jan Hubicka <hubicka at ucw dot cz>]

> On 05/11/2015 09:28 AM, Jan Hubicka wrote:
> >We already discussed earlier that type_in_anonymous_namespace_p is not working
> >on compund types, because these do not have TYPE_STUB_DECL.  I thought those are
> >!TYPE_NAME types.  What is reason for !TYPE_NAME type with no TYPE_STUB_DECL?
> >Is it always a compound type with typedef name?
> 
> Right.  Typedef names have no linkage, so they aren't really ODR
> types; only classes and enums have linkage.  Why do you want to
> check other types?

Well, my main motivatoin to extend from RECORD_OR_UNION_TYPE_P was to handle
enums. But other case I would like to deal with are integer types - i.e. preserve
difference between char/signed char/unsigned char/short/int/long/wchar in cases
where they structurally coincide.  

This makes us to output better diagnostics on ODR violations caused by -fsigned-char
mismatches, but it also has some issues with fact that LTO forcingly merge char_type_node
no matter whetehr it agrees or disagress across units by preloading
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01538.html

I can go with  RECORD_OR_UNION_TYPE_P (..) || TREE_CODE (type) == ENUMERAL_TYPE
with comment that those types have linkage and other not, but we lose some checks.

Honza
> 
> Jason