[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #12 from Paul

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #11 from John Reiser --- This comment is to confirm that the bug still exists today 2024-06-24, 7 years after original filing. Actually there are two bugs: 1) In the True branch after a test for Equality (==) then the Defined bits

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #10 from John Reiser --- (In reply to John Reiser from comment #8) > The underlying principle is that it can be useful to view "a bit is > initialized" as equivalent to "the cardinality of the set of possible values >

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #9 from John Reiser --- (In reply to John Reiser from comment #8) > The underlying principle is that it can be useful to view "a bit is > initialized" as equivalent to "the cardinality of the set of possible values >

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #8 from John Reiser --- (In reply to Julian Seward from comment #5) > What's the underlying insight > here? In particular, why is it the case that knowing the two operands are > equal allows us to mark the operands

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #7 from John Reiser --- (In reply to Julian Seward from comment #6) > In particular I am trying to figure out if this can somehow be used to avoid > the problems shown at > https://bugs.llvm.org//show_bug.cgi?id=12319

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #6 from Julian Seward --- In particular I am trying to figure out if this can somehow be used to avoid the problems shown at https://bugs.llvm.org//show_bug.cgi?id=12319 and https://github.com/rust-lang/rust/issues/11710

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #5 from Julian Seward --- (In reply to John Reiser from comment #4) Interesting, but I don't really understand it. What's the underlying insight here? In particular, why is it the case that knowing the two operands are

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #4 from John Reiser --- (In reply to John Reiser from comment #1) More generally, when memcheck complains about uninit in a test for equality between variables, then the Valid bits should "cross-pollinate": if (a ==

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #3 from John Reiser --- (In reply to Julian Seward from comment #2) > for (z=p; n; n--, z++) if (*z) *z=0; > > What is the point of this? Why not just assign zeroes unconditionally? > Is this some

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #2 from Julian Seward --- (In reply to John Reiser from comment #0) for (z=p; n; n--, z++) if (*z) *z=0; What is the point of this? Why not just assign zeroes unconditionally? Is this some game with the

[valgrind] [Bug 381326] recognize re-convergent fanout before complaining about Uninitialized

https://bugs.kde.org/show_bug.cgi?id=381326 --- Comment #1 from John Reiser --- Using reasoning that is similar to that the NOT_EQUAL operator (not_equal in any bit position that is initialized, implies not_equal in the whole word, regardless of uninit bits in other