[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983
--- Comment #5 from Eric Botcazou ---
> I think it may be a bug in the odr hash function with an accidental
> hash collision but I am not sure.
The ODR hash function essentially hashes the name only here so the collision is
apparently by design. The discrepancy between x86 and ARM/SPARC comes from:
/* For ODR types be sure to compare their names.
To support -wno-odr-type-merging we allow one type to be non-ODR
and other ODR even though it is a violation. */
if (types_odr_comparable (t1, t2, true))
{
if (!types_same_for_odr (t1, t2, true))
return false;
/* Limit recursion: If subtypes are ODR types and we know
that they are same, be happy. */
if (!odr_type_p (t1) || !get_odr_type (t1, true)->odr_violated)
return true;
}
The call to get_odr_type (t1, true) is supposed to yield the warning, but this
depends on the order in which types t1 and t2 have been inserted in the table.
In other words, get_odr_type (t1, true) works on x86 and get_odr_type (t2,
true) works on ARM/SPARC, so maybe something like:
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 258068)
+++ ipa-devirt.c(working copy)
@@ -686,7 +686,10 @@ odr_subtypes_equivalent_p (tree t1, tree t2,
return false;
/* Limit recursion: If subtypes are ODR types and we know
that they are same, be happy. */
- if (!odr_type_p (t1) || !get_odr_type (t1, true)->odr_violated)
+ if (!odr_type_p (t1)
+ || !odr_type_p (t2)
+ || (!get_odr_type (t1, true)->odr_violated
+ && !get_odr_type (t2, true)->odr_violated))
return true;
}
is the proper thing to do.
[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- This also fails on SPARC64/Linux: /home/ebotcazou/src/gcc/testsuite/g++.dg/lto/pr83121_0.C:6:8: warning: type 'st\ ruct Environment' violates the C++ One Definition Rule [-Wodr]^M /home/ebotcazou/src/gcc/testsuite/g++.dg/lto/pr83121_1.C:1:8: note: a type with\ different size is defined in another translation unit^M PASS: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 6) FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8) FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_1.C line 2) FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_1.C line 3) PASS: g++.dg/lto/pr83121 cp_lto_pr83121_0.o-cp_lto_pr83121_1.o link, -O0 -flto
[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #3 from Steve Ellcey --- I tried digging into this some but was not able to come up with a fix. I compared x86, which gives the expected error messages with aarch64 which gives different errors and tried to find out where they diverged. I tracked it down to get_odr_type in ipa-devirt.c. Just before: if (val->type != type && (!val->types_set || !val->types_set->add (type))) I added this print statement: fprintf(stderr,"%p %p %p\n", (void *) type, (void *) val->type, (void *) val->types_set); On x86 I see: 0x7f98aa018dc8 0x7f98aa018930 (nil) 0x7f98aa0189d8 0x7f98aa018d20 (nil) 0x7f98aa0189d8 0x7f98aa018d20 0x32c9610 0x7f0222cbfc78 0x7f0222cbf9d8 (nil) 0x7f0222cbfa80 0x7f0222cbfa80 (nil) On Aarch64 I see: 0x4002c859aaa0 0x4002c859a758 (nil) 0x4002c859a6b0 0x4002c859a6b0 (nil) 0x4002c859a6b0 0x4002c859a6b0 (nil) 0x4001f45aa9f8 0x4001f45aa758 (nil) 0x4001f45aa800 0x4001f45aa800 (nil) I think the second line where type and val->type are the same for Aarch64 but not for x86 is where the problem is but I am not sure why we have this difference. I think it may be a bug in the odr hash function with an accidental hash collision but I am not sure.
[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, ||arm-none-linux-gnueabihf CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- As David mentioned these also fail on arm: $TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:7:10: warning: type 'struct AsyncHooks' violates the C++ One Definition Rule [-Wodr] $TOP/gcc/testsuite/g++.dg/lto/pr83121_1.C:2:10: note: a different type is defined in another translation unit $TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:8:21: note: the first difference of corresponding definitions is field 'providers_' $TOP/gcc/testsuite/g++.dg/lto/pr83121_1.C:3:21: note: a field of same name but different type is defined in another translation unit $TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:7:10: note: array types have different bounds $TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:6:8: warning: type 'struct Environment' violates the C++ One Definition Rule [-Wodr] $TOP/gcc/testsuite/g++.dg/lto/pr83121_1.C:1:8: note: a different type is defined in another translation unit $TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:10:14: note: the first difference of corresponding definitions is field 'async_hooks_' $TOP/gcc/testsuite/g++.dg/lto/pr83121_1.C:5:14: note: a field of same name but different type is defined in another translation unit $TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:7:10: note: type 'struct AsyncHooks' itself violates the C++ One Definition Rule $TOP/gcc/testsuite/g++.dg/lto/pr83121_1.C:2:10: note: the incompatible type is defined here
[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-23 CC||dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Similar to this report on aarch64/arm: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01637.html
