[Bug c/27026] New: unexpected creation of altivec instructions

["obiwan at mailmij dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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 = &block;
    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 = &block; 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