[FFmpeg-devel] Patch: Inline asm fixes for Intel compiler on?Windows

[Reimar Döffinger]

On Mon, Dec 30, 2013 at 12:38:20AM +0100, Reimar Döffinger wrote:
> On Sat, Dec 28, 2013 at 03:04:43PM +0100, Michael Niedermayer wrote:
> > On Sat, Dec 28, 2013 at 01:34:26PM +0000, Carl Eugen Hoyos wrote:
> > > Michael Niedermayer <michaelni <at> gmx.at> writes:
> > > 
> > > > (testing with 2-3 old compilers from the 2.95 
> > > 
> > > I don't think 2.95.3 can be used to compile 
> > > unpatched FFmpeg git head.
> > 
> > ok, in that case some older gcc 3 versions should do
> > 
> > PS: iam interrested in the errors that gcc 2.95 generates when
> > building ffmpeg ?
> 
> It misses some C99 features mostly.
> 
> Empty macro arguments not supported (to be honest, I find use of that feature somewhat questionable):
> libavdevice/v4l2.c:132: macro `SET_WRAPPERS' used without args
> libavcodec/mss1.c:63: macro `ARITH_GET_BIT' used without args
> libavcodec/mss1.c:108: macro `ARITH_GET_MODEL_SYM' used without args
> libswresample/x86/swresample_x86.c:28: macro `PROTO4' used without args
> 
> Compound statement (surprisingly the only place where we use it?!):
> libavfilter/af_aresample.c:101: invalid use of non-lvalue array
> 
> More than 10 asm operands:
> libavcodec/x86/h264_i386.h: In function `decode_significance_x86':
> libavcodec/x86/h264_i386.h:113: more than 10 operands in `asm'
> libavcodec/x86/h264_i386.h: In function `decode_significance_8x8_x86':
> libavcodec/x86/h264_i386.h:198: more than 10 operands in `asm'
> libavcodec/x86/dsputil_x86.c: In function `ff_add_hfyu_median_prediction_cmov':
> libavcodec/x86/dsputil_x86.c:59: more than 10 operands in `asm'
> libavcodec/x86/mlpdsp.c: In function `mlp_filter_channel_x86':
> libavcodec/x86/mlpdsp.c:174: more than 10 operands in `asm'
> 
> Doesn't like ecx clobber (?):
> libavcodec/x86/cabac.h:205: Invalid `asm' statement:
> libavcodec/x86/cabac.h:205: fixed or forbidden register 2 (cx) was spilled for class GENERAL_REGS.
> 
> No native atomics and not compatible with my system's pthreads (?)
> libavutil/atomic.c:30: extra brace group at end of initializer
> libavutil/log.c:45: extra brace group at end of initializer
> 
> No va_copy:
> cmdutils.c:102: undefined reference to `va_copy'

It's called __va_copy, so easily fixable if desired. However there is no
point unless the macro issues were to be fixed I'd say.
That would then allow to test at least with asm disabled if anyone
desires.
Haiku might be one of the last platforms that have a somewhat maintained
gcc 2.95 setup if someone wanted to have it tested... (though even they
use a newer compiler for most things nowadays).