<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr"><div class="gmail_default" style>On Wed, Jan 2, 2013 at 1:50 PM, <span dir="ltr"><<a href="mailto:dag@cray.com" target="_blank" class="cremed">dag@cray.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">David Blaikie <<a href="mailto:dblaikie@gmail.com" class="cremed">dblaikie@gmail.com</a>> writes:<br>
<br>
>>> There's little effort to keep the GCC build warning clean,<br>
>><br>
>> Why? It seems like a pertty important compiler to support.<br>
><br>
> It has some silly warnings (at least in some versions) that we don't<br>
> want to workaround/suppress. Arguably we could have the build system<br>
> check version information & suppress certain known-bad warnings on<br>
> specific GCC versions.<br>
<br>
</div>That would be ideal, but honestly in my experience there are very few<br>
gcc warnings that should be ignored. Which ones do you think should be<br>
ignored?<br></blockquote><div><br></div><div style>The implementations of -Wuninitialized, -Wreturn-type, and a few other GCC warnings are extremely aggressive. They have high false positive rates with few benefits. We regularly keep -Wreturn-type working despite this (see all of the llvm_unreachable after switch statements), but the fix to silence GCC's -Wuninitialized false positives actively degrades the quality of the code -- it forces dead stores to variables. These dead stores are a waste and prevent tools like Valgrind from finding very real bugs in the logic which cause a variable to be left uninitialized.</div>
<div><br></div><div><br></div><div style>I'm a big fan of -Werror, but only when the warnings actually make sense. There are many older compilers (both Clang and GCC) which have false positives in their warnings which should *not* be fixed because the code is in fact correct. Even with the latest GCC, we would need to suppress some warnings due to a fundamentally different approach to when and where the warning is appropriate.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Honestly we need to cleanup the buildbot infrastructure in general.<br>
> That's a work in progress. David Dean's bringing up the new<br>
> phase-based build infrastructure & my hope is that we'll use the<br>
> transition to a separate buildmaster running that infrastructure as a<br>
> chance to hold a higher bar for builders/slaves and take some time to<br>
> really assess where/how we'll allocate our build resources, including<br>
> things like building with -Werror, C++11, etc.<br>
<br>
</div>What kind of higher bar? I'm interested in contributing resources for a<br>
build slave (particularly for -Werror) but I can't guarantee 100%<br>
uptime. What will be the requirements for a build slave?<br>
<div class="im"><br>
>> This is with 4.7.1, BTW.<br>
><br>
> & your -Werror build of Clang+LLVM is otherwise clean apart from that?<br>
<br>
</div>I'm not sure since I didn't build with -k. I patched the warning and<br>
now it's building. I'll commit the fix if everything works.<br>
<span class="HOEnZb"><font color="#888888"><br>
-David<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" class="cremed">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank" class="cremed">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div></div>