This has been bugging me for already more then a year, but tonight I found some
time to debug it.
I'm running mandrake-ppc on a G3 processor. As is common for most distro's,
"-mcpu=7450 -maltivec" are the standard compile options, even although my
processor cannot execute altivec instructions. In general, this works
perfectly. Except for this case:
./mplayer -ao alsa /opt/shared/music/test.mp3
MPlayer dev-CVS-060323-17:34-4.0.3 (C) 2000-2006 MPlayer Team
CPU: PowerPC
<snip some>
Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
==========================================================================
Illegal instruction
backtrace:
#0 0x10110bd0 in init ()
#1 0x10107e0c in init_best_audio_out ()
#2 0x1006ca4c in main ()
this is init in ao_alsa.c of the mplayer internal copy of libao2.
lets continue:
0x10110b9c <init+0>: stwu r1,-432(r1)
0x10110ba0 <init+4>: mflr r0
0x10110ba4 <init+8>: stw r26,408(r1)
0x10110ba8 <init+12>: stw r27,412(r1)
0x10110bac <init+16>: stw r28,416(r1)
0x10110bb0 <init+20>: stw r29,420(r1)
0x10110bb4 <init+24>: stw r31,428(r1)
0x10110bb8 <init+28>: stw r0,436(r1)
0x10110bbc <init+32>: mr r31,r1
0x10110bc0 <init+36>: stw r3,360(r31)
0x10110bc4 <init+40>: stw r4,364(r31)
0x10110bc8 <init+44>: stw r5,368(r31)
0x10110bcc <init+48>: stw r6,372(r31)
0x10110bd0 <init+52>: vxor v0,v0,v0
0x10110bd4 <init+56>: li r0,32
0x10110bd8 <init+60>: stvx v0,r31,r0
0x10110bdc <init+64>: vxor v0,v0,v0
vxor? That's altivec. Weird....
Adding -O -g got rid of the bug. Strangely, adding -O2 or -O3 seemed to fix the
issue as well (normally, no -O option is specified).
I played a bit with the sources (see the *.i file I'll add in a subsequent
post).
This is the problematic area of ao_alsa.c:
int init(int rate_hz, int channels, int format, int flags)
{
int err;
int block;
//int block_ad = █
strarg_t device;
snd_pcm_uframes_t bufsize;
snd_pcm_uframes_t boundary;
opt_t subopts[] = {
{"block", OPT_ARG_BOOL, &block, NULL},
{"device", OPT_ARG_STR, &device, (opt_test_f)str_maxlen},
{NULL}
};
Checkout the //int block_ad = █ which I added inthere myself.
If I uncomment this, the program works perfectly!
But the line in question doesn't do anything at all since block_ad is not used
anywhere (I originally tried to substitute &block for block_add because I
iterativelly found that &block was the problematic thingy).
I guess just getting the address of block puts the compiler straight about what
it is supposed to do:)
I hope this provides enough info to find and fix the problem.
Danny
--
Summary: unexpected creation of altivec instructions
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: obiwan at mailmij dot org
GCC host triplet: ppc
GCC target triplet: ppc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27026
