On Tue, 16 Dec 2008 22:28:32 +1300 Simon Geard <[email protected]> wrote:
> > The short version is that the glibc guys believe a source repository > should always be in a releasable state, that checking in unproven code > is a no-no. Given that attitude, the most reliable set of code for a > given branch (2.8 in this case) should always be the most recent > snapshot from that branch, since it'll be as stable as any other, and > will have all the available bug fixes for that branch. > It's always a good idea, though, to run some independent tests. Since I do a lot of mathematics on my machine, I am particularly interested in floating point performance. Whenever I compile a new glibc (about every six months), I always use these two floating point tests: paranoia.c: http://www.netlib.org/paranoia/ UCBTEST: http://www.netlib.org/fp/ The paranoia C code still compiles on modern hardware and gives a thorough test. This program should produce no errors or deficiencies. Interestingly, when I first began using Linux in 1998, the paranoia test would indicate some FP deficiencies on an Intel processor with the versions of glibc at that time. The code has obviously gotten better and the latest glibc's all pass paranoia perfectly. For a much more exhaustive test, the UCBTEST should be performed. However, this code, as it is supplied, will not compile on newer systems. The problem is the use of obsolete floating point control routines in the place of the newer fsetcw(). Modifying the file ucbtest/ieee.c to replace the obsolete references will get the code to work. But there are also some other small changes needed as well. If anyone is interested, I can make a tarball of the modified UCBTEST code that compiles and runs well on my machine (an x86_64) and upload this tarball to my personal web page. It would just need to be untarred and executed. Frank Peters -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
