4.3.1 test failures on alphaev56-dec-osf4.0g (Tru64)

[Torbjorn Granlund]

"Daniel Richard G." <skunk at iSKUNK.ORG> writes:

  * Configured with --host=none: I got a link error building t-bswap:
  
  ----8<----
  /usr/home/cport/tmp/bash ../libtool --mode=link cc -std1  -O   -o
  t-bswap  t-bswap.o libtests.la ../libgmp.la 
  cc -std1 -O -o t-bswap t-bswap.o  ./.libs/libtests.a
  /usr/home/cport/tmp/gmp-noasm/.libs/libgmp.a ../.libs/libgmp.a  
  ld:
  Unresolved:
  __gmpn_count_leading_zeros
  __gmpn_invert_limb
  gmake[4]: *** [t-bswap] Error 1
  gmake[4]: Leaving directory `/usr/home/cport/tmp/gmp-noasm/tests'
  gmake[3]: *** [check-am] Error 2
  gmake[3]: Leaving directory `/usr/home/cport/tmp/gmp-noasm/tests'
  gmake[2]: *** [check-recursive] Error 1
  gmake[2]: Leaving directory `/usr/home/cport/tmp/gmp-noasm/tests'
  gmake[1]: *** [check-recursive] Error 1
  gmake[1]: Leaving directory `/usr/home/cport/tmp/gmp-noasm'
  gmake: *** [check] Error 2
  ---->8----
  
And you didn't forget to start with a pristine build dir?

  * Configured with CFLAGS="-O0 -g2" and any combination of options:
    Everything builds, all tests pass.

I smell compiler bugs.

  (dbx) run
  signal Segmentation fault at   [__gmpn_invert_limb:73 ,0x12001d3ac]     
  Source not available
  (dbx) where
  >  0 __gmpn_invert_limb() ["tmp-invert_limb.s":73, 0x12001d3ac]
     1 __gmpn_divrem_2() ["tmp-divrem_2.s":115, 0x12001c6d4]
  (dbx)

If __gmpn_invert_limb segfaults, it either was called with a corrupt
stack, or with an unnormalized argument.  I am pretty confident the code
works, as it has been tested a lot.
  
  Thinking this could be a compiler error, I tried building GMP with GCC
  4.4.0 + CFLAGS="-O0 -g3 -pedantic -Wa,-arch,ev56 -mcpu=ev56" (the
  default flags, except for the first two). Exactly the same results as
  with cc(1).
  
"Exactly the same results" meaning that it worked just like cc without
optimisation, or "exactly the same results" meaning that it fails like
when  using -fast with cc?

  What else I should try?
  
If it is just cc -fast that fails, then just don't use -fast.  The
compiler vendors like -fast flags; my experience is that they should
more aptly me called -fast-but-faulty.  I don't know how it is with
OSF's compiler, but presumably they deliberatly do invalid
transformations under -fast for the sake of speed.

-- 
Torbjörn