assembly files on Solaris SPARC can only be processed with gcc
dclarke at blastwave.org
Mon Aug 28 22:00:08 UTC 2017
On 8/28/17 5:44 PM, Niels Möller wrote:
> Dennis Clarke <dclarke at blastwave.org> writes:
>> somedays I don't include details and I get railed at .. other days I
>> do and I get railed at .. life goes on.
I'm verbose. Social skills of the average gnat. I don't mean ada :-)
> Including details is nice and helpful, just don't expect everyone to
> digest all of the details at once. If I spot a single small problem in
> what you report, I might be able to provide some help on that, even if I
> don't have a good idea of the big picture.
I was just flabberghasted ( I think that is the word ) at how impossibly
horribly slow the results were that I was getting everywhere. Not just
on sparc but on powerpc and on amd64 systems. Those assembly bits are
>>> 2. GMP's Makefiles are not expected to try to do that; if they do on
>>> your platform, we'd need to figure out why.
>> sorry .. lost me there.
> I'll try to clarify. The Makefiles are expected to run roughly the two
> m4 ... foo.asm > foo.s
> $(CC) ... foo.s -o foo.o
> for each used .asm file. If you observe make trying to run
> $(CC) ... foo.asm -o foo.o
bingo .. I know that the expected file name should be a foo.s and I have
been writing assembly one way or another for thirty years. I just was
hoping that I didn't have too. Ever. However I thought, erronously, that
I had seen the compiler try to ingest a foo.asm file but perhaps that
was libtool doing its dance. No idea. The real truth is that those asm
files need a processing stage. That seems clear.
> instead, then you have found a severe Makefile-related problem. "can
> only be preprocessed with gcc" sounded like you expected the above
nope .. I was just looking at the whole process like a hand crank black
box problem. If I grab the handle marked "gcc" then I get a nice fast
result with a bucket of dependencies in there. If I grab the crank that
says c99 then I get really low dependency desperately slow results
because the crank box can't ingest the assembly files. Even worse is
that I really do need to hand build a decent gcc first and that is a
whole other kettle of fish.
> incorrect command to somehow succeed in case CC=gcc, and break only if
> gcc is replaced by Oracles compiler. But it's broken regardless of
> compiler; the separate m4 step is always required.
> Do you follow?
Yes Sir I do. Now I just need to ponder if the whole process is worth
the efforts that are going to be needed but when I see result times of
45 secs as opposed to 1 sec then something has to be done. Thankfully
the results all match across a few platforms. I have yet to write up any
tests that exercise memory or bother with pushing data around in
toroidal spatial coordinates but that may have to happen. Anyways ...
this is good progress and I have not really really looked carefully at
gmp in years. I think a look is needed. At least on sparc stuff.
More information about the gmp-bugs