[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


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