Bugzilla Bug 11384

please provide some more information as to why it is 'incorrect' 

Recently I assembled a PC with an MSI 645E Max-U motherboard and an
Intel 2.4 GHz CPU.  I bootstrapped Gentoo Linux from
"livecd-ut2003-i586-1.4.1" although I booted the system from an 1.3
version because with 1.4.1, the network card didn't work because of
APIC problems.  The bootstrap process was successful; I used
CFLAGS='-march=pentium4 -O3 -pipe" in make.conf.

However, numerical software, using g77, performed incorrectly on rare
occasions.  I installed gcc version 2.95.3, but the problem wasn't
solved.  I tracked it down to the libm library; linking the above
software with a version from a Slackware 8.1 distribution (also with
glibc version 2.2.5) made it yield correct results.

A separate `make' of glibc-2.2.5 failed, maybe because of missing patches.
A `make' of glibc-2.3.1 was successful, but the `make check' failed
at ' ./math/test-double.out' with Error 2.

Probably the compiler generated during the bootstrap isn't able to
produce a correct libm library.

did you try building glibc w/out 'march=pentium4' ? 
maybe instead using 'mcpu=i686' ? 

Yes, that is, without any CFLAGS; the 'make check' failed at another stage,
I would have to do that again to be able to report exactly which one.

What gcc version ?  3.2 is known to break some optimizations, so try to use
3.2.1 ?

I've downloaded gcc-3.2.1 and performed a 'make bootstrap' (so with a possibly
broken gcc 3.2) with default optimization settings and installed it in a local
directory. Using that compiler (by use of the CC variable), with the above
optimization flags (in CFLAGS), I built glibc-2.3.1, and the 'make check' failed
at another stage. It could be that another component, such as the assembler or
the linker is broken. I therefore downloaded binutils-2.13.1 and built them
using the above gcc-3.2.1, and built glibc using these (--with-binutils). Again,
the 'make check' failed, at the same stage. Well, the gcc and binutils were made
on a broken environment and could not recover as yet... (By the way, on the same
computer, using gcc-2.95.3, the 'make check' of glibc-2.2.5 (glibc-2.3.1 was too
new) was successful, so I doubt it has anything to do with the hardware.
The only solution now seems to be bootstrapping the whole system with the newer
compiler?

Where does it fail now ?

It failed at 'math/test-misc'. To be sure that what I said before was true,
I compiled gcc-3.2.1, binutils-2.13.1 on the same machine under the slackware
distribution, so starting with gcc-2.95.3.
'make check' of glibc-2.3.1 failed at the same stage! But without the
optimization options, the 'make check' passed! Of course, a problem with my
hardware can still not be excluded, and I don't know if the optimization options
I used cause problems on a different machine as well. Is the check performed
when emerge
builds glibc? It appears to be necessary.

I did many builds and 'make checks' of glibc-2.3.1,
using gcc-3.2.1 and binutils-2.13.1. Summary:

-march=pentium4 -O3  ->  FAILS
-march=pentium4 -O2  ->  FAILS
-march=pentium4 -O1  ->  FAILS

-march=pentium3 -O3  ->  PASSES
-mcpu=pentium4 -O3   ->  PASSES

-march=pentium4 -mfpmath=i387 -O3  ->  FAILS

When it fails, it is always in `test-misc'; the first failure
in the output file reads 'modf (4.29497e+09, ...) failed'

Sounds pretty much like what I suspected.  Thus is why the strip-flags()
command
in the ebuild.  3.2.1 fixes a lot of -march=pentium4 issues, but guess not all
of them :(

Yes indeed. But if strip-flags() was operational when I
bootstrapped gentoo (on Oct 25) how could I get an
improperly functioning libm?

It leaves -march, -mcpu, -O and -pipe.  But -march=pentium4 also broke xfree,
mozilla, etc among things, so I use -march=pentium3 on my P4 box.  We can
have a CFLAGS="${CFLAGS/pentium4/pentium3}" type of thing in glibc, but
problem is if you filter too much, you may miss if it is actually fixed in
gcc.

Thank you very much for your comments.
I guess the -march=pentium4 issues are known to the gcc team so that
I don't need to report this?
Would it be an idea to have a configuration option so that the ebuilds
do tests on generated packages when available?

I think it will help if you could report it.  To be honest, I have not looked
at the current open bugs at gcc.gnu.org.

If you file it, you can tell them at least that it is an unpatched version of
3.2.1.

This should rather be a CANTFIX, but oh well.  Hopefully gcc.gnu.org will
fix related problems, or maybe some dev will start doing gcc hacking :/

Anyhow, try gcc-3.2.1-r1, as it have some updates from cvs and Redhat patches.

*** Bug 14072 has been marked as a duplicate of this bug. ***