| |||||||||||||
Regehr: GCC 4.8 Breaks Broken SPEC 2006 BenchmarksRegehr: GCC 4.8 Breaks Broken SPEC 2006 BenchmarksPosted Mar 26, 2013 5:10 UTC (Tue) by dlang (✭ supporter ✭, #313)In reply to: Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks by iabervon Parent article: Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks
and the mistake in the chain of reasoning is the very first one where it assumes that the loop variable will never be out of range..
The rest of the optimizations make sense, but that first one is optimistic thinking on the part of the compiler writer.
(Log in to post comments)
Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks Posted Mar 26, 2013 8:39 UTC (Tue) by mlopezibanez (guest, #66088) [Link]
No, the assumption is how C programs work. It is in general impossible to tell if there is going to be an out-of-bounds access without checking every access. If you want code that checks that, then wrap every array access in the equivalent of vector.at() and let the compiler try to remove redundant checks.
Of course, GCC could do better at static analysis and warning about such cases, but that is a different problem from optimization, and GCC needs new developers that are interested in such things.
Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks Posted Mar 27, 2013 22:27 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> and the mistake in the chain of reasoning is the very first one where it assumes that the loop variable will never be out of range.
That's not the chain of reasoning. The reasoning is that if the loop variable is out of range, the program's behaviour is undefined, thus not testing the variable is just as valid as testing it or doing something else entirely.
|
|||||||||||||