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

Reply via email to