Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Soft Works <softworkz@hotmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] Patchwork FATE Errors
Date: Thu, 20 Jan 2022 22:59:08 +0000
Message-ID: <DM8P223MB036562B19C3417CDB4287BBFBA5A9@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <AM7PR03MB66609E2E3F9BF2425EE4530E8F5A9@AM7PR03MB6660.eurprd03.prod.outlook.com>



> -----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


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

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

  reply	other threads:[~2022-01-20 22:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-20 21:03 Soft Works
2022-01-20 21:22 ` Andreas Rheinhardt
2022-01-20 22:12   ` Soft Works
2022-01-20 22:37     ` Andreas Rheinhardt
2022-01-20 22:59       ` Soft Works [this message]
2022-01-21  1:31         ` Andreas Rheinhardt
2022-01-21  1:44           ` Soft Works
2022-01-21  4:24             ` Andriy Gelman
2022-01-21  4:52               ` Soft Works
2022-01-21  5:11                 ` Soft Works

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM8P223MB036562B19C3417CDB4287BBFBA5A9@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \
    --to=softworkz@hotmail.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git