Since the upgrade from Fedora 36 to Fedora 38 the lfedora1 tester is seeing failures in none/tests/s390x/dfp-1 ================================================= ./valgrind-new/none/tests/s390x/dfp-1.stdout.diff ================================================= --- dfp-1.stdout.exp 2023-07-03 00:15:24.677944868 +0000 +++ dfp-1.stdout.out 2023-07-03 00:29:03.147950180 +0000 @@ -8,11 +8,11 @@ a230000000000194 - 222c000000000005 = a22c000000000cc5 cc = 1 2230000000000194 - 2230000000000194 = 2230000000000000 cc = 0 64-bit MULTIPLY -2230000000000194 * 2238000000000007 = 22300000000008de cc = 0 +2230000000000194 * 2238000000000007 = 22300000000008de cc = 2 a230000000000194 * 2238000000000007 = a2300000000008de cc = 0 a230000000000194 * 2238000000000000 = a230000000000000 cc = 0 64-bit DIVIDE -2238000000000022 / 2238000000000007 = 2dfcc2d74c2d74c3 cc = 0 +2238000000000022 / 2238000000000007 = 2dfcc2d74c2d74c3 cc = 2 a238000000000022 / 2238000000000007 = adfcc2d74c2d74c3 cc = 0 2238000000000000 / 2238000000000007 = 2238000000000000 cc = 0 128-bit ADD @@ -24,10 +24,10 @@ a20780000000000000000194 - 220740000000000000000005 = a20740000000000000000cc5 cc = 1 220780000000000000000194 - 220780000000000000000194 = 220780000000000000000000 cc = 0 128-bit MULTIPLY -220780000000000000000194 * 220800000000000000000007 = 2207800000000000000008de cc = 0 +220780000000000000000194 * 220800000000000000000007 = 2207800000000000000008de cc = 2 a20780000000000000000194 * 220800000000000000000007 = a207800000000000000008de cc = 0 220780000000000000000194 * 220800000000000000000000 = 220780000000000000000000 cc = 0 128-bit DIVIDE -220800000000000000000022 / 220800000000000000000007 = 2dffcc2d74c2d74c2d74c2d74c2d74c3 cc = 0 +220800000000000000000022 / 220800000000000000000007 = 2dffcc2d74c2d74c2d74c2d74c2d74c3 cc = 2 a20800000000000000000022 / 220800000000000000000007 = adffcc2d74c2d74c2d74c2d74c2d74c3 cc = 0 220800000000000000000000 / 220800000000000000000007 = 220800000000000000000000 cc = 0
This looks like an issue I noticed while working on Bug 465782: The decimal floating-point instructions for "multiply" and "divide" don't set the condition code, but the test case extracts and prints the condition code anyway without initializing it first. The result could have been random all the time, but has obviously been stable so far. This seems to have changed, probably due to changes in GCC. I've been working on lots of test case fixes anyhow, this one included. Let me sort through my patches, then I can probably come up with a fix soon.
Created attachment 160744 [details] zero condition code before instruction test I noticed this failure too when I was testing an unrelated patch. My stupid solution, since the test is expecting zeroes unless the tested instruction changes it, would be to simply prepend an instruction that zeroes condition code, such as comparing the register being used with itself, which should always yield zero cc. I just tried it and it seems to work. But, if you already have a fix or better idea, feel free to ignore it. $ perl tests/vg_regtest none/tests/s390x/dfp-1 dfp-1: valgrind ./dfp-1 == 1 test, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
(In reply to Miroslav Franc from comment #2) > Created attachment 160744 [details] > [...] > I just tried it and it seems to work. But, if you already have a fix or > better idea, feel free to ignore it. Your patch should be sufficient for solving this issue. Perhaps for Fedora this can be picked as-is. Upstream I'd like to fix other issues with the DFP test cases as well, which will require a much larger patch.
Created attachment 160801 [details] Three-part patch series for fixing some issues in the dfp-1 and pfp test cases This should fix the issue with the condition code, while also fixing a few other issues that require significant adjustments to the output files.
(In reply to Andreas Arnez from comment #3) > Your patch should be sufficient for solving this issue. Perhaps for Fedora > this can be picked as-is. I saw the failure on openSUSE Tumbleweed. > Upstream I'd like to fix other issues with the DFP > test cases as well, which will require a much larger patch. It's great to hear. :-)
(In reply to Andreas Arnez from comment #3) > Upstream I'd like to fix other issues with the DFP > test cases as well, which will require a much larger patch. I pushed a bunch of patches for the s390x DFP test cases, including a fix for this issue.