[PATCH, committed] SFmode arg padding and va_arg cleanup

Alan Modra amodra@bigpond.net.au
Fri Aug 6 07:58:00 GMT 2004


On Wed, Jul 28, 2004 at 12:07:02PM +0930, Alan Modra wrote:
> On Wed, Jul 28, 2004 at 11:55:47AM +0930, Alan Modra wrote:
> > Applied mainline after testing powerpc64-linux.
> > 
> > 	* config/rs6000/rs6000.c (function_arg_padding): Pad SFmode upwards.
> 
> I'd like to apply this to the 3.4 branch too.  OK?

I don't know what happened during my testing, but clearly I didn't test
the source I actually committed.  Regressions all over the place.  :-(
Sorry, I think this patch needs reverting.

As I said in http://gcc.gnu.org/ml/gcc-patches/2004-07/msg02370.html,
there's a problem with returning "none" from function_arg_padding too,
with the size of float args being calculated incorrectly.  The following
testcase shows va_arg looking in the wrong place for an arg that follows
a float, if we return "none".  It also happens to show the current
breakage when returning "upward"..

int foo (float f1, ...)
{
  __builtin_va_list ap;

  if (f1 != 1.0f)
    return 1;

  __builtin_va_start (ap, f1);
  if (__builtin_va_arg (ap, int) != 2)
    return 2;

  __builtin_va_end (ap);
  return 0;
}

int main (void)
{
  return foo (1.0f, 2);
}

There is also a problem in that returning "none" doesn't actually do the
right thing according to the current ABI:  SFmode, when passed in gprs
as well as fprs (eg. non-prototyped function) is passed in the least
significant end of the gpr, which corresponds to the second word of a
doubleword in the parameter save area.

So, I'm inclined to think that both patches should be reverted, and we
modify the ppc64 ABI to state that floats are passed in the second word
of a doubleword.  ie. in the word with the higher address.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre



More information about the Gcc-patches mailing list