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

[Torbjorn Granlund]

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

  On Tue, 2009 Aug  4 11:21+0200, Torbjorn Granlund wrote:
  > "Daniel Richard G." <skunk at iSKUNK.ORG> writes:
  >
  >   * Configured with --host=none: I got a link error building t-bswap:
  >    Unresolved:
  >    __gmpn_count_leading_zeros
  >    __gmpn_invert_limb
  >
  > And you didn't forget to start with a pristine build dir?
  
  Positive. I just gave it another go, with the same result.
  
Unfortunately, I cannot repproduce this (on alphaev6-unknown-linux-gnu),
and I also cannot pathom how the NO_ASM checks of longlong.h can fail in
your builds.  Please investigate!

Can other users of OSF reproduce this?

  >   * Configured with CFLAGS="-O0 -g2" and any combination of options:
  >     Everything builds, all tests pass.
  >
  > I smell compiler bugs.
  
  But with GCC 4.4?
  
  >   Thinking this could be a compiler error, I tried building GMP with
  >   GCC 4.4. + 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?
  
  GCC 4.4 + CFLAGS="-O0 -g3" + --disable-shared = test failures. The dbx
  session from t-tdiv looks exactly the same, too (aside from the
  pointer values). The same configuration, but without --disable-shared,
  works fine.
  
OK, so the static builds using cc and gcc 4.4 have problems.

  > 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.
  
  This is correct. From the cc(1) man page:
  
        Note that the -fast option can produce different results for
        floating-
        point arithmetic and math functions, although most programs are
        not sensitive to these differences.
  
This might be OK with GMP, even if one may disagree with the principle
of intensional miscompilation.

  I have to point out, however, that it is the GMP configure script itself
  that is adding -fast into the mix. Unless otherwise specified, I'm
  configuring with CFLAGS unset, and letting configure do what it wants.

  And here is yet another twist: If I configure with cc(1) +
  CFLAGS="-fast" (i.e. no "-arch ev56 -tune ev56"), all the tests pass.

Isn't it somewhat odd that a crash in assembly code just happens
under certain compiler options?
  
  My system has an EV5.6 21164A CPU, according to "psrinfo -v". According
  to the cc(1) man page, neither -arch nor -tune will generate code
  incompatible with earlier CPUs, although there are two different ways to
  work around that (instruction emulation vs. alternate codepath).
  
  I don't suppose you have access to a Tru64 system?

No longer.

I don't think more points on the envelope of this bug will enlighten me.
Somebody needs to debug a failing test on the host system.  With a
crash, this shouldn't be terribly difficult.

-- 
Torbjörn