Here are my latest thoughts on what the run-time test for NEON should
probably look like.
Previous proposals used two static variables instead of just one, but
I think that would be less thread-safe.
The variable "cached" is used in only two places, so, provided the
access to it is atomic, the co
sorry for the lack of reply, I have been traveling for the last 1.5 weeks.
I'll try to look at this weekend. Feel free to NMU if you need a faster
solution.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.o
Control: severity -1 serious
Control: block 760271 by -1
Control: block 769974 by -1
Control: reopen 752514
Control: block 752514 by -1
Le mercredi 19 novembre 2014 à 12:15 -0800, Kamal Mostafa a écrit :
> I'm investigating an armhf FTBFS of my package 'minimodem'[0], which I
> now suspect might b
On Wed, Nov 19, 2014 at 08:37:15PM +, Edmund Grimley Evans wrote:
> Finding out which armhf machines have NEON is depressingly difficult,
> but I think that abel ("Marvell Armada 370/XP CPU @ 1.6GHz on a
> Marvell MV78460 SoC Development Board (ARM v7)") doesn't have NEON and
> the others do, s
Kamal Mostafa :
> Edmund et al., I would appreciate your expertise here... Does it also appear
> to
> you that my minimodem (0.20-1) failure[0] could be caused by the fftw3 "NEON
> is
> perhaps broken" bug? Does it make sense that abel.d.o would be affected by
> it, but harris and asachi would
I'm investigating an armhf FTBFS of my package 'minimodem'[0], which I now
suspect might be caused by this libfftw3 bug in unstable:
#767138 "fftw3: runtime detection of NEON is perhaps broken"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767138
There, Edmund points out that "#752514 ruby-ff
6 matches
Mail list logo
