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