News for hackers. Stuff that matters.

A comment on Sometimes the bug isn't in your code, it's in the CPU. Parent comment

Re:Sometimes the bug isn't in your code, it's in the CPU by mansr on Monday March 05, 2012 @08:18PM (#3669229)
One way of actively looking for compiler bugs is using a tool like Csmith[1]. Another is to compile some known-difficult code (e.g. Libav[2]) with various combinations of (optimisation) flags until the test suite fails. Most of the bugs I've found were during routine testing of Libav.

While I don't consider missed optimisations bugs as such, they are easy to find. Simply compile some non-trivial function and look at the output. There's usually something that could be done better, especially if some exotic instruction can be used.

[1] http://embed.cs.utah.edu/csmith/ [2] http://libav.org/

[ Parent | on HN ]
Re:Sometimes the bug isn't in your code, it's in the CPU by haberman on Wednesday March 07, 2012 @12:09AM (#3674353)
> While I don't consider missed optimisations bugs as such, they are easy to find. Simply compile some non-trivial function and look at the output.

Perhaps you'll give me a little credit :) if I mention that I found missed optimization bugs in extremely trivial functions. One of them involved gcc generating several completely useless stores even at -O3: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194

[ Parent | on HN ]
Re:Sometimes the bug isn't in your code, it's in the CPU by mansr on Wednesday March 07, 2012 @07:02PM (#3677940)
That's not "missed optimisation," that's "generating ridiculous code."
[ Parent | on HN ]