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

[Ramiro Polla]

On Wed, Dec 9, 2009 at 3:17 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Wed, Dec 09, 2009 at 12:11:46AM +0000, Loren Merritt wrote:
>> On Tue, 8 Dec 2009, Reimar D?ffinger wrote:
>> >On Tue, Dec 08, 2009 at 09:32:28PM +0000, Loren Merritt wrote:
>> >
>> >>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?
>>
>> Well, I'm just guessing. But if that's not the cause, then I'm even
>> more confused about why it sometimes worked.
>
> I didn't pay much attention, but maybe the different compilers used a different stack
> layout that avoided the issue?
> Maybe someone can clarify if the Mingw/Cygwin gcc 3.x and 4.x are the same and have
> the same configuration, but FATE sure claims that they are running on the same hardware.

They are running on the same VirtualBox. I tried reproducing with gcc
3.x and 4.x on another vbox but I've been stuck the past 2 days
debugging virtualbox and ubuntu bugs (I regret trying to update both
at the same time). I'll try again tomorrow after I get back home and
have local access to the fate vboxes again.