On Fri, 2004-01-02 at 09:11, Steven G. Johnson wrote: > Steven G. Johnson wrote: > > Can you tell us whether -mabi=altivec is really required for programs > > calling FFTW? I never did figure out exactly what this flag does on > > Linux. (It is not needed for 16-byte stack alignment, apparently, since > > I think that is guaranteed by the SVR4 ABI.) > > I checked with my co-author on this, and there is an additional problem: > > Currently, FFTW detects Altivec by reading an altivec register that says > whether it is enabled...on other machines, e.g. a G3, this causes a > SIGILL and we use setjmp/longjmp to recover from the trap. However, > last he checked, gcc -mabi=altivec caused setjmp/longjmp to try to save > altivec registers, failing on the G3. There are several possible > workarounds, but since the ABI seemed incompatible we gave it up as a > lost cause.
Well... that's a problem, though I expect glibc to deal with that more gracefully... Possibly only an upcoming version. > So, with the current version of FFTW, the runtime Altivec detection will > not work under Linux on non-Altivec machines (last we checked), and > should therefore be disabled in the standard Debian ppc package. You can detect differently by using the ELF AUX tables passed by the kernel to any executable. The AT_HWCAP entry contains "feature" bits, one of them indicating the support of Altivec, see the kernel include/asm/cputable.h for the bit definitions. > If you can assure us that the ABIs are compatible on Debian, and that > -mabi=altivec won't cause FFTW to fail on e.g. a G3 for other reasons, > we can revisit this issue and try to come up with a way to detect > Altivec support properly at runtime. (There is also still the question > of whether altivec-FFTW-calling programs need -mabi=altivec, and whether > this will break them on non-altivec architectures.)
