This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/12817] New: Altivec code generation error with setjmp
- From: "john dot whitney at timesys dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 28 Oct 2003 20:42:32 -0000
- Subject: [Bug c/12817] New: Altivec code generation error with setjmp
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12817
Summary: Altivec code generation error with setjmp
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot whitney at timesys dot com
CC: gcc-bugs at gcc dot gnu dot org,john dot whitney at
timesys dot com
GCC build triplet: powerpc-linux
GCC host triplet: i686-linux
GCC target triplet: i686-linux
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. 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.
This problem appears in GCC 3.2, and in a test build I made of GCC 3.3.2.