[MPlayer-dev-eng] buggy linux altivec support (was: workaround for altivec const vars in gcc-3.4 (postproc/swscale_altivec_template.c))

[Romain Dolbeau]

Luca Barbato wrote:

> <flame>
> Do your homework
> take a look at the altivec.h and you'll discover why that happens...
> (already found in libmpeg2 and fixed ages ago btw=E)
> </flame>

And if that's such a well-known problem, why doesn't the
thing spit out a warning or an error instead of dying
on me with a memory allocation error after eating up 1GiB ?

> The problem with bigger and bigger intermediate files (and ram usage) is 
> just due the fact there are many preprocessor expansion if you use 
> nested altivec functions. The quick solution is split them a bit (2 
> levels is the most you can get w/out depleting your ram), the better 
> solution is improve the preprocessor or the macros in altivec.h

I have chosen the best solution: use a gcc that works,
like the apple one. Supporting a compiler and an OS
I don't use isn't worth being flamed for it. I can give
up very easily.

> The problem with screw up result MAY be due something like having 
> -fstrict-aliasing on when building code that uses type punning.

The problem is a buggy compiler. If nobody has the time to
fix it, that's fine with me, because I don't actually use
it for anything except checking the code works in an OS
I don't use (well, I use it for checking :-).

The answer to the check is: it doesn't work, sorry,
fix the compiler...

> If you are sure that your code and the requested optimization are sane, 
> please use the bugzilla to report the problem and not complain on a 
> completely unrelated ml.

It is related ; the bug will bite all linux/ppc users trying
to compile mplayer and/or ffmpeg. And you mentioned above
that it's a known problem, so there's no point in reporting
it *again* to gcc-dev. It's now in the mplayer-dev ML, so
users will find the answer when compiling mplayer in linux/ppc
fails.

-- 
Romain Dolbeau