This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Dealing with ODR violations in GCC
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Martin Liška <mliska at suse dot cz>
- Cc: gcc at gcc dot gnu dot org, jason at redhat dot com
- Date: Tue, 17 Feb 2015 01:27:04 +0100
- Subject: Re: [RFC] Dealing with ODR violations in GCC
- Authentication-results: sourceware.org; auth=none
- References: <20140912054042 dot GB10910 at kam dot mff dot cuni dot cz> <54B66FB9 dot 8050607 at suse dot cz> <20150115054758 dot GB11672 at atrey dot karlin dot mff dot cuni dot cz> <54DE4857 dot 3090601 at suse dot cz>
Hi,
the warning about types of fields seems misplaced:
> ../../third_party/WebKit/public/platform/WebCryptoAlgorithmParams.h:295:0: warning: type ???struct WebCryptoEcKeyImportParams??? violates one definition rule [-Wodr]
> class WebCryptoEcKeyImportParams : public WebCryptoAlgorithmParams {
> ^
> ../../third_party/WebKit/public/platform/WebCryptoAlgorithmParams.h:295:0: note: a different type is defined in another translation unit
> class WebCryptoEcKeyImportParams : public WebCryptoAlgorithmParams {
> ^
> ../../third_party/WebKit/public/platform/WebCryptoAlgorithmParams.h:307:0: note: the first difference of corresponding definitions is field ???m_namedCurve???
> const WebCryptoNamedCurve m_namedCurve;
> ^
> ../../third_party/WebKit/public/platform/WebCryptoAlgorithmParams.h:295:0: note: a field of same name but different type is defined in another translation unit
> class WebCryptoEcKeyImportParams : public WebCryptoAlgorithmParams {
> ^
> ../../third_party/WebKit/public/platform/WebCryptoAlgorithm.h:78:0: note: type ???const WebCryptoNamedCurve??? should match type ???const WebCryptoNamedCurve???
> enum WebCryptoNamedCurve {
> ^
> ../../third_party/WebKit/public/platform/WebCryptoAlgorithm.h:79:0: note: the incompatible type is defined here
> WebCryptoNamedCurveP256,
> ^
Not sure how it can happen, but will take a look. The third note should not point to the type itself but to the field.
> ../../third_party/icu/source/i18n/unicode/fieldpos.h:106:0: warning: virtual table of type ???struct FieldPosition??? violates one definition rule
> class U_I18N_API FieldPosition : public UObject {
> ^
> ../../third_party/icu/source/i18n/unicode/fieldpos.h:106:0: note: the conflicting type defined in another translation unit
> class U_I18N_API FieldPosition : public UObject {
> ^
> ../../third_party/icu/source/i18n/unicode/fieldpos.h:106:0: note: virtual method ???_ZTIN6icu_5213FieldPositionE???
> class U_I18N_API FieldPosition : public UObject {
> ^
> ../../third_party/icu/source/i18n/format.cpp:125:0: note: ought to match virtual method ???__comp_dtor ??? but does not
> Format::format(const Formattable& /* unused obj */,
> ^
This should warn about different number of entries in the table rather than insisting that typeinfo should match destructor.
Jason, I wonder if there is more informative way to print destructor during LTO than as __comp_dtor? Laos for named types,
perhaps printing just type name instead of the wrong "struct typename" (because we make no difference between struct and
class at LTO) would be cleaner.
Honza