3 cxx tests fail on i386-pc-solaris2.8 ABI=32
dclarke at blastwave.org
Thu Jul 16 15:54:09 CEST 2009
> 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
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
> 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
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.
More information about the gmp-bugs