Your message dated Fri, 30 Oct 2009 15:04:16 +0100
with message-id <[email protected]>
and subject line Re: Bug#534722:
has caused the Debian Bug report #534722,
regarding libfftw3-dev: aliasing violations due to complex.h inclusion
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
534722: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534722
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libfftw3-dev
Version: 3.1.2-3.1
Severity: important
FFTW3 has a mis-design feature where if complex.h is included before fftw3.h
(maybe indirectly and
unintentionally through another header) then the header changes the definition
of
the "fftw_complex" types (without doing any mangling to give them different
names).
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.
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).
As a workaround, Debian should alter the fftw3.h header so it does not define
fftw_complex based on header inclusion order, but always defines fftw_complex in
the same way it is defined when Debian compiles libfftw3.so.
-- System Information:
Debian Release: 5.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libfftw3-dev depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libfftw3-3 3.1.2-3.1 library for computing Fast Fourier
libfftw3-dev recommends no packages.
libfftw3-dev suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thank you Matteo and Steven for your explanations. I am closing this bug
now.
Best wishes, Paul
Steven G. Johnson wrote:
>> Whether or not such aliasing is safe is entirely dependent on
>> implementation-defined behavior, the standard leaves it undefined.
> This is not true. Matteo already quoted the portion of the C standard
> that specifically requires double complex and double[2] to have exactly
> the same binary representation.
> This thread is somewhat ironic because the binary equivalence between
> double[2] and double complex in C99 was designed *precisely* to allow
> safe type reinterpretations of the sort that FFTW does. The C++
> standard was subsequently amended to mandate exactly the same binary
> equivalence for complex<double>, again to allow safe typecasting of
> pointers to complex arrays in order to reinterpret them as arrays of
> double[2]. (And if I remember correctly, one of the examples used in
> the original rationale for this specification was FFT algorithms for
> real data, which need to re-interpret an array of real numbers as an
> array of complex numbers of half the length.)
>
> Regards,
> Steven G. Johnson
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkrq8l8ACgkQkuC958YALL09HQCgmCPufNVV+5nBZ5NDrTpKFMuS
TmUAn3uO+oTArAB+HC3S0QxzB22s0DBO
=tF9B
-----END PGP SIGNATURE-----
--- End Message ---
