Re: rs6000 PPC32 SVR4 ABI long double function return bug

[Jim Wilson <wilson at redhat dot com>]

>	32-bit SVR4 long double support has not been implemented in the
>GCC rs6000 port.

I missed that part.  Yes, the testsuite I have is testing 128-bit long double
ABI support.  Regardless of whether 128-bit long doubles are usable, we should
still get the calling convention correct, so my patch still stands.  There
are presumably other 32-bit PPC SVR4 compilers that have 128-bit long doubles,
and we need to get it right so that we can interoperate with them.

If no one is currently using 128-bit long doubles, then that makes things a
little simpler, since we wouldn't be introducing an ABI change, and thus we
don't need to worry about backwards compatibility.

It is better to get the calling convention support correct now in case we
switch to a 128-bit long double format in the future.

I see that the rs6000/sysv4.h file has all of the _q_* library functions
defined for long double arithmetic, so it looks like it might work if the
library functions were available.

> Optionally utilizing the IBM 128-bit long double format in the
>32-bit PPC SVR4 port of GCC requires that the port follow the IBM 128-bit
>long double ABI -- returning long double in FPRs -- when invoking that
>long double variant.

I am not interested in trying to get the 32-bit PPC SVR4 ABI changed.  I
merely want gcc to follow the existing published standard, as it claims to
do.

I see that the IBM format is a pair-of-doubles format.  It is only used for
the AIX and DARWIN ABIs, so I don't believe that there is any conflict with
my patch, as my patch only affects the SVR4 ABI support.

Jim