[MPlayer-dev-eng] ppc runtime-cpu-detection fails with gcc 3.3

[Ivan Kalvachev]

2006/2/23, Alan Curry <pacman at theworld.com>:
> There's a bug in gcc 3.3:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13133
>
> which prevents runtime CPU detection of altivec from working. If run on a
> machine without altivec support, it dies with SIGILL because gcc has decided
> to save all the altivec registers (along with floating point and others) in
> the prologue. This bug is triggered by the presence of a call to [sig]setjmp
> in the function.
>
> It would be possible to rearrange the code in cpudetect.c to work around the
> gcc 3.3 bug, but it's not easy - you have to have a SIGILL handler installed
> before you can safely call a function that calls setjmp, but you have to have
> a jmp_buf ready before your SIGILL handler can do anything useful, because
> returning from the handler just causes the illegal instruction to be
> retried. The only way I can think of to make it work is to forget the
> handler, use a child process and let it die from the SIGILL.
>
> And that's not the end of it. There are other places in mplayer that setjmp
> is used, and they will all die with SIGILL on non-altivec-capable machines if
> compiled with gcc-3.3 -mabi=altivec.
>
> It looks to me like we should blacklist the combination of ppc,
> runtime-cpu-detect, and gcc 3.3 in configure. Objections? Alternatives?
> Comments?

MPlayer have old-day policy of _not_ workarounding gcc bugs (read gcc
2.96 flames;)
It would be much simpler to just blacklist the 3.3.x that produce this
bug and require the newer (fixed) version.