[FFmpeg-devel] [PATCH] fate-valgrind.supp: Suppress uninitialized warnings for h264.

[Michael Niedermayer]

On Fri, Feb 17, 2012 at 05:25:47PM +0100, Reimar Döffinger wrote:
> 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

theres not really a uninitialized data source


> > > Option 2) Disable the affected tests for valgrind runs

disabling valgrind for all h264 tests seems suboptimal


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

sounds like hacks that noone will maintain


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

if you find a way to do this without slowing the code down then thats
surely a solution

if that doesnt work out IMHO the patch i posted is still the best
solution.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120217/2080a77f/attachment.asc>