[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ATLAS on PIII
Greetings, and thanks for your quick reply!
R Clint Whaley <firstname.lastname@example.org> writes:
> >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?
> >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.
Camm Maguire email@example.com
"The earth is but one country, and mankind its citizens." -- Baha'u'llah