llvm dev - Aug 2013 - [LLVMdev] Uninitialized variables -- LLVM bug?

Consider the following C code. When it is compiled using clang with '
-O', the assert fires. Gcc seems to do the opposite.

#include <assert.h>
int main()
{
    unsigned a;     // uninitialized!
    unsigned b = a;
    assert(b == a); // shouldn't this be always true?
    return 0;
}

Would you consider this a LLVM bug? I think GVN is responsible for this. I
don't know if it falls within the realm of "undefined" or
"implementation specific" behavior but there are probably examples of
code where one can "correctly" skip initialization. The Briggs-Torczon
sparse set data structure comes to mind (where you are not comparing two
uninitialized variables but an uninitialized variable with an initialized
variable-LLVM seems to do the right thing in that case, though).


n  Riyaz


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130816/634f1ba0/attachment.html>

On Fri, Aug 16, 2013 at 3:20 PM, Riyaz Puthiyapurayil <
Riyaz.Puthiyapurayil at synopsys.com> wrote:
>  Consider the following C code. When it is compiled using clang with ‘
> –O’, the assert fires. Gcc seems to do the opposite. ****
>
> ** **
>
> #include
> <assert.h>
> ****
>
> int main()
>                           ****
>
> {
> ****
>
>     unsigned a;     // uninitialized!                                 ****
>
>     unsigned b = a;
>
> ****
>
>     assert(b == a); // shouldn’t this be always
> true?
>
> ****
>
>     return
> 0;                                                                   ****
>
> }           ****
>
> ** **
>
> Would you consider this a LLVM bug? I think GVN is responsible for this. I
> don’t know if it falls within the realm of “undefined” or “implementation
> specific” behavior but there are probably examples of code where one can
> “correctly” skip initialization. The Briggs-Torczon sparse set data
> structure comes to mind (where you are not comparing two uninitialized
> variables but an uninitialized variable with an initialized variable—LLVM
> seems to do the right thing in that case, though).
>
Loading from an uninitialized variable is undefined behavior.  You might be
interested in Chris Lattner's series on undefined behavior at
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html .

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130816/5b05d894/attachment.html>