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

[Daniel Richard G.]

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:
>
> And you didn't forget to start with a pristine build dir?

Positive. I just gave it another go, with the same result.

>   * 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.

I tried building GDB 6.8 in hopes of getting a better stack trace, but
it fails to compile on this system :( (Yet another bug to report...)

> 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.

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.

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?


--Daniel


-- 
NAME = Daniel Richard G.     _\|/_    Remember, skunks
MAIL = skunk at iSKUNK.ORG     (/o|o\) _- don't smell bad---
MAIL+= skunk at alum.MIT.EDU   < (^),>     it's the people who
WWW  = (not there yet!)      /   \      annoy us that do!