https://bugs.kde.org/show_bug.cgi?id=506211
--- Comment #2 from Florian Krohm <[email protected]> --- 25b9956679 updates the iropt tester to run both with and without constant folding. For now only s390 is enabled because there are failures on the other supported architectures. Here are a few samples: ppc failures: *** Incorrect result for operator MullU32 ppc64be, ppc64le opnd 0: 00000001 opnd 1: fffffffe result fold: 00000000fffffffe result nofold: fffffffffffffffe result expected: 00000000fffffffe *** Incorrect result for operator DivU32E ppc64be, ppc64le, ppc32 opnd 0: 000000ff opnd 1: 00000002 result fold: 80000000 result nofold: 00000000 result expected: 80000000 *** Incorrect result for operator DivS32E ppc64be, ppc64le, ppc32 opnd 0: 00000001 opnd 1: 00000002 result fold: 80000000 result nofold: 00000000 result expected: 80000000 amd64 failures: *** Incorrect result for operator ClzNat64 opnd 0: 0000000000000000 result fold: 0000000000000040 result nofold: fffffffffffff870 result expected: 0000000000000040 *** Incorrect result for operator CtzNat64 opnd 0: 0000000000000000 result fold: 0000000000000040 result nofold: 00000000000173da result expected: 0000000000000040 This is understood. The reason is that ClzNat64 is implemented via the BSF insn which has undefined behaviour when the operand is zero. Clearly, this is wrong and needs to be fixed. See also https://bugs.kde.org/show_bug.cgi?id=507033 This error does not surface in normal valgrind operation because in IR generation there is scaffolding to handle a 0 operand. x86 failures: *** Incorrect result for operator ClzNat32 opnd 0: 00000000 result fold: 00000020 result nofold: 7e0a7c0f result expected: 00000020 *** Incorrect result for operator CtzNat32 opnd 0: 00000000 result fold: 00000020 result nofold: 81f58410 result expected: 00000020 See amd64 explanation. -- You are receiving this mail because: You are watching all bug changes.
