Re: [FFmpeg-devel] Patchwork FATE Errors

[Andreas Rheinhardt <andreas.rheinhardt@outlook.com>]

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.

- Andreas
_______________________________________________
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".