gmp-4.2.4 failures with Solaris 10 AMD64 and Studio Express 03/09

[Dennis Clarke]

>> Everything was going well until I ran make check.
>
> it seems to be a big-endian vs little-endian issue. Maybe the configure
> script
> was fooled by the combination Solaris - AMD64.

Why would that be a problem? Solaris has been 64-bit on AMD64 for years.

I just did a full re-compile again. No optimization and nothing fancy.
Same code segfaults and dumps core over and over.

$ ./tests/mpz/t-io_raw
check_in: result wrong
  i=1 zeros=0 neg=0
  got_ret  5
  want_ret 5
  got      =0x8100000000000000
  want     =0x81
Abort(coredump)
$ find . -type f | grep core
./tests/mpz/core.t-io_raw.isis_global_i86pc.16411:101.1238997336.20116
./tests/mpz/core.t-import.isis_global_i86pc.16411:101.1238997336.20136
./tests/mpz/core.t-export.isis_global_i86pc.16411:101.1238997337.20156
./core.t-io_raw.isis_global_i86pc.16411:101.1238997763.20239
$

I can generate core files on demand and I am thinking I should go back and
recompile such that I can single step into this until the fault occurs.
There must be a way to find the root cause here.

$ file ./tests/mpz/.libs/t-io_raw
./tests/mpz/.libs/t-io_raw: ELF 64-bit LSB executable AMD64 Version 1
[SSE2 SSE FXSR FPU], dynamically linked, not stripped
$ ldd ./tests/mpz/.libs/t-io_raw
        libgmp.so.3 =>  
/export/medusa/dclarke/build/libgmp/i386/CXX/gmp-4.2.4-build-amd64/.libs/libgmp.so.3
        libthread.so.1 =>        /lib/64/libthread.so.1
        libc.so.1 =>     /lib/64/libc.so.1
        libm.so.2 =>     /lib/64/libm.so.2

I have LD_LIBRARY_PATH set to find the correct libs.

$ dbx ./tests/mpz/.libs/t-io_raw
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.7' in your
.dbxrc
Reading t-io_raw
Reading ld.so.1
Reading libgmp.so.3.4.4
Reading libthread.so.1
Reading libc.so.1
(dbx) run
Running: t-io_raw
(process id 20265)
check_in: result wrong
  i=1 zeros=0 neg=0
  got_ret  5
  want_ret 5
  got      =0x8100000000000000
  want     =0x81
t at 1 (l at 1) signal ABRT (Abort) in __lwp_kill at 0xfffffd7fff27c94a
0xfffffd7fff27c94a: __lwp_kill+0x000a:  jae      __lwp_kill+0x18        [
0xfffffd7fff27c958, .+0xe ]
(dbx) where
current thread: t at 1
=>[1] __lwp_kill(0x1, 0x6, 0xffffffff89dde400, 0x3, 0x0, 0x0), at
0xfffffd7fff27c94a
  [2] _thr_kill(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff275223
  [3] raise(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff221c39
  [4] abort(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff2011c0
  [5] check_in(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x403b73
  [6] main(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x40462b
(dbx) quit
$

I'll try to focus on one test at a time and see if I cna single step into
this.

Dennis