On 9/29/2026 2:43 AM, Philippe Mathieu-Daudé wrote: > 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. >
It's possible. However, we have no guarantee that all the previous ref files were correctly generated from hardware also. >> 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~ >> >> >
