https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #4) > > At least in linux64_closure.S, perhaps guarding it with #ifdef __VEC__ might > > be ok, because the C code will not use that code if __VEC__ isn't defined: > > #elif !defined(__VEC__) > > /* If compiled without vector register support (used by assembly)... */ > > if ((cif->abi & FFI_LINUX_LONG_DOUBLE_IEEE128) != 0) > > return FFI_BAD_ABI; > > But not sure about linux64.S if it doesn't suffer from the same problem. > > Note that __VEC__ does not mean the current CPU can execute those insns, > of course, so these #ifdefs are only good if you compile this file twice, > or similar? Sure. I think the expectation is that one gets the ieee128 long double support in libffi only if libffi is built with -mcpu=power8 (or -mcpu=power7 or -mvsx). And the assumption is that the *.S files are compiled with the same -mcpu=/-mvsx flags as the C files. So the only question is if all the lvx/stvx instructions are in code path that will not be reached when __VEC__ support isn't seen on the C side. The whole inital patch is: https://github.com/libffi/libffi/commit/73dd43afc8a447ba98ea02e9aad4c6898dc77fb0
