Toon Moene wrote: >>> Can somebody with access to SPEC sources confirm / deny and file a bug >>> report, if appropriate? >> >> It is an x87 bug only and has already been filed: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856 and working on >> being fixed already.
The reason that is was not found before - despite several people running SPEC's CPU benchmark - was exactly that they run it in 32bit mode. After they send me the options, Richard could immediately reproduce the problem. The patch is at: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01926.html > A x87 bug only exposed using SPEC ?!?!?!? Seemingly yes. To a certain extend this was by accident as "-msse3" was used, but it is on i586 only effective with -mfpmath=sse (that is not completely obvious). By the way, my tests using the Polyhedron benchmark show that for 32bit, x87 and SSE are similarly fast, depending a lot on the test case thus it does not slow down the benchmark too much. The author regretted that Atom support is not available in 4.4 - it will be in 4.5, but that's rather late given that the CPUs are around since some time. I agree with this. If I understood correctly, the 32bit mode was used since the 64bit mode needs more than the available 2GB memory. Similarly, the option -funroll-loops was avoided as they expect that unrolling badly interacts with the small cache Atom processors have. (That CPU2006 runs that long, does not make testing different options that easy.) > What are these guys thinking - like, lets cripple this benchmark and > use completely out of date floating point arithmetic ? > Duh, I hope the rest of their reporting is more useful ... Well, I think it will be just a short article announcing the new version. I think it is difficult to give a full account of a new compiler if the article needs to be in the next issue. And SPEC seemingly runs for 4 days with the additional problem that if a result is too much off, the run completely aborts (which makes the journalists avoid certain options). I would have liked that the options were reported. For instance -ffast-math was not used out of fear that it results in too imprecise results causing SPEC to abort. (Admittedly, I'm also careful with that option, though I assume that -ffast-math works for SPEC.) On the other hand, certain flags implies by -ffast-math are already applied with -O1 in some commercial compilers. David Korn wrote: > They accused us of a too-hasty release. My irony meter exploded! I think their accuse it right and wrong at the same time. Between the release candidate and the release there was indeed very little time. Thus 4.4.0 was released before he could report the bug which he found in RC1. -- And it is wrong since there was a very long Stage4. Whether one agrees, also depends on one's expectations. I think .0 releases are usually not as stable as people only start with .0 testing the release and that release candidates are also not much more tested than the Stage4 builds. (And in general, I believe .0 releases or - even most of the time the trunk - are quite well usable.) Tobias
