Re: [FFmpeg-devel] Patchwork FATE Errors

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Andreas
> Rheinhardt
> Sent: Friday, January 21, 2022 2:31 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Patchwork FATE Errors
> 
> Soft Works:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Andreas
> >> Rheinhardt
> >> Sent: Thursday, January 20, 2022 11:38 PM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] Patchwork FATE Errors
> >>
> >> Soft Works:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Andreas
> >>>> Rheinhardt
> >>>> Sent: Thursday, January 20, 2022 10:22 PM
> >>>> To: ffmpeg-devel@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@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
> >
> 
> I would not use an else branch, but only put the volatile and the
> comment in the #if branch.
> 
> >
> > It was fixed in 3.5.1, so "medium age" would be 3.5.1 to 4.0.0
> >
> 
> Fine by me if tested.

I do not have a Clang setup locally, I'd assume at least one of the 
Patchwork VMs uses Clang?

softworkz



_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".