5.1.2 assembler error on Solaris 10 with CC='cc -xtarget=opteron -xarch=amd64'

[Daniel Richard G.]

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
  "$CFLAGS $CPPFLAGS".

* 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
  ASSEMBLE_FLAGS.)


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" \
      ./configure

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
arbitrary assembly.

> 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


-- 
Daniel Richard G. || skunk at iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.