[LLVMdev] Build Failure

David Blaikie dblaikie at gmail.com
Thu Jan 3 11:09:40 PST 2013


On Thu, Jan 3, 2013 at 10:52 AM,  <dag at cray.com> wrote:
> David Blaikie <dblaikie at gmail.com> writes:
>
>> The other point Chandler was making, though, was that this sort of fix
>> means that other tools (Valgrind/MemSan) won't catch a broader class
>> of errors because we will have silenced them too.
>
> Does buildbot do a valgrind build with the same frequency as any other
> build?  If so, then either we should fix the warnings or we should
> disable them in the Makefile.
>
>> Except it isn't. We can ignore this warning & instead use
>> Valgrind-esque tools to catch not only these bugs, but catch & fix
>> them better by learning which specific codepath leads to the
>> uninitialized use, rather than just initializing a variable to zero
>> (or whatever) even in cases where that value was never intended to be
>> used in any computation.
>
> So what am I to do?  We build with -Werror.  I am really opposed to
> having to sift through hundreds of warning messages to pick out actual
> compiler errors.

Selfhost clang. Whenever we get a warning from Clang we either fix
Clang or fix the build quite quickly.

If you must use GCC to develop Clang you'll essentially be fighting
upstream - you'll commit code that produces Clang warnings & break
other people's builds and you'll receive code that other people have
committed that's Clang clean but produces GCC warnings.

If you want to fix the build such that LLVM can be built -Werror clean
with GCC the right solution is going to be to turn off -Wuninitialized
when the LLVM build system detects that it is using GCC rather than
Clang (we have the inverse, where we turn on certain Clang warning
flags when we detect that we're using Clang).

> How about initializing things to a garbage value and then doing an
> assert after all the following conditional initialization code runs to
> check for the garbage value?  Then even non-valgrind builds will catch
> the problem.

Complicates the code & isn't necessarily trivial/obvious in complex
cases (& there isn't always a convenient garbage value to use either).

Pragmas: maybe, but it would probably muddy the waters a fair bit.
Depends how noisy any given warning is - I suspect -Wuninitialized
wouldn't meet the bar for pragma suppressions (there would be too many
suppressions) & should just be disabled in the build system when using
GCC. We can rely on Clang's warnings to catch things that can be
caught reliably.

- David



More information about the llvm-dev mailing list