libffi fails to build on powerpc64-linux

Peter Bergner bergner@vnet.ibm.com
Mon Mar 5 22:56:00 GMT 2012


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






More information about the Libffi-discuss mailing list