Optimized code generates valgrind errors

[brson]

We are accumulating a lot of valgrind suppressions because of this: http://llvm.org/bugs/show_bug.cgi?id=12319

[thestinger]

When Rust was zeroing everything (the stack segments and heap allocations), I think this check was always being masked so it was equivalent to having it disabled. I don't know the best way to deal with it, but I don't think disabling the class of error checking would be any worse than masking it with zeroing was.

[brson]

@echristo from LLVM mentioned on IRC that he was looking into this issue. Hopefully upstream will have some guidance for us.

Disabling the 'jump depends on on uninitialized value' error in valgrind would significantly reduce the value of that tool.

[brson]

I've pushed a commit that adds lots of suppressions. When this is resolved those should all be removed so they don't disguise errors.

[catamorphism]

Nominating for milestone 4, well-covered, since this affects our ability to use valgrind to its fullest extent.

[graydon]

Visiting for triage. I agree with the nomination. We should get this fixed someday!

[graydon]

accepted for well-covered milestone

[pnkfelix]

Need not block 1.0. Assigning P-low.

[huonw]

This is still a problem, e.g. just running valgrind rustc generates:

==32331== Conditional jump or move depends on uninitialised value(s)
==32331==    at 0x5AAFF0B: driver::monitor::h67fd9ec99e612659CVF (in /usr/local/lib/librustc-4e7c5e5c.so)
==32331==    by 0x5AAFADE: driver::main_args::h758a33c73a229584LQE (in /usr/local/lib/librustc-4e7c5e5c.so)
==32331==    by 0x5B34BA5: main::ha773b68016fefe22HVM (in /usr/local/lib/librustc-4e7c5e5c.so)
==32331==    by 0x4E77792: start::closure.8433 (in /usr/local/lib/libnative-4e7c5e5c.so)
==32331==    by 0x65B449B: rust_try_inner (in /usr/local/lib/librustrt-4e7c5e5c.so)
==32331==    by 0x65B4485: rust_try (in /usr/local/lib/librustrt-4e7c5e5c.so)
==32331==    by 0x6558D32: unwind::try::hea1640d217ab7457H7d (in /usr/local/lib/librustrt-4e7c5e5c.so)
==32331==    by 0x6558B0E: task::Task::run::hb52aad40b24ebf23Ndd (in /usr/local/lib/librustrt-4e7c5e5c.so)
==32331==    by 0x4E77609: start::h020d729b3953296bsoe (in /usr/local/lib/libnative-4e7c5e5c.so)
==32331==    by 0x4E77448: lang_start::hde2f1b6d366575e3Lne (in /usr/local/lib/libnative-4e7c5e5c.so)
==32331==    by 0x689CB44: (below main) (libc-start.c:287)

I vaguely recall that this was due to enums, e.g. something handling an Option<u32> might branch based on None vs. Some in such a way that the u32 field gets read unconditionally; that is, that memory is read even when uninitialised in a None, but is irrelevant to the semantics of the code in this case. However, I cannot create a small testcase.

[thestinger]

This isn't going to be fixed. It's a consequence of LLVM's optimized instruction scheduling and is entirely correct. They may provide a way to cripple the instruction scheduling to avoid this, but it wouldn't ever be a desired default for an optimized build. I don't think you'll find anyone interested in dealing with it because you might as well just flip on ASAN for Clang and GCC rather than -fno-valgrind-incompatible-optimizations.