Re: ATLAS on PIII

[R Clint Whaley <rwhaley@cs.utk.edu>]

Camm,

>Greetings!   FIrst off, the sgemm kernel is ready whenever you might
>need it.  I thought I'd wait for the next developer release to check
>that it actually gets installed, and to deal with any cleanup issues
>that may have been newly introduced.  If you want what I have now,
>please say so.

If it's ready, point me at it.  I am still debugging the user cleanup,
but have gotten it to the point it finishes an install, if you hold it's
hand warmly enough; having a kernel that I could test on my laptop would
be nice . . .

>Secondarily, atlas compilation is failing on a number of architectures
>supported by Debian.  The most common symptom is exhausting physical
>memory in the search process.  I'm trying to get a compilation now on
>the following machine:

Uh, dude, the error below is a compiler error:
> gcc: Internal compiler error: program cc1 got fatal signal 9

Out of memory in a user application does not cause a gcc internal compiler
error.  This looks like a worse version of the bug I reported to gcc 2 years
ago.  Back then, I unrolled the ma loop, and gcc would give the same error.
I reported it, was told to try the new gcc version three times (I report with
version A, hear no word back until version B is released, then told to try
version B, error still there, repeat), and I finally stopped unrolling the
loop so gcc wouldn't die (this error happened on x86, alpha, and sparcs).
I'm not surprised the PowerPC situation has gone down hill so it can't even
handle non-unrolled loops now . . .

The PowerPC gcc is full of bugs.  Last time I had access to a PowerMac G4,
throwing the -funroll-all-loops flag hung the machine (linux had to be hard
rebooted: even text console was frozen, and did not respond to keyboard).
Have you tried removing that flag?

>Similar, though not identical, things happen on ARM and m68k.  Sparc,
>alpha, and i386 are fine.

Do they also have gcc internal compiler errors?

Clint