------- Additional Comments From jsm28 at gcc dot gnu dot org 2004-10-28 16:35 -------
RTH suggested:
> If we must accept this construct because it might not be
> executed, a possible solution is to notice fallback==fb_lvalue
> for a CALL_EXPR in c_gimplify_expr and create a temporary for
> the call result, and which will also satisfy the lvalue.
c_gimplify_expr doesn't have the fallback information available.
gimplify_expr does (and there's already code specific to this
sort of thing in gimplify.c), but the obvious fix
+ if (fallback == fb_lvalue)
+ *expr_p = get_initialized_tmp_var (*expr_p, pre_p, post_p);
just moves the ICE to expand_assignment (while changing the testcase
to insert an explicit temporary yields almost identical tree dumps
but without the ICE).
A related example
struct foo {char x, y, z[2];};
struct foo p, q; int r;
void bar(int baz)
{
(r ? p : q).z[baz] = 1;
}
ICEs in 3.4 as well as on mainline (in expand_assignment in both cases);
a temporary is already created in gimplifying the COND_EXPR.
While if the non-lvalue structure is the result of an assignment, 3.4 ICEs
and mainline doesn't.
struct foo {char x, y, z[2];};
struct foo p, q;
void bar(int baz)
{
(p = q).z[baz] = 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17855
