3 cxx tests fail on i386-pc-solaris2.8 ABI=32

[Dennis Clarke]

> Dennis Clarke <dclarke at blastwave.org> writes:
>
>   All tests pass except for a few in the C++ section :
>
>   FAIL: t-assign
>   PASS: t-binary
>   PASS: t-cast
>   FAIL: t-constr
>   PASS: t-headers
>   PASS: t-istream
>   PASS: t-locale
>   PASS: t-misc
>   PASS: t-ops
>   PASS: t-ostream
>   PASS: t-prec
>   FAIL: t-rand
>   PASS: t-ternary
>   PASS: t-unary
>   ====================================
>   3 of 14 tests failed
>   Please report to gmp-bugs at gmplib.org
>   ====================================
>
> I am afraid I cannot say for sure what the problem might be.

No one can it seems. I found an entry in the maillist with the same test
failures on another platform and he had no responses to his maillist
posting. These things happen.

I have tried a few builds of gmp over and over with slightly different
configure options and with different CFLAGS and the same tests fail in
every case. I stick with GCC 4.3.3 now for this. Sun Studio will not do
the job and let's not go there right now :-)

> This type of isolated, platform/tools specific failures are very rarely
> GMP's fault.  In few instances, GMP can reasonably work around these
> type of problems.

I agree with that assessment. The exact same code tree builds fine on
Solaris Sparc and passes all tests in both 32-bit and 64-bit mode. So I
have to assume that the same code will compile on an x86 platform with the
same tool revisions. You know, GCC 4.3.3 and binutils as a minimum.

>  I can just give some general advice:
>
> 1. Make sure you're using the same version of gcc and g++ (and in
>    particular not gcc and a vendor C++ compiler, or vice versa.

Right, I was thinking the same thing. What changed here? That was my first
thought.

   mpf/eq.c  <-- this is new.

Not the same as what I used for my builds on Sparc.
I have a patch from you regarding that. Not really a patch. More like a
whole new file. Turns out, nothing other than the arch and that one source
file changed.

> 2. Try another compiler version.  (I have no particular prejudices
>    against gcc 4.3.3, which you say you're using, but I know gcc 4.3.2
>    was not able to correctly compile GMP 4.3.)

Yep .. that is also what I tried. I went with GCC 4.3.2 and watched it
fail with flair. That was late last night before giving up for the day. I
think that I will stick with GCC 4.3.3 because my testsuite results are
very clean  on x86 Solaris regarding GCC and I do trust it.

> 3. Isolate the problem.

Right. That makes sense but the test harness is a bit obfuscated. At the
very least it is not easy to get in there and just do these things myself
knowing what I am supposed to get. I don't have testsuite docs to refer to
that say "run test foo and see result output data bar".

>    Start by running the test stand-alone and see
>    what error message you get.  Then try to recompile things at the
>    lowest optimisation lever where the bug still happens, but add -g to
>    CFLAGS (i.e., do configure ABI=blahblah CFLAGS="-g -On ...").  First
>    and foremost avoid -fomit-frame-pointer, as it makes life hard for
>    debuggers.

I tried -g -Qy and I never use -fomit-frame-pointer.

In a fit of desperation as the coffee pot became more empty I am guilty of
trying this mess :

-march=i386 -m32 -mfpmath=387 -malign-double -mregparm=0
-mpreferred-stack-boundary=8 -mno-mmx -mno-sse

Same failures in the very same places.

>    Then, once you have a build with low optimisation and -g, fire up gdb
>    and follow the error backwards.  Good luck!

Luck, seems to be a factor here.

Dennis