gcc/testsuite/ChangeLog:
2016-01-18 Martin Sebor <msebor@redhat.com>
PR c++/69253
* g++.dg/ext/flexary11.C: New test.
gcc/cp/ChangeLog:
2016-01-18 Martin Sebor <msebor@redhat.com>
PR c++/69253
* typeck2.c (cxx_incomplete_type_diagnostic): Handle flexible
array members.
===================================================================
@@ -498,8 +498,15 @@ cxx_incomplete_type_diagnostic (const_tr
case ARRAY_TYPE:
if (TYPE_DOMAIN (type))
{
- type = TREE_TYPE (type);
- goto retry;
+ if (TYPE_MAX_VALUE (TYPE_DOMAIN (type)))
+ {
+ type = TREE_TYPE (type);
+ goto retry;
+ }
+ /* Flexible array members have no upper bound. */
+ emit_diagnostic (diag_kind, input_location, 0,
+ "invalid use of a flexible array member");
+ break;
}
emit_diagnostic (diag_kind, loc, 0,
"invalid use of array with unspecified bounds");
===================================================================
@@ -0,0 +1,19 @@
+// PR c++/69253 - [6 Regression] g++ ICE at -O0 on x86_64-linux-gnu
+// in "cxx_incomplete_type_diagnostic"
+// { dg-do compile }
+
+struct A {
+ int n;
+ char a [];
+};
+
+void f ()
+{
+ // Compound literals and flexible array members are G++ extensions
+ // accepted for compatibility with C and GCC.
+
+ // The following use of a flexible array member in a compound literal
+ // is invalid in C and rejected by GCC in C mode and so it's also
+ // rejected in C++ mode.
+ (struct A){ 1, "" }; // { dg-error "forbids compound-literals|initialization of a flexible array member|invalid use of a flexible array member" }
+}
The attached patch fixes the ICE reported for the test case below: struct str { int a; char s[]; }; void fn1() { (struct str){1, ""}; } While I don't think the patch is incorrect as far as it goes, it's not the last word on the subject of initializing flexible array members. I uncovered a number of other problems in this area while testing the patch. First, while the patch rejects the submitted test case, it doesn't reject it when the struct is defined like so: struct str { char a, s[]; }; The other problems are variations on the case above that I came across while testing the patch. They are summarized in c++69338 - incorrect ctor initialization of a flexible array member. Since these outstanding problems are not strictly speaking a regression (the code is accepted in 5.1 with -fpermissive), rather than working up a more robust fix addressing all of these issues I think it's probably better to fix just the ICE for now (because that is a regression) and tackle the remaining problems at some later point. Martin