[FFmpeg-devel] [PATCH] fate.sh: Allow overriding what targets to make for running the tests

[Rémi Denis-Courmont]

Le tiistaina 28. marraskuuta 2023, 16.21.55 EET Michael Niedermayer a écrit :
> On Tue, Nov 28, 2023 at 09:27:08AM +0200, Rémi Denis-Courmont wrote:
> > Le 28 novembre 2023 01:22:14 GMT+02:00, Michael Niedermayer 
<michael at niedermayer.cc> a écrit :
> > >On Mon, Nov 27, 2023 at 05:46:40PM +0200, Rémi Denis-Courmont wrote:
> > >[...]
> > >
> > >> Also FWIW, RV broke due to misaligned accesses and illegal vector types
> > >> that QEMU tolerated. That is rather an argument against QEMU than
> > >> against this MR but still.
> > >
> > >has someone reported this to qemu ?
> > >(seems like a bug)
> > 
> > It's not a bug. The specification leaves those cases *undefined*. QEMU
> > supports them because they can, and adding sanity checks would just slow
> > stuff down.
> > 
> > Also generally QEMU TCG policy seems to be maximize perf and
> > compatibility, not formal correctness.
> I think i read somewhere that recent qemu supposedly checks alignment on arm
> more completely. But i couldnt quickly find a official statement about that

As of 8.2.0-rc2, it most definitely does not:

----8<----
static inline void gen_check_sp_alignment(DisasContext *s)
{
    /* The AArch64 architecture mandates that (if enabled via PSTATE
     * or SCTLR bits) there is a check that SP is 16-aligned on every
     * SP-relative load or store (with an exception generated if it is not).
     * In line with general QEMU practice regarding misaligned accesses,
     * we omit these checks for the sake of guest program performance.
     * This function is provided as a hook so we can more easily add these
     * checks in future (possibly as a "favour catching guest program bugs
     * over speed" user selectable option).
     */ 
}                                  
---->8----

And this is an actual violation of the specification. In the RISC-V case, QEMU 
is not even violating the specification, just making a different choice than the 
only one currently commercially available hardware implementation.

> But either way, qemu could emit such code optionally when it is used for
> testing. Which is one of the things people use qemu for.

That would be very true for system mode "soft-MMU" QEMU, but much more 
questionable for user mode. In any case, I don't make their policies.

> So IMHO it would make sense for qemu to detect cases that are undefined
> even if for no other reason than to emulate the hw more exactly.

I would agree that optional flags would be sensible. But TBH, we don't even yet 
know how the IPs from other vendors than Alibaba/T-Head will behave.

> If this is not done, qemu can be detected and code could refuse or
> fail to run

-- 
レミ・デニ-クールモン
http://www.remlab.net/