On 11/25/2015 02:10 PM, Jan Hubicka wrote:
The problem here is that we're trying to compare the TYPE_FIELDS of
two variants of an incomplete type, which doesn't make sense; we
shouldn't expect TYPE_FIELDS of an incomplete type to be meaningful.
Tested x86_64-pc-linux-gnu. OK for trunk?
commit c6f5cd55d0bbebc2fa46628ebb8fdec2a44abf3a
Author: Jason Merrill <ja...@redhat.com>
Date: Wed Nov 25 10:47:03 2015 -0500
PR middle-end/66214
* tree.c (gimple_canonical_types_compatible_p) [RECORD_TYPE]:
Don't try to compare the fields of incomplete types.
This makes sense to me. I would still add a check that incomplete types have to
TYPE_FIELDS during LTO so we are sure that all types are either completed or
have no fields at all once the frontends are done.
Like this?
commit f264166c7358de8eb1c499e2c0a80f8f7cf2d100
Author: Jason Merrill <ja...@redhat.com>
Date: Wed Nov 25 17:05:47 2015 -0500
assert
diff --git a/gcc/tree.c b/gcc/tree.c
index e918e1b..0108e80 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -13429,6 +13429,12 @@ gimple_canonical_types_compatible_p (const_tree t1, const_tree t2,
if (!COMPLETE_TYPE_P (t1) && !COMPLETE_TYPE_P (t2))
return true;
+ /* In LTO, incomplete types should always have null TYPE_FIELDS. */
+ if (in_lto_p)
+ gcc_checking_assert
+ ((COMPLETE_TYPE_P (t1) || TYPE_FIELDS (t1) == NULL_TREE)
+ && (COMPLETE_TYPE_P (t2) || TYPE_FIELDS (t2) == NULL_TREE));
+
if (TYPE_REVERSE_STORAGE_ORDER (t1) != TYPE_REVERSE_STORAGE_ORDER (t2))
return false;
