https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #8 from Eyal <eyals...@gmail.com> --- Drawing up the truth table of those two versions of calculating a_min, I find that only the case when aa is unknown and vaa is 1 make any difference. The output in the version aa & ~vaa return 0 is aa==x and vaa==1. But for (aa&vaa)^aa, it gets unknown. Note that, if vaa is 1, the expression simplifies to (aa&1)^aa, which is just aa^aa, which is always 0 but the way that valgrind works, it can't recognize that the x on the left and the x on the right are the same x so its failing. We could not fix this without a major reworking of valgrind! I tried to reproduce this optimization by modifying the calculation in the code but it didn't make a difference. I suspect that the compiler is undoing the change as part of optimization. So I forced my computer to do it by changing this: value & ~vbits to: vbits_xor(vbits_and(value, vbits), value); and putting those files into separate compilations units, in files by themselves. This forces the code to run the instructions exactly as I specify. I definitely wouldn't suggest doing this long term but, for testing purposes, you can try it out. I have attached a patch that you can try. I've added new files so don't forget to run autogen.sh and configure again.) Now when I run this: make -j 20 check && valgrind -q --expensive-definedness-checks=yes memcheck/tests/vbit-test/vbit-test I get this every time: ==586817== Conditional jump or move depends on uninitialised value(s) ==586817== at 0x110D4E: check_result_for_binary (binary.c:372) ==586817== by 0x1126B7: test_binary_op (binary.c:683) ==586817== by 0x110374: main (main.c:192) ==586817== Either of the patches that I have attached solve the problem so I feel confident that this will fix Andreas' problem. I much prefer the 3 line solution to the other one so I will deprecate that other solution. -- You are receiving this mail because: You are watching all bug changes.
