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

[Michel Bardiaux]

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?

> 
> [...]


-- 
Michel Bardiaux
Peaktime Belgium S.A.  Bd. du Souverain, 191  B-1160 Bruxelles
Tel : +32 2 790.29.41