Chris@42: Chris@42: Chris@42: Chris@42: FFTW FAQ - Section 2 Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42:

Chris@42: FFTW FAQ - Section 2
Chris@42: Installing FFTW Chris@42:

Chris@42: Chris@42:
Chris@42: Chris@42:

Chris@42: Question 2.1. Which systems does FFTW run Chris@42: on? Chris@42:

Chris@42: Chris@42: FFTW is written in ANSI C, and should work on any system with a decent Chris@42: 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, Chris@42: such as cycle counters and SIMD instructions, but this is optional. Chris@42: Chris@42:

Chris@42: Question 2.2. Does FFTW run on Windows? Chris@42:

Chris@42: Chris@42: Yes, many people have reported successfully using FFTW on Windows with Chris@42: various compilers. FFTW was not developed on Windows, but the source Chris@42: code is essentially straight ANSI C. See also the Chris@42: 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 Chris@42: jour?'. Chris@42:

Chris@42: Question 2.3. My compiler has trouble with Chris@42: FFTW. Chris@42:

Chris@42: Chris@42: Complain fiercely to the vendor of the compiler. Chris@42: Chris@42:

Chris@42: 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@42: xlc compiler for AIX, Intel's icc versions 5-7, and Sun WorkShop cc version 6. Chris@42:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chris@42: Question 2.4. FFTW does not compile on Solaris, complaining about Chris@42: const. Chris@42:

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

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

Chris@42: This is the case when the configure script reports that const does not work: Chris@42:

Chris@42: checking for working const... (cached) no Chris@42:

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

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

Chris@42: ucbcc: WorkShop Compilers 4.2 30 Oct 1996 C Chris@42: 4.2 Chris@42:

Chris@42: then the compiler is wrong. The right message is something like Chris@42: Chris@42:

Chris@42: cc: WorkShop Compilers 4.2 30 Oct 1996 C Chris@42: 4.2 Chris@42:

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

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

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

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

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

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

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

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

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

Chris@42: Question 2.7. Which language is FFTW written Chris@42: in? Chris@42:

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

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

Chris@42: Question 2.8. Can I call FFTW from Fortran? Chris@42:

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

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

Chris@42: Question 2.9. Can I call FFTW from C++? Chris@42:

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

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

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

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

Chris@42: Chris@42: 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 Chris@42: recompile FFTW. In FFTW 3, all FFTW identifiers will then begin with Chris@42: fftwf_ instead of fftw_. Chris@42:

Chris@42: Question 2.12. --enable-k7 does not work on Chris@42: x86-64 Chris@42:

Chris@42: Chris@42: Support for --enable-k7 was discontinued in fftw-3.2. Chris@42: Chris@42:

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

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

Chris@42: Next: Using FFTW.
Chris@42: Back: Introduction and General Information.
Chris@42: Return to contents.

Chris@42:

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

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