This post is making the rounds today: http://blog.regehr.org/archives/918
Actually SPEC 2006 is broken if you read the blog post correctly and GCC 4.8 just exposes it.
Thanks, Andrew
________________________________________ From: linaro-toolchain-bounces@lists.linaro.org [linaro-toolchain-bounces@lists.linaro.org] on behalf of Mans Rullgard [mans.rullgard@linaro.org] Sent: Saturday, March 23, 2013 7:33 AM To: linaro-toolchain@lists.linaro.org Subject: Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks
This post is making the rounds today: http://blog.regehr.org/archives/918
-- Mans Rullgard / mru
_______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 23 March 2013 18:08, Pinski, Andrew Andrew.Pinski@caviumnetworks.com wrote:
Actually SPEC 2006 is broken if you read the blog post correctly and GCC 4.8 just exposes it.
Yes, that might be why Mans' subject line applies the adjective 'broken' to 'SPEC 2006' :-) [also, for completeness: 4.8.0 actually does not break things, a patch making it avoid doing so was committed before release.]
The underlying point is a serious one, though -- the gcc tendency to "adversarial optimisation" may be useful for helping us meet our benchmark targets but it's not very pleasant to be the programmer on the other side of it, when today's working program silently breaks when compiled with tomorrow's gcc.
-- PMM
On 23 March 2013 18:51, Peter Maydell peter.maydell@linaro.org wrote:
On 23 March 2013 18:08, Pinski, Andrew Andrew.Pinski@caviumnetworks.com wrote:
Actually SPEC 2006 is broken if you read the blog post correctly and GCC 4.8 just exposes it.
Yes, that might be why Mans' subject line applies the adjective 'broken' to 'SPEC 2006' :-)
Those Regehr's words, although I do agree with the assessment.
[also, for completeness: 4.8.0 actually does not break things, a patch making it avoid doing so was committed before release.]
The underlying point is a serious one, though -- the gcc tendency to "adversarial optimisation" may be useful for helping us meet our benchmark targets but it's not very pleasant to be the programmer on the other side of it, when today's working program silently breaks when compiled with tomorrow's gcc.
The thing is, those of us who are careful when writing code actually want these optimisations. The more information the compiler can infer from the code, the better.
On 23 March 2013 18:58, Mans Rullgard mans.rullgard@linaro.org wrote:
The thing is, those of us who are careful when writing code actually want these optimisations. The more information the compiler can infer from the code, the better.
And those of us who don't write careful code want as many warnings as possible!! :D
cheers, --renato
On 23 March 2013 20:18, Renato Golin renato.golin@linaro.org wrote:
On 23 March 2013 18:58, Mans Rullgard mans.rullgard@linaro.org wrote:
The thing is, those of us who are careful when writing code actually want these optimisations. The more information the compiler can infer from the code, the better.
And those of us who don't write careful code want as many warnings as possible!! :D
foo.c:1: warning: statement may not have intended effect
On 23 March 2013 20:32, Mans Rullgard mans.rullgard@linaro.org wrote:
foo.c:1: warning: statement may not have intended effect
Or automatically open pages like these on the user's browser:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://lwn.net/Articles/250967/
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
And show one of these on the eog:
http://www.quickmeme.com/Batman-Slapping-Robin/
cheers, --renato
linaro-toolchain@lists.linaro.org
-
Mans Rullgard -
Peter Maydell -
Pinski, Andrew -
Renato Golin