This is the mail archive of the
mailing list for the GCC project.
Re: False ODR violation positives on anonymous namespace types
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 11 May 2015 23:39:49 +0200
- Subject: Re: False ODR violation positives on anonymous namespace types
- Authentication-results: sourceware.org; auth=none
- References: <20150511142810 dot GA6584 at kam dot mff dot cuni dot cz> <5550E3D2 dot 2080408 at redhat dot com> <20150511174607 dot GB59663 at kam dot mff dot cuni dot cz> <5550ECB5 dot 8000607 at redhat dot com> <20150511180509 dot GB22960 at kam dot mff dot cuni dot cz> <55511D40 dot 1010808 at redhat dot com>
> 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
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