On Monday 28 September 2009, Matteo Frigo wrote:
> > Frank Hess wrote:
> > > This means if a user doesn't include fftw3.h first, before any
> > > possible inclusion of complex.h, then his code may be using a
> > > different ABI than that of the libfftw3.so provided by debian.
>
> This is false. [N843, 6.2.5 Types, verse 13]:
>
> Each complex type has the same representation and alignment
> requirements as an array type containing exactly two elements of
> the corresponding real type; the first element is equal to the real
> part, and the second element to the imaginary part, of the complex
> number.
>
> Note that we changed the complex number definition from fftw2 (struct
> { double re, im }) to fftw3 (double [2]) precisely to be compatible
> with the (at the time) upcoming c99 standard.I'm not trying to say the different types fftw uses for complex numbers have different alignment or representation. I'm saying you're violating the strict-aliasing rules, which state that a piece of memory cannot be accessed through pointers to different types, with the exception of pointers to char. See n1124, 6.5, paragraph 7 (also 6.2.7 which defines compatible types). Or, you can get tons of hits on google about strict aliasing problems. > > > Or, indeed, different translation units of the user's program may > > > be using different definitions of fftw_complex depending on > > > exactly when each translation unit included fftw3.h. This will at > > > the very least cause violations of the C strict aliasing rules > > > which can cause mysterious crashes when optimization is turned on > > > (unless gcc's -fno-strict-aliasing option is used). I have > > > personally seen these crashes, and the problems can also be > > > visible when using valgrind (I saw it cause various uninitialized > > > memory problems in my program which valgrind reported). > > If so, gcc is broken (but I'd still like to see a test program). > Since the standard clearly implies that one can treat a c99 complex > number as an array of two reals, e.g. by taking the address of the > real part as a double *, a conforming compiler cannot possibly treat > the two cases differently. I don't think g++ is broken, although I've certainly heard arguments that the strict-aliasing rules in the standard were a bad idea. The strict aliasing rules allow compilers to make optimizations that assume pointers to different types will not access the same memory. I'll try to produce a test program soon.
signature.asc
Description: This is a digitally signed message part.
