[LLVMdev] Build Failure

David Blaikie dblaikie at gmail.com
Thu Jan 3 09:17:55 PST 2013


On Thu, Jan 3, 2013 at 8:56 AM,  <dag at cray.com> wrote:
> Krzysztof Parzyszek <kparzysz at codeaurora.org> writes:
>
>>> I'm curious about this statement.  Can you give an example?  I've
>>> committed fixes to lots of -Wuninitialized warnings in my tree.  It's
>>> all just initializing local variables, which shouldn't result in extra
>>> stores.
>>
>> The logic of the program may be such that the actual store (not the
>> "pre-initialization") always happens before any uses, but the compiler
>> may be unable to prove it.  In such case, the added initialization
>> will extend the live range of the object and may result in a register
>> spill.
>
> If that's really the case, then the variable is declared much too early
> and the declaration should be moved.

Not necessarily. As was pointed out, a simple example of this is when
a variable is used only under one specific condition:

int x;
if (y) {
  x = ...
}
...
if (y) {
  func(x);
}

where the initial computation must preceed a large block of
unconditional code then be used after that under the same condition it
was computed.

If we initialize x to 0 because the warning tells us to (not because
we need to) then we'll not be able to find bugs where x is used
outside of if(y) when we use tools like Valgrind.

>
>> I believe that in the vast majority of cases this is not going to be a
>> problem, and the warning is shown because of the basic nature of the
>> front-end's analysis.
>
> It's a problem if we keep ignoring warnings and we miss real bugs
> because there are so many warning messages that things get lost.

The point is we can catch the bugs with other tools (Valgrind/MemSan)
& keep the compiler focused on bugs it can /reliably/ find without
interfering with other systems. We can do that by implementing all the
valuable warnings in Clang & ensuring we're Clang -Werror clean while
ignoring other compilers warnings that make bad choices about warning
quality.

> I have fixed several dozen warnings now.
>
>                            -David
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



More information about the llvm-dev mailing list