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).