GCC 4.8 Breaks Broken SPEC 2006 Benchmarks (fixed)

It's disappointing that SPEC refuses to fix the code and is spreading disinformation like "it is at minimum arguable that the code fragment is compliant under the C89 standard". If the global 'int d[16]' is placed at the very end of a page (which the linker is allowed to do), that code compiled in the most naive possible way will SEGV.

As pointed out by the LWN crowd, the article author is mistaken, because the 4.8 release doesn't do this. <a href="http://lwn.net/Articles/544123/" rel="nofollow">http://lwn.net/Articles/544123/</a>

I'm not really a crack at micro-optimizing C code, so can anyone here explain to me why the given function was written in the form it was?<p>Why not something like this:<p><pre><code> int d[16]; int SATD (void) { int satd = 0, dd, k; for (k=0; k&#60;16; ++k) { dd = d[k]; satd += (dd &#60; 0 ? -dd : dd); } return satd; } </code></pre> Does this generate slower code?

Should SPEC pay for static analysis services like Coverity on the code that enters the benchmark?<p>Or does it take a law to make them fix bugs in the code they ship?

As pointed out in the comments the code is quite contrived to begin with, no surprise such mistakes go unnoticed.<p>As long as a warning is emitted when the compiler relies only such undefined behavior it is a good thing to optimize this heavily, there are not many other ways to get more performance from C/C++.