[Ffmpeg-devel] [PATCH] fix x86 asm compilation

Michael Niedermayer michaelni
Mon May 30 17:22:22 CEST 2005


Hi

On Monday 30 May 2005 13:12, Aurelien Jacobs wrote:
> On Mon, 30 May 2005 09:57:48 +0200
>
> Michel Bardiaux <mbardiaux at peaktime.be> wrote:
> > Rich Felker wrote:
> > > On Mon, May 30, 2005 at 12:39:23AM +0200, Aurelien Jacobs wrote:
> > >>Hi,
> > >>
> > >>Currently i386/dsputil_mmx.c fails to compiles on x86 when
> > >
> > >configured >with --disable-opts. (At least for me with gcc 3.3.4)
> > >
> > >
> > > Why does this option to configure exist? It's known that disabling
> > > optimizations is not supported for asm...
> > >
> > >>I've written a small patch which fixes this. I don't like it very
> > >
> > >much, >but I've no better idea right now.
> > >
> > >
> > > If you insist on disabling optimizations (there is no good reason
> > > for this), then disable asm while you're at it too...
> >
> > There *is* one good reason to disable optimisations: when you need
> > debugging (which of course never happens with ffmpeg :-) ), gdb is
> > often  very confused by optimisations. Being unable to have asm and
> > no-opt  simultaneously makes debugging of code containing asm a real
> > PITA.
>
> That was exactly my purpose. I only used --disable-opts for debugging.
> I never use it for any other purpose.
> The fact is that --disable-opts used to work and was broken some times
> ago (it still works on amd64 thanks to it's 8 new general purpose
> registers).
> The transpose4x4 is the only asm code which breaks compilation with
> --disable-opts so I think it should really be fixed.

yes, please send a patch to gcc-devel or so, thats where the bug is and where 
it should be fixed
OTOH if you can workaround it in ffmpeg i wont complain either BUT it must be 
clean, working with gcc 2.95, 3.* & not slower then currently (post 
benchmarks)

[...]
-- 
Michael





More information about the ffmpeg-devel mailing list