https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102683
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason at gcc dot gnu.org --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- Now, for some reason we initialize 'y' which is clearly not necessary: y = .DEFERRED_INIT (32, 2, 0); if (n == 1) goto <D.1920>; else goto <D.1921>; <D.1920>: y = x; goto <D.1922>; <D.1921>: y = *.LC1; <D.1922>: and the suggested patch fixes the ICE during expansion. But we should avoid the .DEFERRED_INIT here. The GENERIC is struct C y; <<cleanup_point <<< Unknown tree: expr_stmt (void) (y = n == 1 ? TARGET_EXPR <D.1917, x> : TARGET_EXPR <D.1916, {.c=__complex__ (3.0e+0, 3.0e+0)}>) >>>>>; so we have first stmt <decl_expr 0x7ffff6666da0 type <void_type 0x7ffff6558f18 void> side-effects arg:0 <var_decl 0x7ffff7ff52d0 y> t.i:10:5 start: t.i:10:5 finish: t.i:10:5> and then stmt <cleanup_point_expr 0x7ffff6666e00 type <void_type 0x7ffff6558f18 void> side-effects arg:0 <expr_stmt 0x7ffff6666de0 type <void_type 0x7ffff6558f18 void> side-effects arg:0 <convert_expr 0x7ffff6666dc0 type <void_type 0x7ffff6558f18 void> side-effects arg:0 <init_expr 0x7ffff66810a0 type <record_type 0x7ffff6663d20 C> side-effects arg:0 <var_decl 0x7ffff7ff52d0 y> arg:1 <cond_expr 0x7ffff66772d0 type <record_type 0x7ffff6663d20 C> ... so this is an INIT_EXPR which never(?) requires .DEFERRED_INIT? Of course we're instrumenting the DECL_EXPR, not the INIT_EXPR and at that point we didn't see the INIT_EXPR. I wonder if we want a bit on DECL_EXPR denoting whether the decl is fully initialized?