Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks [LWN.net]

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 23, 2013 15:25 UTC (Sat) by proski (subscriber, #104)
In reply to: Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks by juzzor
Parent article: Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

It would be more interesting to know the description of the commit that changed the behavior. As others wrote, it would be nice if gcc emitted a warning ("comparison is always true") regardless of the code it generates.

(Log in to post comments)

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 23, 2013 15:46 UTC (Sat) by khim (subscriber, #9252) [Link]

It's easy to do, but you'll be surprised to see just how many such warnings typical code will generate. There are lots of idioms explicitly built around them (think "do { ... } while (TRUE)" defines and recall that TRUE is often is defined "(!FALSE)").

It's trivial to produce bazillion "comparison is always true" warnings or not produce anything at all. To produce meaningful number of warnings… that's different story… it's really hard.

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 23, 2013 17:54 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> It's easy to do, but you'll be surprised to see just how many such warnings typical code will generate. There are lots of idioms explicitly built around them (think "do { ... } while (TRUE)" defines and recall that TRUE is often is defined "(!FALSE)").
You could omit the warning whenever the expression to be tested is a constant-expression as defined by the C standard. The code to test for that is already there, so it should be trivial. In any case, it's time for the GCC developers to think about these issues, it's not the first time something like that comes up after all.

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 26, 2013 8:26 UTC (Tue) by mlopezibanez (guest, #66088) [Link]

The code that is always true might not have been even written by the user, but come from a system header file, a macro expansion (but not a constant expression), or generated code (very common in C++), from transformations of the code that don't match any original code, etc.

Regardless, there are very few GCC developers, so if you think you could do something better, you should give it a try. Sometimes you realize how difficult your obvious thing turns out to be, and other times you realize that it was indeed obvious but nobody had time to do it before. I can tell you from personal experience that there is a lot of the latter in GCC.

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 23, 2013 15:49 UTC (Sat) by juzzor (subscriber, #89840) [Link]

The fix is this commit by Jakub:

http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=228bf2b8...