

GCC 4.8 Breaks Broken SPEC 2006 Benchmarks (fixed) - neeee
http://lwn.net/Articles/544123/

======
jedbrown
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.

~~~
mnarayan01
Unless the C89 standard says something about VM interaction (I'm too lazy to
check), it seems like your complaint is misguided.

~~~
cygx
How so? The pointer pointing past the last member of an array may not be
dereferenced. Doing so is UB - end of story.

~~~
mnarayan01
As I said, I'm to lazy too delve into the C89 spec (and too young to have
actually programmed in the pre-VM days), but my (only slightly) educated guess
is that on the type of machine/OS C89 would have been targeted at, any
exceptions thrown by reading past the end of an array could be solved by
adding more memory; the same solution as would be required if the array was
increased in size.

------
kzrdude
As pointed out by the LWN crowd, the article author is mistaken, because the
4.8 release doesn't do this. <http://lwn.net/Articles/544123/>

------
ginko
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?

Why not something like this:

    
    
      int d[16];
     
      int SATD (void)
      {
        int satd = 0, dd, k;
        for (k=0; k<16; ++k) {
          dd = d[k];
          satd += (dd < 0 ? -dd : dd);
        }
        return satd;
      }
    

Does this generate slower code?

~~~
cygx
_Does this generate slower code?_

No, or at least not with an optimizing compiler. It was probably more about
writing compact code.

Personally, I'd have used abs() and gotten rid of the temporary variable dd
altogether:

    
    
        int SATD (void)
        {
            int satd = 0, k;
            for (k = 0; k < sizeof d / sizeof *d; ++k)
              satd += abs(d[k]);
    
            return satd;
        }

~~~
mansr
Good thinking. Most modern compilers will recognise abs() and generate
efficient code.

------
miga
Should SPEC pay for static analysis services like Coverity on the code that
enters the benchmark?

Or does it take a law to make them fix bugs in the code they ship?

------
mrich
As pointed out in the comments the code is quite contrived to begin with, no
surprise such mistakes go unnoticed.

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

