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

2014-10-29 Thread Edmund Grimley Evans
> really_have_neon is probably inlined into fftwf_have_simd_neon, because The assembler code you quoted looks like the translation of X(have_simd_neon) with "bl 0xa9f84" being the call to really_have_neon(). -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debi

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

2014-10-29 Thread Gert Wollny
On Wed, 2014-10-29 at 18:36 +0100, Julian Taylor wrote: > the flags are only added to files which do the computations, the rest > of the program should not have this flag, this should include the file > that has the neon runtime check. Makes sense, but then adding an intrinsic should be okay. Reg

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

2014-10-29 Thread Julian Taylor
On 29.10.2014 13:06, Gert Wollny wrote: > > Regarding the use of intrinsics: AFAICS in configure.ac --with-neon > always sets HAVE_NEON as define and adds the flag -mfpu=neon. > the flags are only added to files which do the computations, the rest of the program should not have this flag, this

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

2014-10-29 Thread 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 ex

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

2014-10-28 Thread Julian Taylor
On 29.10.2014 00:18, Edmund Grimley Evans wrote: >> Though for Debian wouldn't it be enough to change the encoding to what >> we are using? >> possibly that could be automated by compiling a vand snipped and getting >> the code with objdump during configure time. > > That sounds as if it could be

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

2014-10-28 Thread Edmund Grimley Evans
> > Is this signal-handling approach the best way of detecting NEON? The > > following blog suggests using HWCAP, but I don't know if that would > > work with the freebsd kernels: > > looks like a better way to do it, freebsd doesn't matter for us as we > don't have a arm port of that. > I don't k

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

2014-10-28 Thread Julian Taylor
On 28.10.2014 18:13, Edmund Grimley Evans wrote: > Is this signal-handling approach the best way of detecting NEON? The > following blog suggests using HWCAP, but I don't know if that would > work with the freebsd kernels: looks like a better way to do it, freebsd doesn't matter for us as we don'

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

2014-10-28 Thread Edmund Grimley Evans
Source: fftw3 Version: 3.3.4-1.1 In simd-support/neon.c I found: static int really_have_neon(void) { void (*oldsig)(int); oldsig = signal(SIGILL, sighandler); if (setjmp(jb)) { signal(SIGILL, oldsig); return 0; } else { /* parano