Altivec Code generation bug

[John Whitney <john dot whitney at timesys dot com>]

Hello,

I've recently come across what appears to be a GCC code generation bug, and
wanted to verify that I am interpreting the results correctly (I hope this
is the correct mailing list for this).

We are using GCC 3.2 for the PowerPC 74xx to compile the Linux Test Project
code (in specific, the write04 test).  I found that the resulting executable
was segfaulting.  Investigation showed the following assembly code:

  70:   7d 80 42 a6     mfvrsave        r12
  74:   91 8c ff 20     stw     r12,-224(r12)
  78:   65 8c df ff     oris    r12,r12,57343
  7c:   61 8c ff ff     ori     r12,r12,65535
  80:   7d 80 43 a6     mtvrsave        r12

VRSAVE was 0, so line 74 resulted in a NULL pointer access.

I've come up with a much-reduced test program that exercises this problem:
-------------------
#include <signal.h>
#include <setjmp.h>
#include <limits.h>

static sigjmp_buf jmp;

int main(int argc, char **argv)
{
        char wbuf[8 * PIPE_BUF];

        if (sigsetjmp(jmp, 1)) {
                return 1;
        }
        return 0;
}
-------------------

This produces the following assembly code:

10000490 <main>:
10000490:       7c 2c 0b 78     mr      r12,r1
10000494:       3c 00 ff ff     lis     r0,-1
10000498:       60 00 7e 30     ori     r0,r0,32304
1000049c:       7c 21 01 6e     stwux   r1,r1,r0
100004a0:       38 00 fe 50     li      r0,-432
100004a4:       7e 8c 01 ce     stvx    v20,r12,r0
100004a8:       38 00 fe 60     li      r0,-416
100004ac:       7e ac 01 ce     stvx    v21,r12,r0
100004b0:       38 00 fe 70     li      r0,-400
100004b4:       7e cc 01 ce     stvx    v22,r12,r0
100004b8:       38 00 fe 80     li      r0,-384
100004bc:       7e ec 01 ce     stvx    v23,r12,r0
100004c0:       38 00 fe 90     li      r0,-368
100004c4:       7f 0c 01 ce     stvx    v24,r12,r0
100004c8:       38 00 fe a0     li      r0,-352
100004cc:       7f 2c 01 ce     stvx    v25,r12,r0
100004d0:       38 00 fe b0     li      r0,-336
100004d4:       7f 4c 01 ce     stvx    v26,r12,r0
100004d8:       38 00 fe c0     li      r0,-320
100004dc:       7f 6c 01 ce     stvx    v27,r12,r0
100004e0:       38 00 fe d0     li      r0,-304
100004e4:       7f 8c 01 ce     stvx    v28,r12,r0
100004e8:       38 00 fe e0     li      r0,-288
100004ec:       7f ac 01 ce     stvx    v29,r12,r0
100004f0:       38 00 fe f0     li      r0,-272
100004f4:       7f cc 01 ce     stvx    v30,r12,r0
100004f8:       38 00 ff 00     li      r0,-256
100004fc:       7f ec 01 ce     stvx    v31,r12,r0
10000500:       7d 80 42 a6     mfvrsave        r12
10000504:       91 8c ff 20     stw     r12,-224(r12)
10000508:       65 8c df ff     oris    r12,r12,57343
1000050c:       61 8c ff ff     ori     r12,r12,65535
10000510:       7d 80 43 a6     mtvrsave        r12
10000514:       7c 08 02 a6     mflr    r0


Again, the zero-containing r12 is used at address 0x10000500.  This appears
to be caused by the 32k stack variable, wbuf (I didn't write the code!).  If
that variable is made static, or reduced in size, r1 is used as expected in
the line following mfvrsave, instead of the erroneous r12.

Note that this code is also generated with or without the -mno-altivec flag
given to GCC, which seems odd.

In any case, this problem appears in GCC 3.2, and in a test build I made of
GCC 3.3.2.  I've looked on the web and through the GCC mailing lists, but
haven't seen any mention made of this problem, but I could have missed
something.

Any argument that this isn't a compiler bug?  Any suggestions on how to fix
the problem?

Thank you,
John Whitney

Using both the GCC 3.2 and 3.3.2 versions, I compile the following code