Re: False ODR violation positives on anonymous namespace types

[Jan Hubicka <hubicka at ucw dot cz>]

> On 05/11/2015 01:05 PM, Jan Hubicka wrote:
> >>On 05/11/2015 12:46 PM, Jan Hubicka wrote:
> >>>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.
> >>
> >>In what context?  Won't you get that from comparing e.g. the field
> >>types of two definitions of the same class?
> >
> >If one class define "int foo;" and other "long foo;" we currently do not complain
> >about ODR on 32bit targets while I think we could.
> 
> We certainly should.  But that's a problem because foo is subject to
> the ODR.  I don't see why you need to treat int as an ODR type to
> get checking for foo.

What happens in LTO is that lto-symtab decide to merge the two declarations of
foo.  At this time it has chance to output the warning.  For that it needs to
be able to work out that these declarations are having different types, but
because LTO merge canonical types on structural basis, types_compatible_p
(long, int) will return true. The idea behind LTO canonical type computation is
that it needs to safely work cross-language and if the two declarations came
from C and fortran, the mismatch in type name is useless
(see gimple_canonical_types_compatible_p)

So what I want is to have odr_or_derived_type_p to return true on those types
(because it sees they do have mangled name attached) and then call
odr_types_equivalent_p which is the same comparer I use to output ODR waring
about types and it will complain about mangled type names being different.
This is already implemented in
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00870.html

Honza
> 
> Jason