const.
Chris@19: --enable-3dnow and --enable-k7?
Chris@19:
Chris@19: We have successfully used gcc 3.2.x on x86 and PPC, a recent Compaq C compiler for Alpha, version 6 of IBM's
Chris@19: xlc compiler for AIX, Intel's icc versions 5-7, and Sun WorkShop cc version 6.
Chris@19:
Chris@19: FFTW is likely to push compilers to their limits, however, and several Chris@19: compiler bugs have been exposed by FFTW. A partial list follows. Chris@19: Chris@19:
Chris@19: gcc 2.95.x for Solaris/SPARC produces incorrect code for
Chris@19: the test program (workaround: recompile the
Chris@19: libbench2 directory with -O2).
Chris@19:
Chris@19: NetBSD/macppc 1.6 comes with a gcc version that also miscompiles the test program. (Please report a workaround if you know
Chris@19: one.)
Chris@19:
Chris@19: gcc 3.2.3 for ARM reportedly crashes during compilation.
Chris@19: This bug is reportedly fixed in later versions of
Chris@19: gcc.
Chris@19:
Chris@19: Versions 8.0 and 8.1 of Intel's icc falsely claim to be gcc, so you should specify CC="icc -no-gcc"; this is automatic in FFTW 3.1. icc-8.0.066 reportely produces incorrect code for FFTW 2.1.5, but is fixed in version 8.1.
Chris@19: icc-7.1 compiler build 20030402Z appears to produce
Chris@19: incorrect dependencies, causing the compilation to fail.
Chris@19: icc-7.1 build 20030307Z appears to work fine. (Use
Chris@19: icc -V to check which build you have.) As of 2003/04/18,
Chris@19: build 20030402Z appears not to be available any longer on Intel's
Chris@19: website, whereas the older build 20030307Z is available.
Chris@19:
Chris@19:
Chris@19: ranlib of GNU binutils 2.9.1 on Irix has been observed to corrupt the FFTW libraries, causing a link failure when
Chris@19: FFTW is compiled. Since ranlib is completely superfluous on Irix, we suggest deleting it from your system and replacing it with
Chris@19: a symbolic link to /bin/echo.
Chris@19:
Chris@19: If support for SIMD instructions is enabled in FFTW, further compiler Chris@19: problems may appear: Chris@19:
Chris@19: gcc 3.4.[0123] for x86 produces incorrect SSE2 code for
Chris@19: FFTW when -O2 (the best choice for FFTW) is used, causing
Chris@19: FFTW to crash (make check crashes). This bug is fixed in gcc 3.4.4. On x86_64 (amd64/em64t), gcc 3.4.4 reportedly still has a similar problem, but this is fixed as of
Chris@19: gcc 3.4.6.
Chris@19:
Chris@19: gcc-3.2 for x86 produces incorrect SIMD code if
Chris@19: -O3 is used. The same compiler produces incorrect SIMD
Chris@19: code if no optimization is used, too. When using
Chris@19: gcc-3.2, it is a good idea not to change the default
Chris@19: CFLAGS selected by the configure script.
Chris@19:
Chris@19: Some 3.0.x and 3.1.x versions of gcc on x86 may crash. gcc so-called 2.96 shipping with RedHat 7.3 crashes
Chris@19: when compiling SIMD code. In both cases, please upgrade to
Chris@19: gcc-3.2 or later.
Chris@19:
Chris@19: Intel's icc 6.0 misaligns SSE constants, but FFTW has a
Chris@19: workaround. icc 8.x fails to compile FFTW 3.0.x because it
Chris@19: falsely claims to be gcc; we believe this to be a bug in icc, but FFTW 3.1 has a workaround.
Chris@19:
Chris@19: Visual C++ 2003 reportedly produces incorrect code for SSE/SSE2 when
Chris@19: compiling FFTW. This bug was reportedly fixed in VC++ 2005;
Chris@19: alternatively, you could switch to the Intel compiler. VC++ 6.0 also
Chris@19: reportedly produces incorrect code for the file
Chris@19: reodft11e-r2hc-odd.c unless optimizations are disabled for that file.
Chris@19:
Chris@19: gcc 2.95 on MacOS X miscompiles AltiVec code (fixed in
Chris@19: later versions). gcc 3.2.x miscompiles AltiVec permutations, but FFTW has a workaround.
Chris@19: gcc 4.0.1 on MacOS for Intel crashes when compiling FFTW; a workaround is to
Chris@19: compile one file without optimization: cd kernel; make CFLAGS=" " trig.lo.
Chris@19:
Chris@19: gcc 4.1.1 reportedly crashes when compiling FFTW for MIPS;
Chris@19: the workaround is to compile the file it crashes on
Chris@19: (t2_64.c) with a lower optimization level.
Chris@19:
Chris@19: gcc versions 4.1.2 to 4.2.0 for x86 reportedly miscompile
Chris@19: FFTW 3.1's test program, causing make check to crash (gcc bug #26528). The bug was reportedly fixed in
Chris@19: gcc version 4.2.1 and later. A workaround is to compile
Chris@19: libbench2/verify-lib.c without optimization.
Chris@19:
const.
Chris@19: make such as
Chris@19:
Chris@19: "./fftw.h", line 88: warning: const is a keyword in ANSI
Chris@19: C
Chris@19:
Chris@19: This is the case when the configure script reports that const does not work:
Chris@19:
Chris@19: checking for working const... (cached) no
Chris@19:
Chris@19: You should be aware that Solaris comes with two compilers, namely,
Chris@19: /opt/SUNWspro/SC4.2/bin/cc and /usr/ucb/cc. The latter compiler is non-ANSI. Indeed, it is a perverse shell script
Chris@19: that calls the real compiler in non-ANSI mode. In order
Chris@19: to compile FFTW, change your path so that the right
Chris@19: cc is used.
Chris@19:
Chris@19: To know whether your compiler is the right one, type
Chris@19: cc -V. If the compiler prints ``ucbcc'', as in
Chris@19:
Chris@19: ucbcc: WorkShop Compilers 4.2 30 Oct 1996 C
Chris@19: 4.2
Chris@19:
Chris@19: then the compiler is wrong. The right message is something like Chris@19: Chris@19:
Chris@19: cc: WorkShop Compilers 4.2 30 Oct 1996 C
Chris@19: 4.2
Chris@19:
--enable-3dnow and --enable-k7?
Chris@19: --enable-k7 enables 3DNow! instructions on K7 processors
Chris@19: (AMD Athlon and its variants). K7 support is provided by assembly
Chris@19: routines generated by a special purpose compiler.
Chris@19: As of fftw-3.2, --enable-k7 is no longer supported.
Chris@19:
Chris@19:
Chris@19: --enable-3dnow enables generic 3DNow! support using gcc builtin functions. This works on earlier AMD
Chris@19: processors, but it is not as fast as our special assembly routines.
Chris@19: As of fftw-3.1, --enable-3dnow is no longer supported.
Chris@19:
Chris@19:
configure script attempts to automatically guess which
Chris@19: version to use.
Chris@19:
Chris@19: The FFTW 3.1 configure script enables fma by default on PowerPC, Itanium, and PA-RISC, and disables it otherwise. You can
Chris@19: force one or the other by using the --enable-fma or --disable-fma flag for configure.
Chris@19:
Chris@19: Definitely use fma if you have a PowerPC-based system with
Chris@19: gcc (or IBM xlc). This includes all GNU/Linux systems for PowerPC and the older PowerPC-based MacOS systems. Also
Chris@19: use it on PA-RISC and Itanium with the HP/UX compiler.
Chris@19:
Chris@19:
Chris@19: Definitely do not use the fma version if you have an ia-32 processor Chris@19: (Intel, AMD, MacOS on Intel, etcetera). Chris@19: Chris@19:
Chris@19: For other architectures/compilers, the situation is not so clear. For
Chris@19: example, ia-64 has the fma instruction, but
Chris@19: gcc-3.2 appears not to exploit it correctly. Other compilers may do the right thing,
Chris@19: but we have not tried them. Please send us your feedback so that we
Chris@19: can update this FAQ entry.
Chris@19:
genfft, written in the Objective Caml dialect of ML. You do not need to know ML or to
Chris@19: have an Objective Caml compiler in order to use FFTW.
Chris@19:
Chris@19:
Chris@19: genfft is provided with the FFTW sources, which means that
Chris@19: you can play with the code generator if you want. In this case, you
Chris@19: need a working Objective Caml system. Objective Caml is available
Chris@19: from the Caml web page.
Chris@19:
Chris@19: By default, FFTW configures its Fortran interface to work with the
Chris@19: first compiler it finds, e.g. g77. To configure for a different, incompatible Fortran compiler
Chris@19: foobar, use ./configure F77=foobar when installing FFTW. (In the case of g77, however, FFTW 3.x also includes an extra set of
Chris@19: Fortran-callable routines with one less underscore at the end of
Chris@19: identifiers, which should cover most other Fortran compilers on Linux
Chris@19: at least.)
Chris@19:
<complex> template class is bit-compatible with FFTW's complex-number format
Chris@19: (see the FFTW manual for more details).
Chris@19:
Chris@19: configure --enable-float. On a non-Unix system: edit config.h to #define the symbol FFTW_SINGLE (for FFTW 3.x). In both cases, you must then
Chris@19: recompile FFTW. In FFTW 3, all FFTW identifiers will then begin with
Chris@19: fftwf_ instead of fftw_.
Chris@19: Chris@19: The fftw-3.1 release supports --enable-k7. This option only works on Chris@19: 32-bit x86 machines that implement 3DNow!, including the AMD Athlon Chris@19: and the AMD Opteron in 32-bit mode. --enable-k7 does not work on AMD Chris@19: Opteron in 64-bit mode. Use --enable-sse for x86-64 machines. Chris@19: Chris@19:
Chris@19: FFTW supports 3DNow! by means of assembly code generated by a Chris@19: special-purpose compiler. It is hard to produce assembly code that Chris@19: works in both 32-bit and 64-bit mode.
Chris@19:
Chris@19: Matteo Frigo and Steven G. Johnson / fftw@fftw.org Chris@19: - 04 March 2014 Chris@19: