User: Password:
|
|
Subscribe / Log in / New account

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 23, 2013 16:16 UTC (Sat) by HelloWorld (guest, #56129)
In reply to: Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks by ssam
Parent article: Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

That is an academic distinction. The point is that gcc should give a warning when one uses a very unusual syntax like k < 16 to express 1, because chances are that wasn't the original intent.


(Log in to post comments)

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 23, 2013 16:38 UTC (Sat) by ssam (guest, #46587) [Link]

a 'expression always evaluates to true' or 'expression always evaluates to true' warning. It might be a pain for bits of code that you want the compiler to remove.

I sometimes use code like:

int a[] = {6,8,3};
...
for (int i=0; i<(sizeof(a)/sizeof(int)); i++){
done_stuff_with(a[i]);
}
...

maybe because i want to check if a particle in a simulation is in one of my regions of interest. I may often modify a, and then recompile the code (in my work its not unusual to recompile code before each run). Sometimes a will just be {}, so i would like the compiler remove the loop.

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 23, 2013 17:32 UTC (Sat) by apoelstra (subscriber, #75205) [Link]

> maybe because i want to check if a particle in a simulation is in one of my regions of interest. I may often modify a, and then recompile the code (in my work its not unusual to recompile code before each run). Sometimes a will just be {}, so i would like the compiler remove the loop.

I do this too, and I also compile with -Werror, but IMHO I'd rather have the warning than not. A simple (ugly) solution is to couch your loop in #ifdef's, and just flip a preprocessor variable.

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 26, 2013 5:31 UTC (Tue) by bronson (subscriber, #4806) [Link]

I think ifdefs would fall apart too quickly to be of much use.

Compiler warnings would too... If the compiler emits 22 "might be true" warnings, and 21 of them are spurious, what are the chances I'll catch the meaningful one? Knowing me, probably next to nil.

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 23, 2013 18:24 UTC (Sat) by smurf (subscriber, #17840) [Link]

>> The point is that gcc should give a warning when one uses a very
>> unusual syntax like k < 16 to express 1, because chances are that
>> wasn't the original intent.

The problem is that this kind of thing comes up in macros all the time, esp. in hand-optimized libraries. "(Foo < 8) ? _handcoded_special_function() : _generic_function()" is a common-enough idiom. You cannot just warn about that.

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 23, 2013 18:52 UTC (Sat) by mansr (guest, #85328) [Link]

A common strategy is to not warn for integer constant expressions used in conditions while warning if a condition involving a non-constant expression is provably invariant.

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 25, 2013 13:37 UTC (Mon) by dlthomas (guest, #89935) [Link]

Fortunately, GCC 4.8 also keeps track of what code is the result of expansion of what macros...


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds