This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/12817] New: Altivec code generation error with setjmp


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]