You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}


2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}
(2) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2003 
_{Jan}

_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(2) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}
(2) 
2004 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2006 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}

2008 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}
(1) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2009 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: <whaley@cs...>  20090813 23:08:20

Guys, If ATLAS chooses an NB > 84, then it is possible for SGEMM and CGEMM to produce the wrong answer for M that are multiples of 14. If you use the architectural defaults on a 64bit AMD K10h, then you definitely have this error, and if you don't use arch defs on other x86 platforms you could potentially have it (if the search chooses NB > 84 and uses this cleanup routine). For details and the fix, see: http://mathatlas.sourceforge.net/errata.html#mu14nb120 Regards, Clint ************************************************************************** ** R. Clint Whaley, PhD ** Assist Prof, UTSA ** http://www.cs.utsa.edu/~whaley ** ************************************************************************** 
From: <whaley@cs...>  20090708 22:20:49

Guys, There's a bug in complex GEMM that can cause an unitialized memory read when c/z GEMM is called with large K and small M and N. The fix is described at: http://mathatlas.sourceforge.net/errata.html#JITB02 Cheers, Clint ************************************************************************** ** R. Clint Whaley, PhD ** Assist Prof, UTSA ** http://www.cs.utsa.edu/~whaley ** ************************************************************************** 
From: Clint Whaley <whaley@cs...>  20080606 20:12:30

There is a performance bug that causes a fairly large performance drop on all architectures. This bug is present in both ATLAS 3.8.0 and 3.8.1. The explanation and fix is available at: http://mathatlas.sourceforge.net/errata.html#JITcpBug Regards, Clint ************************************************************************** ** R. Clint Whaley, PhD ** Assist Prof, UTSA ** http://www.cs.utsa.edu/~whaley ** ************************************************************************** 
From: Clint Whaley <whaley@cs...>  20080523 20:08:00

An error has been found where ATLAS3.8.1 will occasionally read C even when BETA={0.0,0.0} in complex GEMM. Details, including the fix are available at http://mathatlas.sourceforge.net/errata.html#JITNaN Regards, Clint ************************************************************************** ** R. Clint Whaley, PhD ** Assist Prof, UTSA ** http://www.cs.utsa.edu/~whaley ** ************************************************************************** 
From: Clint Whaley <whaley@cs...>  20080115 12:59:43

I thought I had already sent a message about this, but the error archive doesn't show it. There have been two errors found in 3.8.0, and errata fixing them have been issued. The most important error is: http://mathatlas.sourceforge.net/errata.html#RMAAT This causes GEMM to compute the wrong answer for rowmajor C = alpha*A*A' or C = alpha*A'*A. The second error only effects configure on the PentiumM, which is misidentified as a CoreDuo. The errata and fix are at: http://mathatlas.sourceforge.net/errata.html#PMCD Regards, Clint ************************************************************************** ** R. Clint Whaley, PhD ** Assist Prof, UTSA ** http://www.cs.utsa.edu/~whaley ** ************************************************************************** 
From: Clint Whaley <whaley@cs...>  20061121 00:36:30

Guys, A user just discovered an error that effects all ATLAS releases at least as far back as 3.3. Essentially, complex GEMM (ZGEMM & DGEMM) can produce the wrong answer for the special case where B = transpose(A). Here's the errata entry describing the fix: http://mathatlas.sourceforge.net/errata.html#AAT Best regards, Clint 
From: <rwhaley@cs...>  20040417 20:05:24

