Hi,
this error recovery regression is caused by my work for c++/70202 back
in 2016. At the time I remember wondering whether in the easy cases of
errors right at beginning of xref_basetypes (not those in the loop below
handled via dropped_base) we really wanted to proceed or immediately
bail out, as far as error recovery in concerned. This new testcase shows
that if we don't bail out early we may end up crashing much later, in
cgraph.c. Thus the straightforward fix below. Tested x86_64-linux.
Thanks, Paolo.
/////////////////////
/cp
2018-01-18 Paolo Carlini <paolo.carl...@oracle.com>
PR c++/81013
* decl.c (xref_basetypes): Early return upon error about derived
union.
/testsuite
2018-01-18 Paolo Carlini <paolo.carl...@oracle.com>
PR c++/81013
* g++.dg/inherit/union3.C: New.
Index: cp/decl.c
===================================================================
--- cp/decl.c (revision 256840)
+++ cp/decl.c (working copy)
@@ -13801,7 +13801,10 @@ xref_basetypes (tree ref, tree base_list)
CLASSTYPE_NON_LAYOUT_POD_P (ref) = true;
if (TREE_CODE (ref) == UNION_TYPE)
- error ("derived union %qT invalid", ref);
+ {
+ error ("derived union %qT invalid", ref);
+ return;
+ }
}
if (max_bases > 1)
Index: testsuite/g++.dg/inherit/union3.C
===================================================================
--- testsuite/g++.dg/inherit/union3.C (nonexistent)
+++ testsuite/g++.dg/inherit/union3.C (working copy)
@@ -0,0 +1,16 @@
+// PR c++/81013
+
+struct A
+{
+ virtual void foo() const;
+};
+
+union B : A // { dg-error "derived union 'B' invalid" }
+{
+ void foo() const;
+};
+
+void bar(const B& b)
+{
+ b.foo();
+}