This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Dealing with ODR violations in GCC


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]