libffi fails to build on powerpc64-linux

[Peter Bergner <bergner at vnet dot ibm dot com>]

After the latest libffi merge into GCC, GCC no longer builds on
powerpc64-linux due to the following errors:

/home/bergner/gcc/gcc-mainline-testsuite-base/libffi/src/powerpc/ffi.c: In function âffi_prep_args_SYSVâ:
/home/bergner/gcc/gcc-mainline-testsuite-base/libffi/src/powerpc/ffi.c:199:4: error: âdouble_tmpâ undeclared (first use in this function)
/home/bergner/gcc/gcc-mainline-testsuite-base/libffi/src/powerpc/ffi.c:199:4: note: each undeclared identifier is reported only once for each function it appears in
/home/bergner/gcc/gcc-mainline-testsuite-base/libffi/src/powerpc/ffi.c:215:6: error: label âsoft_double_prepâ used but not defined
/home/bergner/gcc/gcc-mainline-testsuite-base/libffi/src/powerpc/ffi.c: In function âffi_closure_helper_SYSVâ:
/home/bergner/gcc/gcc-mainline-testsuite-base/libffi/src/powerpc/ffi.c:1135:8: error: âtempâ undeclared (first use in this function)


Building upstream libffi code directly, it fails exactly the same way.
The "double_tmp" and "temp" errors are easily fixed with the following
obvious patch:

diff --git a/src/powerpc/ffi.c b/src/powerpc/ffi.c
index 1920c91..191b9dc 100644
--- a/src/powerpc/ffi.c
+++ b/src/powerpc/ffi.c
@@ -146,6 +146,7 @@ ffi_prep_args_SYSV (extended_cif *ecif, unsigned *const stack)
   gpr_base.u = stacktop.u - ASM_NEEDS_REGISTERS - NUM_GPR_ARG_REGISTERS;
   intarg_count = 0;
 #ifndef __NO_FPRS__
+  double double_tmp;
   fpr_base.d = gpr_base.d - NUM_FPR_ARG_REGISTERS;
   fparg_count = 0;
   copy_space.c = ((flags & FLAG_FP_ARGUMENTS) ? fpr_base.c : gpr_base.c);
@@ -1132,7 +1133,7 @@ ffi_closure_helper_SYSV (ffi_closure *closure, void *rvalue,
 
          if (nf < 8)
            {
-             temp = pfr->d;
+             double temp = pfr->d;
              pfr->f = (float) temp;
              avalue[i] = pfr;
              nf++;

But I'm not confident enough to place the missing âsoft_double_prepâ label.
Can someone more familiar with this code patch that and then remerge the
updated code into GCC?  I'm willing to help build and test any patch
someone comes up with.

As an FYI, I'll mention I opened a GCC bugzilla to track this on the
GCC side of things:

    http://gcc.gnu.org/PR52497


Peter