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 15:51 UTC (Sat) by mlopezibanez (guest, #66088)
Parent article: Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

GCC doesn't say: "Aha- let's replace this broken code with an infinite loop"

It is more like: "k is in the range 0..15, so this test I just found for k<16 is redundant, so change it to always true." It doesn't know that the test is used for exiting the loop. Well, in this simple case it does, and it should warn with -Waggressive-loop-optimizations. In other cases, the optimization can be disabled with -fno-aggressive-loop-optimizations.


(Log in to post comments)

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 25, 2013 20:37 UTC (Mon) by xorbe (guest, #3165) [Link]

OTOH, the compiler should know:
#1 k starts as zero
#2 k is incremented every loop, which is its only assignment point.
#3 k is 16 when the loop stops.

Therefore, it also can't be an infinite loop.

> It doesn't know that the test is used for exiting the loop.

What nonsense is this. "k<16" is the exact test in the for loop! Anyways, glad to know the situation is better than the initial blog post.

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 25, 2013 21:09 UTC (Mon) by mansr (guest, #85328) [Link]

The problem is that the source code is self-contradicting when interpreted strictly. While your observation is correct, the source also implicitly (through the d[k] array access) promises that k < 16. When given conflicting information like this, the interpretation is unpredictable. That is (part of) what undefined behaviour means. Get over it.

Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

Posted Mar 26, 2013 0:57 UTC (Tue) by nix (subscriber, #2304) [Link]

The 'nonsense', btw, is that the optimization pass which is coming to conclusions about the conditional test does not care where that test is located: in particular, it doesn't know nor care that it might be bounding a for loop. Generality in optimizations is generally a good thing...


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