Re: ATLAS on PIII

[Camm Maguire <camm@enhanced.com>]

Greetings, and thanks for your quick reply!

R Clint Whaley <rwhaley@cs.utk.edu> writes:

> 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 . . .
> 

OK, let me put it together and post a url.

> >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

You could have a point here, but I think what is happening is that gcc
is taking up a *huge* amount of memory to compile this, and is getting
*killed* by the kernel (i.e. not an internal error per se, unless you
consider such memory usage an error, which I would :-)).  In other
words, when I do a 'dmesg' on a Linux box to see the kernel syslog
messages, I see

VM: killing process cc1
VM: killing process cc1


at the end.  Notice that the compiler received signal 9.


> 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 . . .
> 

Oh dear.  No doubt this immaturity of gcc on these archs is then most
likely to blame.  

> 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?
> 

Will try.

> >Similar, though not identical, things happen on ARM and m68k.  Sparc,
> >alpha, and i386 are fine.
> 
> Do they also have gcc internal compiler errors?
> 

Let me compile a list of these errors and report back more specifically.

> Clint
> 
> 


Thanks!


-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah