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

Dennis Clarke dclarke at blastwave.org
Thu Jul 16 17:11:00 CEST 2009


>   > I am afraid I cannot say for sure what the problem might be.
>
>   No one can it seems.
>
> No one except those that can reproduce the problem and then isolate it.

Right. That would be me.

> Please don't expect me to download Slowlaris, install it in a PC,

stop that.  Solaris is generally faster than Linux/Windows on the same
hardware for a given CPU intensive test. But let's not go there.

>   >  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.
>
> Eh, you misunderstood.  What does gcc -v and g++ -v output?  (Assuming
> you don't pass CC=some-other-gcc without CXX=the-same-g++.)

bash-4.0$ /opt/csw/gcc4/bin/gcc -v
Using built-in specs.
Target: i386-pc-solaris2.8
Configured with: ../gcc-4.3.3/configure --with-gnu-as --with-gnu-ld
--with-as=/opt/csw/gnu/bin/as --with-ld=/opt/csw/gnu/bin/ld
--with-cpu=i386 --enable-threads=posix --enable-nls --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --enable-shared --enable-multilib
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--with-system-zlib --with-gmp=/opt/csw --with-mpfr=/opt/csw
--enable-languages=c,c++,fortran,objc,ada --enable-bootstrap
Thread model: posix
gcc version 4.3.3 (GCC)
bash-4.0$ /opt/csw/gcc4/bin/g++ -v
Using built-in specs.
Target: i386-pc-solaris2.8
Configured with: ../gcc-4.3.3/configure --with-gnu-as --with-gnu-ld
--with-as=/opt/csw/gnu/bin/as --with-ld=/opt/csw/gnu/bin/ld
--with-cpu=i386 --enable-threads=posix --enable-nls --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --enable-shared --enable-multilib
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--with-system-zlib --with-gmp=/opt/csw --with-mpfr=/opt/csw
--enable-languages=c,c++,fortran,objc,ada --enable-bootstrap
Thread model: posix
gcc version 4.3.3 (GCC)

bash-4.0$ gas --version
GNU assembler (GNU Binutils) 2.19.1
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `i386-pc-solaris2.8'.

bash-4.0$ gld --version
GNU ld (GNU Binutils) 2.19.1
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

>   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.
>
> It seems unlikely that the eq rewrite casuses these three cxx failures,
> but as a professional software engineer, you could of course back out
> the eq.c change for now.

did that .. no change. So I put the change back in place.

>   > 3. Isolate the problem.
>
>   Right. That makes sense but the test harness is a bit obfuscated.
>
> Now, now.  When it says "FAIL foo ... Leaving directory bar", perhaps
> try "cd bar; ./foo".  It'll work, and it'll give you the failure
> slightly more verbosely.

Yep .. that is what I am doing this morning. Again, I have no docs on what
that test is doing or what to expect.

Of course .. I could just read the source.

>   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".
>
> The testsuite is documented as a bunch of files with the extension ".c".
>
> (I really doubt you need to understand anything about the test suite in
> order to isolate a failure.)

We shall see. This is going to be a long logn day. Expeect a LOT of
verbose traffic from me to the maillist today. I have this gut instinct
that any thing that can compile and pass all tests on a given ( very
common ) arch should be able to do the same thing on another ( very common
) arch.

No reason to think otherwise.


-
Dennis Clarke



More information about the gmp-bugs mailing list