[Bug c++/11063] [3.3/3.4 Regression] ICE on parsing initialization list of const array member
janis187 at us dot ibm dot com
gcc-bugzilla@gcc.gnu.org
Tue Aug 5 22:45:00 GMT 2003
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11063
janis187 at us dot ibm dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at redhat dot com
------- Additional Comments From janis187 at us dot ibm dot com 2003-08-05 22:45 -------
The regression (ICE) in PR 11063 was introduced or exposed by this patch:
--- gcc/gcc/cp/ChangeLog ---
2001-01-03 Jason Merrill <jason@redhat.com>
* init.c (build_default_init): New fn.
(perform_member_init): Split out from here.
(build_new_1): Use it. Simplify initialization logic.
(build_vec_init): Take an array, rather than a pointer and maxindex.
Speed up simple initializations. Don't clean up if we're assigning.
* cp-tree.h: Adjust.
* decl2.c (do_static_initialization): Remove TREE_VEC case.
* parse.y (new_initializer): Return void_zero_node for ().
* typeck.c (build_modify_expr): Handle getting a CONSTRUCTOR.
* typeck2.c (digest_init): Only complain about user-written
CONSTRUCTORs.
The regression hunt took place on i686-pc-linux-gnu using this test
case, included here because it's slightly different from the one in the
attachment:
class Foo
{
private:
const int val_[2];
public:
Foo(int, int);
};
Foo::Foo(int v0, int v1)
: val_((int[]) {v0, v1})
{
}
Before this patch the test case got these messages:
11063.C: In constructor `Foo::Foo(int, int)':
11063.C:12: incompatible types in assignment of `int[2]' to `const int[2]'
With this test case I get the same ICE with a recent mainline compiler
built with and without checking disabled.
More information about the Gcc-bugs
mailing list