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

Reply via email to