On 26/9/26 19:22, Pierrick Bouvier wrote:
On 9/25/26 7:35 PM, Richard Henderson wrote:
On 9/25/26 18:00, Pierrick Bouvier wrote:
Signed-off-by: Pierrick Bouvier<[email protected]>
---
tests/tcg/mipsel/float_convd.ref | 988 +++++++++++++++++++++++++++
++++
tests/tcg/mipsel/float_convs.ref | 748 +++++++++++++++++++++++
tests/tcg/mipsel/float_madds.ref | 768 ++++++++++++++++++++++++
3 files changed, 2504 insertions(+)
create mode 100644 tests/tcg/mipsel/float_convd.ref
create mode 100644 tests/tcg/mipsel/float_convs.ref
create mode 100644 tests/tcg/mipsel/float_madds.ref
What are you using to generate these?
I noticed that you did the same for other targets.
If the answer is qemu... that's bad.
This really really should be from proper hardware.
I concur. To test emulation fidelity, we need to compare with real
hardware output. In the absense of such valuable set, testing against
QEMU-generated output still extends coverage and assert we do not
regress. It shouldn't be problematic to re-generate when fixing issues.
This series (and previous .ref added) doesn't make our codebase worse.
Maybe we should add metadata to annotate dataset gathered from real
hardware and what is QEMU-generated.
Yes it's qemu. I understand the consequences of generating this with the
tool we are supposed to test, instead of real hardware.
My point of view is that if we can't get access to this hardware, having
a self-reference is better than nothing. It trades correctness for
stability, and allows to catch any change to review them.
In case this approach is proven to be wrong, and changes are too
distracting, I would be happy to remove them. It's easy to isolate
concerned tests in a specific list, and include them only if target has
the reference file. Just saying this to explain that it's not a decision
based on "it's hard to express in meson".
r~
