[PlanetCCRMA] --enable-dynsimd=yes, amd duron, illegal instruction

[Fernando Lopez-Lezcano]

Hi all, I'm having a problem I don't understand with one of my Planet
CCRMA users. 

In short he's using a package I built with --enable-dymsimd=yes and
proper (I think) compile flags running on an AMD Duron cpu. This is an
example run:

> jackd -v -R -p128 -dalsa -r44100 -n2 -i2 -o2
> getting driver descriptor from /usr/lib/jack/jack_dummy.so
> getting driver descriptor from /usr/lib/jack/jack_freebob.so
> getting driver descriptor from /usr/lib/jack/jack_oss.so
> getting driver descriptor from /usr/lib/jack/jack_alsa.so
> jackd 0.103.0
> Copyright 2001-2005 Paul Davis and others.
> jackd comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
> 
> JACK compiled with System V SHM support.
> server `default' registered
> loading driver ..
> Enhanced3DNow! detected

It looks like jackd detects the cpu as supporting 3DNow....

> apparent rate = 44100
> creating alsa driver ... hw:0|hw:0|1024|2|44100|2|2|nomon|swmeter|-|
32bit
> control device hw:0
> registered builtin port type 32 bit float mono audio
> registered builtin port type 8 bit raw midi
> clock source = system clock via clock_gettime
> new client: alsa_pcm, id = 1 type 1 @ 0x805b1d0 fd = -1
> configuring for 44100Hz, period = 1024 frames, buffer = 2 periods
> ALSA: final selected sample format for capture: 16bit little-endian
> ALSA: use 2 periods for capture
> ALSA: final selected sample format for playback: 16bit little-endian
> ALSA: use 2 periods for playback
> Illegal instruction

But then when it tries to use it it bombs (or so I think). 

This is one "compile line" from the build log (to verify that the flags
are fine):

----
if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I. -I..    -I../config -I.. -I.. -D_REENTRANT
-D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -msse -msse2 -m3dnow -DJACK_LOCATION=
\"/usr/bin\" -I../config -I.. -I.. -D_REENTRANT
-D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -msse -msse2 -m3dnow -MT
libjack_la-client.lo -MD -MP -MF ".deps/libjack_la-client.Tpo" -c -o
libjack_la-client.lo `test -f 'client.c' || echo './'`client.c; \
----

"-march=i386" should ensure there are no extraneous instructions in the
regular code, -msse/-msse2/-m3dnow should include the compiler support
needed (build bombs otherwise), and of course in config.h:

/* Define to 1 to use dynamic SIMD selection. */
#define USE_DYNSIMD 1

I have looked at libjack/client.c and libjack/port.c and found nothing
obviously wrong (and regretfully there's no command line override switch
to turn off extra instruction support - hint hint...). 

Can it be that there are different levels of 3dnow and his cpu does not
meet the assumptions in the current jackd codebase? The package is built
from svn revision 1015. 

Thanks for any help!

-- Fernando