[FFmpeg-cvslog] r16488 - in trunk: configure libavutil/mem.c

[Måns Rullgård]

Ramiro Polla <ramiro at lisha.ufsc.br> writes:

>   wrote:
>> ramiro <ramiro at lisha.ufsc.br> writes:
>> 
>>> Michael Niedermayer wrote:
>>>> On Fri, Jan 09, 2009 at 03:35:52AM -0200, ramiro wrote:
>>> [...]
>>>>> So, what could be done here?
>>>>> - check gcc version in configure and have sse depend on it
>>>>> or
>>>>> - #if defined(HAVE_SSE) && (!defined(__GNUC__) || __GNUC__ > 2)
>>>>> or
>>>>> - disable HAVE_SSE in some internal header based on __GNUC__
>>>>>
>>>>> I'm slightly more in favor of configure, because then we can keep
>>>>> HAVE_SSE as the only basis to disable building SSE code in the
>>>>> future. This patch only disabled selecting it at run-time. The
>>>>> functions are still being built.
>>>> fine though you need approval from the configure maintainers for this
>>> Patch attached.
>>>
>>> Ramiro Polla
>>> Index: configure
>>> ===================================================================
>>> --- configure	(revision 16512)
>>> +++ configure	(working copy)
>>> @@ -1744,6 +1744,14 @@
>>>      enabled ssse3 && check_asm ssse3 '"pabsw %xmm0, %xmm0"'
>>>      enabled mmx2  && check_asm mmx2  '"movss %xmm0, %xmm0"'
>>>  
>>> +    if enabled sse; then
>>> +        check_cpp <<EOF || die "This gcc version cannot compile SSE code properly, upgrade or use --disable-sse"
>>> +#if defined(__GNUC__) && __GNUC__ < 2
>>> +#error
>>> +#endif
>>> +EOF
>>> +    fi
>>> +
>> 
>> Rejected.  What is the purpose of that?  It's not even true.
>
> The purpose is that a plain ./configure with gcc 2.95 should work or at 
> least warn the user that he'll encounter problems with SSE code. It used 
> to be silently disabled in cpuid.c, now it'll be explicit.

The problem, as I've understood it, is not with SSE as such, but that
certain functions in libavcodec, which happen to use SSE, don't work
correctly when built with gcc 2.95.

Either way, checking the value of __GNUC__ in configure is just silly.
It can just as easily be done in the code.  Secondly, your check is
wrong in that it errors on gcc 1 (one), which I doubt anyone uses.

-- 
M?ns Rullg?rd
mans at mansr.com