[FFmpeg-cvslog] r26033 - trunk/libavcodec/ac3enc.c

[Dave Yeo]

On 12/21/10 11:58 am, Justin Ruggles wrote:
> On 12/21/2010 02:39 PM, Justin Ruggles wrote:
>
>> On 12/20/2010 05:44 PM, Justin Ruggles wrote:
>>
>>> On 12/20/2010 05:33 PM, Ronald S. Bultje wrote:
>>>
>>>> Hi,
>>>>
>>>> On Mon, Dec 20, 2010 at 5:30 PM, Justin Ruggles
>>>> <justin.ruggles at gmail.com>  wrote:
>>>>> All of the configurations which failed after this revision are x86.
>>>>
>>>> Is it possible that one of the optimized functions on these platforms,
>>>> which isn't tested otherwise, is causing this? E.g. consider that
>>>> float-to-int routines require different float values depending on
>>>> optimization level...
>>>
>>> I tried all x86 versions of sad[0] (C, MMX, MMX2, SSE2) and they passed
>>> on my system, so I don't think there is anything fundamentally wrong
>>> with how ac3enc is using sad[0].
>>
>>
>> I was able to duplicate the test failures using OpenBSD 4.8 i386 in
>> VirtualBox.  Now I'm trying to see if I can track down the specific problem.
>
>
> results for different versions of sad[0]:
> C: ok
> MMX: fail
> MMX2: fail
> SSE2: ok
>
> The x86_32 BSD FATE systems all have 3DNow so they do not use the SSE2
> version.  Next step: try to figure out what is wrong with the MMX and
> MMX2 versions.
>

The OS/2 system was also running a K7 so 3DNow before dieing Saturday. 
Now it is a Celeron D
Dave