Bug#767138: fftw3: runtime detection of NEON is perhaps broken

[Gert Wollny]

A few comments. 

I'm not sure if the disassembly is the right one. Supposedly it is in a
function called "fftwf_guru64_kosherp", but it should be in
"really_have_neon".

There I would expect that the actual disassembly results in the the
signal SIGILL not being reset and "return 1" always being executed. Then
the error pattern would make sense. I will check this tonight when I
have access to my ARM hardware.

Regarding the use of intrinsics: AFAICS in configure.ac --with-neon
always sets HAVE_NEON as define and adds the flag -mfpu=neon. 

In addition the gcc manpage says: 

"If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not generated
by GCC's auto-vectorization pass unless -funsafe-math-optimizations is
also specified."

With this in mind I would suggest the attached patch. 

Best 
Gert 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: correct_neon_test_on_armhf.patch
Type: text/x-patch
Size: 1143 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20141029/c1d4b92e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20141029/c1d4b92e/attachment.sig>