cannam@127: cannam@127: cannam@127: cannam@127: FFTW FAQ - Section 2 cannam@127: cannam@127: cannam@127: cannam@127: cannam@127: cannam@127:

cannam@127: FFTW FAQ - Section 2
cannam@127: Installing FFTW cannam@127:

cannam@127: cannam@127:
cannam@127: cannam@127:

cannam@127: Question 2.1. Which systems does FFTW run cannam@127: on? cannam@127:

cannam@127: cannam@127: FFTW is written in ANSI C, and should work on any system with a decent cannam@127: C compiler. (See also Q2.2 `Does FFTW run on Windows?', Q2.3 `My compiler has trouble with FFTW.'.) FFTW can also take advantage of certain hardware-specific features, cannam@127: such as cycle counters and SIMD instructions, but this is optional. cannam@127: cannam@127:

cannam@127: Question 2.2. Does FFTW run on Windows? cannam@127:

cannam@127: cannam@127: Yes, many people have reported successfully using FFTW on Windows with cannam@127: various compilers. FFTW was not developed on Windows, but the source cannam@127: code is essentially straight ANSI C. See also the cannam@127: FFTW Windows installation notes, Q2.3 `My compiler has trouble with FFTW.', and Q3.18 `How do I call FFTW from the Microsoft language du cannam@127: jour?'. cannam@127:

cannam@127: Question 2.3. My compiler has trouble with cannam@127: FFTW. cannam@127:

cannam@127: cannam@127: Complain fiercely to the vendor of the compiler. cannam@127: cannam@127:

cannam@127: We have successfully used gcc 3.2.x on x86 and PPC, a recent Compaq C compiler for Alpha, version 6 of IBM's cannam@127: xlc compiler for AIX, Intel's icc versions 5-7, and Sun WorkShop cc version 6. cannam@127:

cannam@127: FFTW is likely to push compilers to their limits, however, and several cannam@127: compiler bugs have been exposed by FFTW. A partial list follows. cannam@127: cannam@127:

cannam@127: gcc 2.95.x for Solaris/SPARC produces incorrect code for cannam@127: the test program (workaround: recompile the cannam@127: libbench2 directory with -O2). cannam@127:

cannam@127: NetBSD/macppc 1.6 comes with a gcc version that also miscompiles the test program. (Please report a workaround if you know cannam@127: one.) cannam@127:

cannam@127: gcc 3.2.3 for ARM reportedly crashes during compilation. cannam@127: This bug is reportedly fixed in later versions of cannam@127: gcc. cannam@127:

cannam@127: 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. cannam@127: icc-7.1 compiler build 20030402Z appears to produce cannam@127: incorrect dependencies, causing the compilation to fail. cannam@127: icc-7.1 build 20030307Z appears to work fine. (Use cannam@127: icc -V to check which build you have.) As of 2003/04/18, cannam@127: build 20030402Z appears not to be available any longer on Intel's cannam@127: website, whereas the older build 20030307Z is available. cannam@127: cannam@127:

cannam@127: ranlib of GNU binutils 2.9.1 on Irix has been observed to corrupt the FFTW libraries, causing a link failure when cannam@127: FFTW is compiled. Since ranlib is completely superfluous on Irix, we suggest deleting it from your system and replacing it with cannam@127: a symbolic link to /bin/echo. cannam@127:

cannam@127: If support for SIMD instructions is enabled in FFTW, further compiler cannam@127: problems may appear: cannam@127:

cannam@127: gcc 3.4.[0123] for x86 produces incorrect SSE2 code for cannam@127: FFTW when -O2 (the best choice for FFTW) is used, causing cannam@127: 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 cannam@127: gcc 3.4.6. cannam@127:

cannam@127: gcc-3.2 for x86 produces incorrect SIMD code if cannam@127: -O3 is used. The same compiler produces incorrect SIMD cannam@127: code if no optimization is used, too. When using cannam@127: gcc-3.2, it is a good idea not to change the default cannam@127: CFLAGS selected by the configure script. cannam@127:

cannam@127: 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 cannam@127: when compiling SIMD code. In both cases, please upgrade to cannam@127: gcc-3.2 or later. cannam@127:

cannam@127: Intel's icc 6.0 misaligns SSE constants, but FFTW has a cannam@127: workaround. icc 8.x fails to compile FFTW 3.0.x because it cannam@127: falsely claims to be gcc; we believe this to be a bug in icc, but FFTW 3.1 has a workaround. cannam@127:

cannam@127: Visual C++ 2003 reportedly produces incorrect code for SSE/SSE2 when cannam@127: compiling FFTW. This bug was reportedly fixed in VC++ 2005; cannam@127: alternatively, you could switch to the Intel compiler. VC++ 6.0 also cannam@127: reportedly produces incorrect code for the file cannam@127: reodft11e-r2hc-odd.c unless optimizations are disabled for that file. cannam@127:

cannam@127: gcc 2.95 on MacOS X miscompiles AltiVec code (fixed in cannam@127: later versions). gcc 3.2.x miscompiles AltiVec permutations, but FFTW has a workaround. cannam@127: gcc 4.0.1 on MacOS for Intel crashes when compiling FFTW; a workaround is to cannam@127: compile one file without optimization: cd kernel; make CFLAGS=" " trig.lo. cannam@127:

cannam@127: gcc 4.1.1 reportedly crashes when compiling FFTW for MIPS; cannam@127: the workaround is to compile the file it crashes on cannam@127: (t2_64.c) with a lower optimization level. cannam@127:

cannam@127: gcc versions 4.1.2 to 4.2.0 for x86 reportedly miscompile cannam@127: FFTW 3.1's test program, causing make check to crash (gcc bug #26528). The bug was reportedly fixed in cannam@127: gcc version 4.2.1 and later. A workaround is to compile cannam@127: libbench2/verify-lib.c without optimization. cannam@127:

cannam@127: Question 2.4. FFTW does not compile on Solaris, complaining about cannam@127: const. cannam@127:

cannam@127: cannam@127: We know that at least on Solaris 2.5.x with Sun's compilers 4.2 you cannam@127: might get error messages from make such as cannam@127:

cannam@127: "./fftw.h", line 88: warning: const is a keyword in ANSI cannam@127: C cannam@127:

cannam@127: This is the case when the configure script reports that const does not work: cannam@127:

cannam@127: checking for working const... (cached) no cannam@127:

cannam@127: You should be aware that Solaris comes with two compilers, namely, cannam@127: /opt/SUNWspro/SC4.2/bin/cc and /usr/ucb/cc. The latter compiler is non-ANSI. Indeed, it is a perverse shell script cannam@127: that calls the real compiler in non-ANSI mode. In order cannam@127: to compile FFTW, change your path so that the right cannam@127: cc is used. cannam@127:

cannam@127: To know whether your compiler is the right one, type cannam@127: cc -V. If the compiler prints ``ucbcc'', as in cannam@127:

cannam@127: ucbcc: WorkShop Compilers 4.2 30 Oct 1996 C cannam@127: 4.2 cannam@127:

cannam@127: then the compiler is wrong. The right message is something like cannam@127: cannam@127:

cannam@127: cc: WorkShop Compilers 4.2 30 Oct 1996 C cannam@127: 4.2 cannam@127:

cannam@127: Question 2.5. What's the difference between cannam@127: --enable-3dnow and --enable-k7? cannam@127:

cannam@127: cannam@127: --enable-k7 enables 3DNow! instructions on K7 processors cannam@127: (AMD Athlon and its variants). K7 support is provided by assembly cannam@127: routines generated by a special purpose compiler. cannam@127: As of fftw-3.2, --enable-k7 is no longer supported. cannam@127: cannam@127:

cannam@127: --enable-3dnow enables generic 3DNow! support using gcc builtin functions. This works on earlier AMD cannam@127: processors, but it is not as fast as our special assembly routines. cannam@127: As of fftw-3.1, --enable-3dnow is no longer supported. cannam@127: cannam@127:

cannam@127: Question 2.6. What's the difference between the fma and the non-fma cannam@127: versions? cannam@127:

cannam@127: cannam@127: The fma version tries to exploit the fused multiply-add instructions cannam@127: implemented in many processors such as PowerPC, ia-64, and MIPS. The cannam@127: two FFTW packages are otherwise identical. In FFTW 3.1, the fma and cannam@127: non-fma versions were merged together into a single package, and the cannam@127: configure script attempts to automatically guess which cannam@127: version to use. cannam@127:

cannam@127: The FFTW 3.1 configure script enables fma by default on PowerPC, Itanium, and PA-RISC, and disables it otherwise. You can cannam@127: force one or the other by using the --enable-fma or --disable-fma flag for configure. cannam@127:

cannam@127: Definitely use fma if you have a PowerPC-based system with cannam@127: gcc (or IBM xlc). This includes all GNU/Linux systems for PowerPC and the older PowerPC-based MacOS systems. Also cannam@127: use it on PA-RISC and Itanium with the HP/UX compiler. cannam@127: cannam@127:

cannam@127: Definitely do not use the fma version if you have an ia-32 processor cannam@127: (Intel, AMD, MacOS on Intel, etcetera). cannam@127: cannam@127:

cannam@127: For other architectures/compilers, the situation is not so clear. For cannam@127: example, ia-64 has the fma instruction, but cannam@127: gcc-3.2 appears not to exploit it correctly. Other compilers may do the right thing, cannam@127: but we have not tried them. Please send us your feedback so that we cannam@127: can update this FAQ entry. cannam@127:

cannam@127: Question 2.7. Which language is FFTW written cannam@127: in? cannam@127:

cannam@127: cannam@127: FFTW is written in ANSI C. Most of the code, however, was cannam@127: automatically generated by a program called cannam@127: genfft, written in the Objective Caml dialect of ML. You do not need to know ML or to cannam@127: have an Objective Caml compiler in order to use FFTW. cannam@127: cannam@127:

cannam@127: genfft is provided with the FFTW sources, which means that cannam@127: you can play with the code generator if you want. In this case, you cannam@127: need a working Objective Caml system. Objective Caml is available cannam@127: from the Caml web page. cannam@127:

cannam@127: Question 2.8. Can I call FFTW from Fortran? cannam@127:

cannam@127: cannam@127: Yes, FFTW (versions 1.3 and higher) contains a Fortran-callable cannam@127: interface, documented in the FFTW manual. cannam@127: cannam@127:

cannam@127: By default, FFTW configures its Fortran interface to work with the cannam@127: first compiler it finds, e.g. g77. To configure for a different, incompatible Fortran compiler cannam@127: foobar, use ./configure F77=foobar when installing FFTW. (In the case of g77, however, FFTW 3.x also includes an extra set of cannam@127: Fortran-callable routines with one less underscore at the end of cannam@127: identifiers, which should cover most other Fortran compilers on Linux cannam@127: at least.) cannam@127:

cannam@127: Question 2.9. Can I call FFTW from C++? cannam@127:

cannam@127: cannam@127: Most definitely. FFTW should compile and/or link under any C++ cannam@127: compiler. Moreover, it is likely that the C++ cannam@127: <complex> template class is bit-compatible with FFTW's complex-number format cannam@127: (see the FFTW manual for more details). cannam@127: cannam@127:

cannam@127: Question 2.10. Why isn't FFTW written in cannam@127: Fortran/C++? cannam@127:

cannam@127: cannam@127: Because we don't like those languages, and neither approaches the cannam@127: portability of C. cannam@127:

cannam@127: Question 2.11. How do I compile FFTW to run in single cannam@127: precision? cannam@127:

cannam@127: cannam@127: On a Unix system: 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 cannam@127: recompile FFTW. In FFTW 3, all FFTW identifiers will then begin with cannam@127: fftwf_ instead of fftw_. cannam@127:

cannam@127: Question 2.12. --enable-k7 does not work on cannam@127: x86-64 cannam@127:

cannam@127: cannam@127: Support for --enable-k7 was discontinued in fftw-3.2. cannam@127: cannam@127:

cannam@127: The fftw-3.1 release supports --enable-k7. This option only works on cannam@127: 32-bit x86 machines that implement 3DNow!, including the AMD Athlon cannam@127: and the AMD Opteron in 32-bit mode. --enable-k7 does not work on AMD cannam@127: Opteron in 64-bit mode. Use --enable-sse for x86-64 machines. cannam@127: cannam@127:

cannam@127: FFTW supports 3DNow! by means of assembly code generated by a cannam@127: special-purpose compiler. It is hard to produce assembly code that cannam@127: works in both 32-bit and 64-bit mode.

cannam@127: Next: Using FFTW.
cannam@127: Back: Introduction and General Information.
cannam@127: Return to contents.

cannam@127:

cannam@127: Matteo Frigo and Steven G. Johnson / fftw@fftw.org cannam@127: - 30 July 2016 cannam@127:

cannam@127: Extracted from FFTW Frequently Asked Questions with Answers, cannam@127: Copyright © 2016 Matteo Frigo and Massachusetts Institute of Technology. cannam@127: