Running the following small test case under Valgrind memcheck on s390x yields "conditional jump or move depends on uninitialised value(s)" messages: #include <atomic> int main (void) { std::atomic_flag af = ATOMIC_FLAG_INIT; af.test_and_set(std::memory_order_acquire); } Valgrind complains about the compare-and-swap instruction CS, then again about the conditional branch that retries the CS if necessary. CS operates on an aligned word (4 bytes). It is emitted by the compiler here even though the atomic variable is only 1 byte in this case. Consequently 3 of the 4 bytes targeted by CS are uninitialized. However, the outcome of the CS does *not* depend on the uninitialized bytes, because they are just compared with copies of themselves. Thus these memcheck errors are false positives.
Yes. There's a special Iop_CasCmpEQ{32,64} or some such, designed specifically to deal with this problem. See libvex_ir.h for details.
(In reply to Julian Seward from comment #1) > Yes. There's a special Iop_CasCmpEQ{32,64} or some such, designed > specifically > to deal with this problem. See libvex_ir.h for details. Right I think that should help, thanks for the info. Assigning to myself.
Created attachment 133842 [details] Fix memcheck false positives with compare-and-swap (CS) Just as a preview, this is a first version of a fix. It only handles CS. A similar fix should be applied to other compare-and-swap variants such as CSG.
Created attachment 133881 [details] [v2] Fix memcheck false positives with compare-and-swap (CS) This version includes the changes from before and uses the `Iop_CasCmp...' operations in other compare-and-swap situations as well.
Pushed as 5adeafad7a60b63786d9545e6980de26c17cb0a6.