assembly files on Solaris SPARC can only be processed with gcc

Tue Aug 29 07:30:42 UTC 2017

Separating out the commands/echoes it looks like libtool first runs the compile with -KPIC -DPIC and going to ./libs, which succeeds.
Then it runs it again without those options, and that fails.

/usr/local/bin/bash ../libtool --mode=compile --tag=CC ../mpn/m4-ccas 
--m4="/usr/local/bin/m4" /opt/developerstudio12.5/bin/c99 -c 
-DHAVE_CONFIG_H -I. -I..  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo 
gcd_1 | sed 's/_$//'` -I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc  `test -f 'gcd_1.asm' || echo './'`gcd_1.asm

libtool: compile:  ../mpn/m4-ccas --m4=/usr/local/bin/m4 
/opt/developerstudio12.5/bin/c99 -c -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 
-I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc gcd_1.asm  -KPIC -DPIC -o .libs/gcd_1.o

/usr/local/bin/m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_gcd_1 
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DPIC 
gcd_1.asm >tmp-gcd_1.s

  /opt/developerstudio12.5/bin/c99 -c -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 
-I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc tmp-gcd_1.s -KPIC -DPIC -o .libs/gcd_1.o

libtool: compile:  ../mpn/m4-ccas --m4=/usr/local/bin/m4 
/opt/developerstudio12.5/bin/c99 -c -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 
-I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc gcd_1.asm -o gcd_1.o >/dev/null 2>&1

Dennis, if you run

../mpn/m4-ccas --m4=/usr/local/bin/m4 
/opt/developerstudio12.5/bin/c99 -c -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 
-I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc gcd_1.asm -o gcd_1.o

from the relevant directory, does that produce a more helpful diagnostic message?

-----Original Message-----
From: gmp-bugs [mailto:gmp-bugs-bounces at gmplib.org] On Behalf Of Dennis Clarke
Sent: Tuesday, August 29, 2017 12:00 AM
To: Niels Möller <nisse at lysator.liu.se>
Cc: gmp-bugs at gmplib.org
Subject: Re: assembly files on Solaris SPARC can only be processed with gcc

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

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

Dennis
_______________________________________________
gmp-bugs mailing list
gmp-bugs at gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs