> 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
