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

Michael Niedermayer michaelni
Mon May 30 18:40:28 CEST 2005


Hi

On Monday 30 May 2005 18:15, Michel Bardiaux wrote:
> Michael Niedermayer wrote:
> > 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)
>
> Should speed be an issue with --disable-opts?

no but the code would also be used without --disable-opts

[...]
-- 
Michael





More information about the ffmpeg-devel mailing list