"Sean McGovern" <[email protected]> writes: > Hi folks, > > I wanted to summarize the current status of the Solaris Studio FATE > build as I know the output can sometimes be overwhelming, particularly > with V=1 set. I've been focussing more of my time recently on > assisting with gcc 4.7 on Solaris. > > The following errors in the build are the most immediately apparent: > > 1. libavcodec/h264_cabac.c: it seems to be puking on the > decode_significance* stuff in x86/h264_i386.h. It's currently > conditionally compiled with an #if ARCH_X86 && HAVE_7REGS && > !defined(BROKEN_RELOCATIONS), should it actually be ARCH_X86_32, or > should this work equally well on 64-bit?
It's fine on 64-bit with gcc. The ifdef is a leftover from when this code was randomly sprinkled in the main C code, not under x86/. Feel free to send a patch removing the ARCH_X86 part. > 2. libavcodec/motion_est.c: not too sure on this one yet -- the > compiler complains about "invalid instruction argument" in the > generated assembly, I'm thinking it may have some correlation to the > x86/mathops.h "impossible constraint" warnings peppered through the > build logs. Which of the mathops functions trigger this warning, and can you find the actual invalid assembly output? > 3. libavcodec/x86/h264dsp_mmx.c: It is not fond of the > h264_loop_filter_strength_iteration_mmx2() macro. A candidate for > YASM? Definitely yasm. > 5. libavutil/x86/cpu.c: I also submitted a patch for this -- it seems > suncc is not fond of our cpuid() macro. Is that on patchwork? -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
