http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025
Richard Guenther <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2010.12.28 16:19:51 CC| |rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-28 16:19:51 UTC --- I think this is because ap is thought to escape to __builtin_va_start (which also makes it address-taken), same for __builtin_va_end. Now, with __builtin_va_end there is the problem that it also constitutes a use of ap and what that points to. <bb 2>: __builtin_va_start (&ap, 0); D.2726_2 = ap.fp_offset; if (D.2726_2 >= 176) goto <bb 4>; else goto <bb 3>; <bb 3>: D.2728_3 = ap.reg_save_area; D.2726_4 = ap.fp_offset; D.2729_5 = (long unsigned int) D.2726_4; addr.0_6 = D.2728_3 + D.2729_5; D.2726_7 = ap.fp_offset; D.2730_8 = D.2726_7 + 16; ap.fp_offset = D.2730_8; goto <bb 5>; <bb 4>: addr.0_9 = ap.overflow_arg_area; D.2732_11 = addr.0_9 + 8; ap.overflow_arg_area = D.2732_11; <bb 5>: # addr.0_1 = PHI <addr.0_6(3), addr.0_9(4)> d.1_12 = MEM[(double * {ref-all})addr.0_1]; d = d.1_12; __builtin_va_end (&ap); return; so the question is really what __builtin_va_end is allowed to do (that ap doesn't escape to those fns is obvious and easy to fix).