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