[cross-posting to the GCC and LLVM lists] I've updated the code size results here: http://embed.cs.utah.edu/embarrassing/dec_09/ The changes for this run were: - delete a number of testcases that contained use of uninitialized local variables - turn off frame pointer emission for all compilers - ask all compilers to target x86 + SSE3 - ask all compilers to not emit stack protector code - run unix2dos on the .c files so people on Windows don't see all the lines running together Hopefully the results are more fair and useful now. Again, feedback is appreciated. Once people are happy with how these results are obtained, I'll plan on just re-running the scripts every few months so we can see how the compilers evolve. Also there are many possibilities for enhancement including adding new architectures, harvesting more and larger functions, and harvesting C++ code. Thanks, John Regehr
On 12/16/2009 03:21 AM, John Regehr wrote:> Hopefully the results are more fair and useful now. Again, feedback is > appreciated.I would also avoid testcases using volatile. Smaller code on these testcases is often a sign of miscompilation rather than optimization. For example, http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is miscompiled on GCC 3.4 and SunCC 5.10. Sorry for not noticing yesterday. Paolo
Hi Paolo,> I would also avoid testcases using volatile. Smaller code on these testcases > is often a sign of miscompilation rather than optimization. For example, > http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is > miscompiled on GCC 3.4 and SunCC 5.10.Yeah, there are definitely several examples where small code is generated by miscompilation, especially of volatiles. However I would prefer to leave these testcases in, unless there is a strong feeling that they are too distracting. They serve as poignant little reminders about how easy it is to get volatile wrong... John
On Dec 16, 2009, at 1:26 AM, Paolo Bonzini wrote:> On 12/16/2009 03:21 AM, John Regehr wrote: >> Hopefully the results are more fair and useful now. Again, feedback is >> appreciated. > > I would also avoid testcases using volatile. Smaller code on these > testcases is often a sign of miscompilation rather than optimization. > For example, > http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is > miscompiled on GCC 3.4 and SunCC 5.10. >Perhaps just leaving out those volatile tescases which are miscompiled on other platforms, since not every volatile testcase fails for all compilers. :-) -bw