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

[Michael Niedermayer]

On Fri, Jan 09, 2009 at 03:35:52AM -0200, ramiro wrote:
> Michael Niedermayer wrote:
> > On Thu, Jan 08, 2009 at 07:40:18PM -0200, ramiro wrote:
> >> Michael Niedermayer wrote:
> >>> On Thu, Jan 08, 2009 at 09:34:06PM +0100, Vitor Sessak wrote:
> >>>> ramiro wrote:
> >>>>> Author: ramiro
> >>>>> Date: Thu Jan  8 00:36:34 2009
> >>>>> New Revision: 16488
> >>>>>
> >>>>> Log:
> >>>>> Use posix_memalign() if available.
> >>>> By looking at FATE, it looks like this change broke H264 decoding on gcc 
> >>>> 2.95.3. See for example 
> >>>> http://fate.multimedia.cx/index.php?test_result=6753660 .
> >>> as far as i understand it fate didnt build 3 revissions and this one
> >>> does not look like the most likely cause, 16490 looks more likely
> >> I couldn't get a hold of gcc 2.95 to test, but this patch should fix it.
> > 
> > i seriously doubt this patch will fix it. The problem IIRC was that
> > gcc 2.95 had some problem with alignment somewhere. gcc 2.95 should not
> > have any problem with sse as such.
> 
> I finally got gcc 2.95 working. This patch really changes nothing.
> 
> 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

also strictly the correct solution would be to leave HAVE_SSE enabled
as gcc 2.95 supports it and just disable functions where actual alignment
problems exists.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20090109/c8b36ddf/attachment.pgp>