Errors in single-precision BLAS (libatlas3gf-sse)

[Pauli Virtanen]

At least the single-precision complex arithmetic in libatlas3gf-sse 3.6.0-22ubuntu2 yields completely invalid results. A test program demonstrating the errors is attached.

This issue appears to be specific to the SSE version of Atlas.

Would it be possible to add some sanity checks to Ubuntu/Debian's Atlas build, so that this type of problems would be detected and hosed packages wouldn't make it into distribution? Atlas is an important component in many scientific applications, and bugs in the shipped version will affect many programs down the stream.

    ***

Example of output from the simple test program on this platform:

$ gfortran -o test test.f -lblas
$ ldd test
 linux-gate.so.1 => (0xffffe000)
 libblas.so.3gf => /usr/lib/sse/atlas/libblas.so.3gf (0xb7bc6000)
 libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb7b12000)
 libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7aec000)
 libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7add000)
 libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb797a000)
 /lib/ld-linux.so.2 (0xb7fb8000)
$ ./test # this uses libatlas3gf-sse 3.6.0-22ubuntu2
 failure
 - complex*8: ( 4.0000000 , 6.9998479 )
 - complex*16: ( -4.0000000000000000 , 12.000000000000000 )
$ LD_PRELOAD=/usr/lib/libblas.so.3.0 ./test # use refblas3 1.2-8ubuntu2
 success
$ LD_PRELOAD=/usr/lib/atlas/libblas.so.3gf ./test # use libatlas3gf-base 3.6.0-22ubuntu2
 success

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: libatlas3gf-sse 3.6.0-22ubuntu2
ProcEnviron:
 LC_COLLATE=C
 PATH=(custom, user)
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
SourcePackage: atlas
Uname: Linux 2.6.28-11-generic i686

[Eric Firing (efiring)]

I have confirmed the bug on my 9.04 rc system, upgraded yesterday from 8.10. I get the failure with Pauli's test program. I ran into the problem when I tried to build numpy from svn--it failed nosetests using complex variables in linalg. I routinely built from svn using 8.10, with no such problem. This is puzzling because it looks like the atlas library has not been recompiled since 2004.

I'm using libatlas3gf-sse2 package.

[Eric Firing (efiring)]

I installed the libatlas-test package, ran the tests, and found two that failed: xzl2blastst and xcl2blastst. Output is attached.

[Matthew Arnold (matthew-arnold-1)]

This also affects SSE2... I suppose I should also file a report there.

Essentially the same problems as above:
fails on the jaunty version, ok for intrepid
xzl2blastst & zcl2blastst fail
propagates all the way up to numpy/scipy

[Andrew Straw (astraw)]

This is still present me on a Karmic i386 sbuild. Steps to reproduce ("failure" will be printed):

sudo apt-get install gfortran libatlas-sse2-dev
wget http://launchpadlibrarian.net/25714126/test.f
gfortran -o test test.f -lblas
./test

[Scott Howard (showard314)]

similar upstream bug with xcl2blastst test libatlas-test (3.6.0-24) failure

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517826

[Pauli Virtanen (pauli-virtanen)]

This seems to be fixed in David C's PPA Atlas packages (the jaunty versions install also on karmic):

https://launchpad.net/~david-ar/+archive/ppa

[Andrew Straw (astraw)]

This is still a problem on lucid i386 with atlas 3.6.0-24ubuntu1.

[Sylvestre Ledru (sylvestre)]

FYI, this bug is fixed with Debian Experimental ATLAS packages.

[Morten Kjeldgaard (mok0)]

I am building atlas version 3.8.3-13 from exp. as we speak. However, the build takes so long, that I might as well make use of the time to comment while it's compiling.

libatlas3gf-base has a huge list of dependencies, which is probably why atlas 3.8.3 is still in experimental(?) It is a major step to upgrade this library so late in the Lucid cycle. That said, everyone would be _very_ pleased to see this bug closed!

I have discussed a bit with ScottK on IRC, and our approach so far is the following: we need to test packages that are run time depends and not build depends. If this goes well, we can move forward and test some of the build depends. If that goes well...

Sylvestre, is there anything more you can tell us?

[David Cournapeau (cournape)]

This is a major issue - if upgrading to experimental packages is not possible, the next best solution would be to remove the sse/sse2 packages from the repository. This is especially important for Lucid because it is a LTS.

[Keenan Pepper (keenanpepper)]

Why is this only medium importance? This makes octave, numpy, etc. totally unreliable for simple matrix operations. I thought I was going crazy because the octave "*" operator wasn't acting associatively.

[Pauli Virtanen (pauli-virtanen)]

Seems to be finally fixed in the 3.8.3-22ubuntu2 packages in Maverick.