This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/72775] [6/7 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677
- From: "msebor at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 04 Aug 2016 15:13:06 +0000
- Subject: [Bug c++/72775] [6/7 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677
- Auto-submitted: auto-generated
- References: <bug-72775-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72775
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |msebor at gcc dot gnu.org
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #1)
> But before r233183 this code compiled fine.
It didn't do what one would expect at runtime, though, and neither did a
program that used the aggregate initialization (i.e., struct S { bool b; char
a[]; } s = { 1, "foo" };) because it treated the flexible array member as a
zero-length array. With the flexible array member improvements committed in
6.0, GCC accepts the latter, so it seems that the original test case should be
accepted as well, as an extension. I.e., I suggest to treat this as
ice-on-valid code.
$ cat y.C && ~/bin/gcc-5.1.0/bin/g++ -fpermissive -std=c++11 y.C && ./a.out
struct S {
bool b;
char a[] = "foo";
S () {}
} s;
int main ()
{
if (__builtin_strcmp (s.a, "foo"))
__builtin_abort ();
}
y.C:3:14: warning: initializer-string for array of chars is too long
[-fpermissive]
char a[] = "foo";
^
y.C: In constructor ‘S::S()’:
y.C:4:8: warning: initializer-string for array of chars is too long
[-fpermissive]
S () {}
^
Aborted (core dumped)