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();
+}

Reply via email to