5.1.2 assembler error on Solaris 10 with CC='cc -xtarget=opteron -xarch=amd64'
Daniel Richard G.
skunk at iSKUNK.ORG
Sat Oct 12 07:49:47 CEST 2013
On Thu, 2013 Oct 10 0:02+0200, Torbjorn Granlund wrote:
> Using the l/q forms of the instruction is redundant when using
> register operands. (For memory operands, the operation size needs to
> deduced from the mnemonic.)
> So "shr $17,%rax" = "shrq $17,%rax" and "shr $17,%eax" =
> "shrl $17,%eax".
Ah, now I see what the semantics are, thanks.
> I see that the C compiler is actually invoked as $(CCAS) when
> compiling assembly, and if one sets this at configure time, it will
> use that instead of $(CC). So I could specify CCAS=as. But CFLAGS
> et al. are passed in as arguments, and as(1) here does not like -O
> or -xO3.
> Good luck.
> I don't think we can reasonably do more from the GMP side.
I had a look through the build infrastructure, and IMO there's a bit
that can be done here. Have a look at the attached patch, against the
latest source snapshot. The changes I made are as follows:
* When CCAS is set in the configure script, similarly set CCASFLAGS, to
"$CFLAGS $CPPFLAGS" if not already set by the user.
* Use this new CCASFLAGS variable in the assembly tests instead of
* Changed CL_AS_NOEXECSTACK to modify and AC_SUBST CCASFLAGS, as
ASMFLAGS is basically the same variable (and CCASFLAGS is a better
name for it, being easier to associate with CCAS).
* Modified COMPILE_FLAGS to use CCASFLAGS rather than *CFLAGS/*CPPFLAGS,
and dropped ASMFLAGS. (COMPILE_FLAGS would probably better be named
With those changes, I can compile and test GMP successfully on this
Solaris system by configuring with
$ CC="cc -xarch=generic64" CCAS=as CCASFLAGS="-xarch=generic64" \
now that I can use as(1) to assemble the .s files without it
encountering any incompatible options in CFLAGS.
> The assembly problems are clearly due to a severely broken assembler
> which arbitrarily fails with some standard mnemonics.
fbe seems to be an assembler designed to work only with the output of
its associated compiler. /usr/ccs/bin/as appears to be the one to handle
> You still haven't told us what fails with the -m64 flag; we might be
> able to put that old compiler in 64-bit mode. Not sure how useful
> that'd be, though.
The problem with -m64 is that, on this older Sun compiler, it does
nothing. The compiler complains about it being an illegal option, but
otherwise continues without an error, generating 32-bit code per its
default. The configure error about mp_limb_t occurs because GMP is
expecting 64-bit code, but isn't getting it.
I have access to newer Solaris systems, and the cc(1) man page there
explicitly states that -m64 is the correct option to use, rather than
-xarch=blah64. -xarch=* is still recognized, but only "for compatibility
with previous releases."
This older Solaris system, however, only has -xarch=blah. The options
for blah include "amd64" and "generic64". -xarch=generic64 is probably
the closest equivalent of -m64.
Therefore: GMP should prefer -m64 over -xarch=blah, but it needs to
verify that -m64 is actually generating 64-bit code; if not, then
-xarch=generic64 should be used instead.
Daniel Richard G. || skunk at iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.
More information about the gmp-bugs