On Sun, Mar 08, 2015 at 10:37:53PM +0100, Michael Niedermayer wrote: > On Sun, Mar 08, 2015 at 09:59:21PM +0100, Reimar Döffinger wrote: > > On Sun, Mar 08, 2015 at 08:44:50PM +0100, Michael Niedermayer wrote: > > > On Sun, Mar 08, 2015 at 07:43:29PM +0100, Reimar Döffinger wrote: > > > > On 08.03.2015, at 19:34, Michael Niedermayer <michae...@gmx.at> wrote: > > > > > On Sun, Mar 08, 2015 at 05:16:43PM +0100, Reimar Döffinger wrote: > > > > >> Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc > > > > >> in my tests on a G4 7450. > > > > >> > > > > >> Signed-off-by: Reimar Döffinger <reimar.doeffin...@gmx.de> > > > > > > > > > > breaks build: > > > > > CC libavcodec/aliaspixdec.o > > > > > libavcodec/aliaspixdec.c: In function ‘decode_frame’: > > > > > libavcodec/aliaspixdec.c:35:75: error: expected identifier or ‘(’ > > > > > before ‘unsigned’ > > > > > > > > What compiler/os/... is this? I only tried on Linux, not OSX for > > > > example. Though maybe I just messed up the merge, sorry my PPC machine > > > > doesn't have email. > > > > > > gcc 4.6 (Debian 4.6.3-14) > > > > > > the problem is the "pixel" identifer, renaming it make it build the > > > affected file > > > > Hm, I don't have that issue with 4.9. > > I guess something's broken with the altivec header? > > Looking at the 4.9 version a #undef pixel right after > > the altivec.h include might fix it? > > Assuming we don't actually use it anywhere as an altivec > > keyword. > > your patch with #undef pixel added after the include: > > CC libavcodec/dss_sp.o > libavcodec/dss_sp.c: In function ‘dss_sp_gen_exc’: > libavcodec/dss_sp.c:473:1: error: parameter name omitted
That seems to be due to the vector define. I don't think we can avoid that, to my knowledge using __vector instead doesn't work with some OSX compilers (plus it's kind of ugly). It would be possible to undefine them only in intreadwrite.h, but that would mean altivec code that includes it before altivec.h will break. Does anyone have a suggestion on how to solve this that isn't completely horrible? I guess a gcc version check might be an option, assuming that's what makes the difference... _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel