[FFmpeg-devel] Patchwork FATE Errors

Soft Works softworkz at hotmail.com
Fri Jan 21 00:59:08 EET 2022



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Andreas
> Rheinhardt
> Sent: Thursday, January 20, 2022 11:38 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] Patchwork FATE Errors
> 
> Soft Works:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Andreas
> >> Rheinhardt
> >> Sent: Thursday, January 20, 2022 10:22 PM
> >> To: ffmpeg-devel at ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] Patchwork FATE Errors
> >>
> >> Soft Works:
> >>>
> >>> andriy/make_fate_ppc
> >>>
> >>> => Does it possibly need 'make fate-rsync'?
> >>>
> >>
> >> No. The test does not rely on need samples;
> >
> > It was just a very quick guess, because yesterday I rebased and
> > saw the test matroska-dovi-write-config7 failing which was fixed
> > after fate-rsync - that's why I though it might be the same reason
> > (with make -jX, it's probably not deterministic, which test will
> > fail first).
> >
> >
> >> and the other test that uses
> >> this sample works fine. Some time ago, someone else wrote FATE tests for
> >> AVDOVIDecoderConfigurationRecord in Matroska
> >> (https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220101165153.440729-
> 6-
> >> tcChlisop0 at gmail.com/).
> >> These were faulty and one of them relied on a sample that has apparently
> >> never been uploaded (but this test is actually redundant with the other
> >> test), so I investigated and saw that the test (presumably
> >> unintentially) reencoded audio, so I switched it to a pure copy test and
> >> applied it, believing that codec-copy tests could not possibly for some
> >> arches. That was a mistake and I am deeply sorry for this mess.
> >
> > Nevermind - things happen..
> >
> >
> > BTW, I was thinking about submitting a patch for libavutil/tests/md5.c
> >
> > something like:
> >
> > #ifdef __GNUC__
> > #pragma GCC diagnostic ignored "-Wdiscarded-qualifiers"
> > #endif
> >
> > #ifdef __clang__
> > #pragma clang diagnostic ignored "-Wdiscarded-qualifiers"
> > #endif
> >
> > Would that make sense?
> > Those warnings are appearing in every single fate error output on
> patchwork,
> > possibly covering up more relevant things.
> >
> 
> Instead of pragmas one should limit the volatile to those compilers
> which miscompile the code without them.
> (IMO one does not need to find the exact set of compilers that
> miscompile this; all that matters is that recent versions don't give
> warnings and old versions don't miscompile. If some compilers of medium
> age still show this warning afterwards without needing the volatile, so
> be it.)

You mean like this?

#if defined(__clang__) && defined(__clang_major__) && __clang_major__ < 4
    volatile uint8_t in[1000]; // volatile to workaround http://llvm.org/bugs/show_bug.cgi?id=20849
#else
    uint8_t in[1000];
#endif


It was fixed in 3.5.1, so "medium age" would be 3.5.1 to 4.0.0

sw


More information about the ffmpeg-devel mailing list