[FFmpeg-cvslog] r20739 - in trunk/libavcodec: apedec.c dsputil.c dsputil.h ppc/int_altivec.c x86/dsputil_mmx.c x86/dsputil_yasm.asm

[Reimar Döffinger]

On Tue, Dec 08, 2009 at 09:32:28PM +0000, Loren Merritt wrote:
> On Mon, 7 Dec 2009, Ramiro Polla wrote:
> >On Sun, Dec 6, 2009 at 5:02 PM, Reimar D?ffinger wrote:
> >>
> >>In addition, gcc 4.2.4 MinGW and Cygwin ?builds seem to decode incorrectly:
> >>http://fate.multimedia.cx/index.php?build_record=144294
> >>
> >>Though consistently between them:
> >>http://fate.multimedia.cx/index.php?test_result=33060104
> >>http://fate.multimedia.cx/index.php?test_result=33055764
> >
> >Also reproducible on Ubuntu Linux 9.04 (gcc: Ubuntu 4.3.3-5ubuntu4,
> >yasm: 0.7.1.2093) compiling for 32-bit (--cc='ccache gcc -m32'
> >--arch=i686 --cpu=i686), forcing ff_scalarproduct_and_madd_int16_sse2
> >to be used on a q6600.
> 
> So when fate says "works on x86_32/Windows/MinGW/gcc-3.4.6, fails on
> x86_32/Windows/MinGW/gcc-4.2.4", that could be because those two
> tests where run on different computers with different simd
> capabilities and thus using different codepaths.

Hm. That's not good, I don't think tests running on different systems are
supposed to be grouped together, are they?
Maybe it's time to start switch to a more flexible FATE interface that allows
analyzing the structure of such failures better :-)

> It's good to test everything, but it can be misleading if I start
> the debugging process on the assumption that it's the type of bug
> that gets exposed by differing compiler versions.

Sorry, I had no idea they might be different PCs.