https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77450
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|ice-on-valid-code |ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-09-02
CC| |jsm28 at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Target Milestone|--- |5.5
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The FE creates (on trunk)
VIEW_CONVERT_EXPR<int[1]>(<<< Unknown tree: compound_literal_expr
V D.1794 = { 0 }; >>>)[0] = 0;
which is gimplified to
foo ()
{
V D.1794;
D.1794 = { 0 };
BIT_FIELD_REF <D.1794, 32, 0> = 0;
the issue is that D.1794 is marked as DECL_GIMPLE_REG_P but that is bougs
(and shows after into-SSA).
I believe the testcase is invalid and ought to be rejected - you can't
write to {}.
Breakpoint 5, convert_vector_to_array_for_subscript (loc=180896,
vecp=0x7fffffffcef0, index=<integer_cst 0x7ffff68a4048>)
at /space/rguenther/src/svn/trunk/gcc/c-family/c-common.c:12711
(gdb) p debug_generic_expr (*vecp)
<<< Unknown tree: compound_literal_expr
V D.1794 = { 0 }; >>>
$1 = void
(gdb) n
12712 ret = !lvalue_p (*vecp);
(gdb)
12714 if (TREE_CODE (index) == INTEGER_CST)
(gdb) p ret
$2 = false
so it looks like COMPOUND_LITERAL_EXPR is an lvalue? Do we need to
handle COMPOUND_LITERAL_EXPR by emitting a COMPOUND_EXPR with the
second stmt operating on DECL_EXPR_DECL (COMPOUND_LITERAL_EXPR_DECL_EXPR
(*vecp))? Or is the error on the gimplification side (in setting
DECL_GIMPLE_REG_P)? Which would mean that eventually
c_common_mark_addressable_vec doesn't handle COMPOUND_LITERAL_EXPR correctly.
