Illegal subtraction in tmp-dive_1.s

[Dennis Clarke]

> Dennis Clarke <dclarke at blastwave.org> writes:
>
>   Well, these lines scream endian issues :
>
>          want 0x12, 0x34, 0x56, 0x78,
>          got  0x78, 0x56, 0x34, 0x12,
>
>   And I am curious how a compiler can produce that sort of result.
>
> Surely a buggy compiler might cause that, but it might be a GMP bug too.
> I have no way of telling.

I cna now conffirm that if I use GCC 4.3.3 as well as ld/as etc from
recent binutils that the whole damn thing compiles fine and passes all
tests.

That really bugs me because every compiler, the commerrcial grade Studio
packages which are worth a ton of money, fail to build this code.

Do I trust GCC and then also trust the test results ?

Do I trust that the Sun Studio compilers are doing the "correct" thing in
accordance with specs and standards and thus GMP is at fault?

I can't tell.

I do know that if I set my CFLAGS thus :

CFLAGS=-march=i486 -mno-mmx -mno-sse -m32 -pthreads

everything works. every test passes.

If I try -march=pentiumpro then it compiles fine but fails :

make[4]: Entering directory
`/export/home/dclarke/gmp-4.3.0-pentium_pro/tests/mpn'
PASS: t-asmtype
PASS: t-aors_1
PASS: t-divrem_1
PASS: t-fat
PASS: t-get_d
PASS: t-instrument
PASS: t-iord_u
PASS: t-mp_bases
PASS: t-perfsqr
PASS: t-scan
FAIL: t-hgcd
PASS: t-matrix22
==================================
1 of 12 tests failed

> Note that GMP runs on both little-endian and big-endian machines.  And
> it does run on x86-solaris, so it does not seem like some GMP stupidity
> about assuming solaris means big endian.

I do have a full build on Sparc 32-bit and Sparc 64-bit but only the
libgmp tests run and none of the cxx tests can even be compiled. Again,
Studio 11 is at work here.

>   Regardless, I just tried to build things with Studio 11 on i386 and that
>   fails also :
>
>   Assembler:
>           "tmp-divrem_2.s", line 116 : Syntax error
>           Near line: "    or      %dl, %al"
>           "tmp-divrem_2.s", line 211 : Syntax error
>           Near line: "    or      %dl, %al"
>
> That surely looks like correct syntax to me.  Could the assembler have
> problems with adjacent instructions, but get the error message wrong?
> Please investigate, this should be straightforward to work around once
> we understand the problem.  (The insns around these insns are pretty
> standard, though.)

I have been digging into this all day. Really, it looks like it will be
all night as well. :-(

> I suspect you'd have a simpler life if you compiled using gcc instead of
> that pesky "Studio" compiler.  At least, GNU software likes gcc.

The next logical step after that would be to toss Solaris over my shoulder
and just say "use Linux" because it is a GNU thing ? Sorry, all my
production gear is running Solaris on every rev from Solaris 8 to snv_111.

That reminds me, I have yet to try this on snv_111. I'll give it a whirl
but really, the compilers ( and *maybe* the code ) are the issue.

Dennis