[FFmpeg-devel] [PATCH] fate-valgrind.supp: Suppress uninitialized warnings for h264.
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Fri Feb 17 17:25:47 CET 2012
On Fri, Feb 17, 2012 at 05:06:46PM +0100, Reimar Döffinger wrote:
> On Fri, Feb 17, 2012 at 04:40:12PM +0100, Reimar Döffinger wrote:
> > On 17 Feb 2012, at 08:15, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > On Fri, Feb 17, 2012 at 07:20:33AM +0100, Reimar Döffinger wrote:
> > >> On 17 Feb 2012, at 05:11, Michael Niedermayer <michaelni at gmx.at> wrote:
> > >>> A prettier solution is welcome.
> > >>
> > >> The subject is wrong.
> > >
> > >> It will suppress all uninitialized data warnings for any decoder ouput.
> > >
> > > all uninitialized data warnings of all correct decoder output,
> > > fate does check that the output is correct. And that on all platforms
> >
> > It checks that it matches the reference. Particularly for H.264 (though admittedly only the time stamps are a real issue) I am not sure that is the same as being correct.
> >
> > >> IMO that is very close to making that valgind fate instance useless.
> > >
> > > what do you suggest on how to get rid of the warnings.
> >
> > Option 1) Fix the uninitialized data source
> > Option 2) Disable the affected tests for valgrind runs
> > Option 3) Add those suppressions only for the files with the issue
>
> Might be the quickest, smuggle a $TEST_VG_OPTS into the generated
> valgrind command-line and have those tests set that variable.
> (will still need some time/fiddling to get working I'm sure)
Option 5) find some better place for deblock_h_chroma_8_mmxext to
store m0 and m3 in x86_64 than _below_ the stack pointer.
That might be by decrementing the stack pointer or some
other registers...
More information about the ffmpeg-devel
mailing list