| Summary: | none/tests/s390x/dfp-1 failure | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Mark Wielaard <mark> |
| Component: | general | Assignee: | Andreas Arnez <arnez> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | arnez, mfranc |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
zero condition code before instruction test
Three-part patch series for fixing some issues in the dfp-1 and pfp test cases |
||
|
Description
Mark Wielaard
2023-08-01 12:50:13 UTC
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. |