Guys, The first serious error in 3.6.0 has been found. It affects only UltraSPARC systems. It should cause a problem on any UltraSPARC install, though I have so far reproduced it only when using the USIII/gcc defaults. It is a outof bounds read for some Kcleanup cases, specifically when K%NB == 8. It can cause a seg fault (but often won't, if your leading dimension > K). The fix is discussed: http://mathatlas.sourceforge.net/errata.html#USCU Regards, Clint 
From: <rwhaley@cs...>  20031223 15:45:11

Hi, The previously mentioned ATHLONSSE1 threaded bug is fixed in the newest ATLAS stable, 3.6.0, which has just been released. I include the 3.6.0 announcement below. Regards, Clint >From rwhaley@... Tue Dec 23 10:43:04 2003 XOriginalTo: rwhaley@... To: mathatlasannounce@... Subject: ATLAS 3.6.0 released Cc: rwhaley@... Date: Tue, 23 Dec 2003 10:43:02 0500 (EST) From: rwhaley@... (R Clint Whaley) XVirusScanned: by amavisdnew and ClamAV at cs.utk.edu XSpamStatus: No, hits=4.9 tagged_above=100.0 required=7.0 tests=BAYES_00 XSpamLevel: Hi, I am pleased to announce the release of ATLAS 3.6.0, the new ATLAS stable. http://mathatlas.sourceforge.net/ It's been two years since the last stable, so there have been a large number of changes. I will provide a few highlights here, and you can examine the ChangeLog for full details (the ChangeLog can be found on SourceFourge download page or in ATLAS/doc/ChangeLog). The first thing is, of course, speedups. ATLAS 3.6 is *much* faster than 3.4 for most common architectures. In particular, Opteron, Athlon64, Itanium 2, Pentium 4, Pentium 3, UltraSparc II/III are all signficantly faster in 3.6 than they were under 3.4. To give a flavor of this speedup, I have posted a few initial timings at: http://mathatlas.sourceforge.net/timing/ ATLAS also supports arch defaults for several new architectures. In addition to the machines mentioned above, ATLAS has defaults for IBM Power 4, and you can also build ATLAS using Intel's compiler on most Intel platforms. Another new feature in 3.6 is an improved SYRK/HERK implementation, with associated Cholesky speedup. Regards, Clint Whaley 
From: <rwhaley@cs...>  20031216 16:58:33

Pearu Peterson of scipy.org has reported and I have confirmed a bug that occurs intermittently on multiprocessor Athlons. The fix for now is to not use the threaded interface on Athlons. This is fixed in ATLAS 3.6, the new stable, which should be released before the new year. I will send mail on this list when it is available. Regards, Clint 
From: <rwhaley@cs...>  20031128 17:49:42

Ladies & Gentlemen, Pearu of the Scipy project (www.scopy.org) reported a bug in the rowmajor complex Cholesky code, and I have verified and issued an errata for it: http://mathatlas.sourceforge.net/errata.html#clltR This bug will affect all codes that depend on rowmajor complex cholesky (i.e. the problem could show up in the solve or inversion of rowmajor complex matrices). If you are not using rowmajor operations at all, you can safely ignore. If you use rowmajor operations, it is probably safest to apply the fix. If you are using the developer series, this error will be fixed in 3.5.13, which should be released this weekend (I'm waiting on some contributer code for the release). Regards, Clint 
From: R Clint Whaley <rwhaley@cs...>  20030728 15:53:57

When you make the change I sent out last week, you also need to make a similar change to slvtst. I have added this fix to the original errata entry: http://mathatlas.sourceforge.net/errata.html#rLLt Regards, Clint 
From: R Clint Whaley <rwhaley@cs...>  20030724 22:26:28

A user discovered an error in rowmajor complex cholesky, as shown: http://mathatlas.sourceforge.net/errata.html#rLLt While you are scoping this patch, you should scope the other ATLAS errors. There are one or two that are not bad enough to generate an atlaserror message, but that might be of interest (eg., an error when using solaris make on install, an error in the clapack.h include file, etc.): http://mathatlas.sourceforge.net/errata.html Regards, Clint FYI: I've also been posting ATLAS timings here: http://mathatlas.sourceforge.net/timing/ 
From: R Clint Whaley <rwhaley@cs...>  20030205 17:33:46

A very alert user has discovered a possible array bounds read in ATLAS's NRM2 implementation. Only systems that use the bad kernels will be effected. Details are given at: http://mathatlas.sourceforge.net/errata.html#NRM2 Regards, Clint 
From: R Clint Whaley <rwhaley@cs...>  20020618 17:34:35

There's an error in 3.4.1 CIAMAX that effects AltiVec systems only. Details at: http://mathatlas.sourceforge.net/errata.html#AVCIAMAX Cheers, Clint 
From: R Clint Whaley <rwhaley@cs...>  20020615 03:09:55

Real LU can get wrong answer for problems where M=2, N > 2, and both LU and LLt can return wrong error codes for singular matrices. Details and fix at: http://mathatlas.sourceforge.net/errata.html#LPIERR Cheers, Clint 
From: R Clint Whaley <rwhaley@cs...>  20020530 00:22:32

An alert user has pointed out several errors in 3.4.0, see the errata for details and fixes: http://mathatlas.sourceforge.net/errata.html Cheers, Clint 
From: <claude.lacoursiere@cm...>  20010926 17:30:49

Hi. I'm new to this list so please have some patience with the neophyte. I did read the errata file and built myself a patched version of ATLAS 3.2.1 with assorted lapack on my Linux box with ATLON 800 using 3DNow2 extensions: I'm happily using the resulting cblas library. I performed successful builds on an Octane and on a Linux/Celeron laptop. All that is good. However, I also need an NT, PIII SSE1 (512K L2 cache) version and that's causing trouble. I did use the architectural defaults provided in the stable ATLAS release and I did rename the default tarball file appropriately as described in the errata. The install job progressed smoothly for a long while but in the end, during the matrix vector tuning, the time produced NaN for the MFLOP count and !KABOOM!, I got the attached error report. Any clues would be appreciated. I think that there is little in the error report that is instructive except for the NaN MFLOP results. How did that happen? Is there a timer setting that might be wrong? Any help is appreciated. Thanks in advance! Regards, Claude.   Claude Lacoursière  Tel: +1.(514)2871166 Critical Mass Labs  Fax: +1.(514)2873360 (formerly MathEngine Canada Inc.)  Cel: +1.(514)5747409 420 rue NotreDame Ouest, Suite 505  http://www.cmlabs.com Montreal, Qc H2Y 1V3 CANADA  claude.lacoursiere@... 