Created attachment 7030 [details] gcc 4.6 failure 1 On a 32bit build I get a number of test suite failures in the math test suite 64bit is ok. This started sometime a few months ago (?) I can bisect when there is interest. They seem to be correlated with using older gcc. The failing systems have gcc 4.5 and gcc 4.6 (older Fedora). When I build with gcc 4.8 there are no failures. Interestingly the failures are not the same between 4.5 and 4.6 gcc 4.5.1 (FC14) fails test-double.out test-ifloat.out gcc 4.6.3 (FC16) fails test-float.out test-ifloat.out I'm attaching the test outputs.
Created attachment 7031 [details] gcc 4.6 failure 2
Created attachment 7032 [details] gcc 4.5 failure 1
Created attachment 7033 [details] gcc 4.5 failure 2
They are all 1, or 2 ulp at most in tgamma, cacos, or cacosh. It would be interesting to see when these 1 or 2 ulp failures started. I expect you'll find two patches, one effecting tgamma, the other related to complex sinusoidal. Joseph might know exactly what's going on though since he is the one making the most changes in this code. I've added Joseph to the CC.
My suspicion is that this relates to differences in when each compiler uses excess precision, given that it's only for 32-bit and only for float and double not long double. This does illustrate that when we regenerate the x86 / x86_64 ulps from scratch (which I think we should do at the start of the release freeze) it will be desirable to have not just people with different processors but also people with different GCC versions running the tests and adding ulps they see but other people don't.
I don't think this sort of bug is useful in Bugzilla. There's no indication of a glibc bug, and ulps updates to account for different compilers / hardware are best sent direct to libc-alpha (and can be committed as obvious unless the ulps are excessive or the functions are ones such as rint, sqrt and fma that should always be correctly rounded).