------- Comment #8 from atgraham at gmail dot com 2006-08-08 23:21 -------
(In reply to comment #7)
> I don't get any failures with the 4.0-branch for powerpc-linux with sjlj
> exceptions. Here's the executable test case I'm using for a regression hunt:
Janis,
Thank you for looking into this. I built gcc 4.1.1 for powerpc-linux, and
although I don't have the hardware in front of me right now to run the
executable, I can see just by looking at the disassembly that the bug exists
for -O0:
disassembly of tryfunc(), compiled with:
powerpc-linux-g++ -O0 -msoft-float -mcpu=405 -c bug.cc -fno-inline
00000000 <tryfunc()>:
0: 94 21 ff 50 stwu r1,-176(r1)
4: 7c 08 02 a6 mflr r0
8: 7d 80 00 26 mfcr r12
c: 91 c1 00 68 stw r14,104(r1)
10: 91 e1 00 6c stw r15,108(r1)
14: 92 01 00 70 stw r16,112(r1)
18: 92 21 00 74 stw r17,116(r1)
1c: 92 41 00 78 stw r18,120(r1)
20: 92 61 00 7c stw r19,124(r1)
24: 92 81 00 80 stw r20,128(r1)
28: 92 a1 00 84 stw r21,132(r1)
2c: 92 c1 00 88 stw r22,136(r1)
30: 92 e1 00 8c stw r23,140(r1)
34: 93 01 00 90 stw r24,144(r1)
38: 93 21 00 94 stw r25,148(r1)
3c: 93 41 00 98 stw r26,152(r1)
40: 93 61 00 9c stw r27,156(r1)
44: 93 81 00 a0 stw r28,160(r1)
48: 93 a1 00 a4 stw r29,164(r1)
4c: 93 c1 00 a8 stw r30,168(r1)
50: 93 e1 00 ac stw r31,172(r1)
54: 90 01 00 b4 stw r0,180(r1)
58: 91 81 00 64 stw r12,100(r1)
5c: 7c 3f 0b 78 mr r31,r1
60: 3d 20 00 00 lis r9,0
62: R_PPC_ADDR16_HA __gxx_personality_sj0
64: 38 09 00 00 addi r0,r9,0
66: R_PPC_ADDR16_LO __gxx_personality_sj0
68: 90 1f 00 30 stw r0,48(r31)
6c: 3d 20 00 00 lis r9,0
6e: R_PPC_ADDR16_HA .gcc_except_table
70: 38 09 00 00 addi r0,r9,0
72: R_PPC_ADDR16_LO .gcc_except_table
74: 90 1f 00 34 stw r0,52(r31)
78: 39 7f 00 38 addi r11,r31,56
7c: 38 1f 00 08 addi r0,r31,8
80: 90 0b 00 00 stw r0,0(r11)
84: 3d 20 00 00 lis r9,0
86: R_PPC_ADDR16_HA .text+0xec
88: 38 09 00 ec addi r0,r9,236
8a: R_PPC_ADDR16_LO .text+0xec
8c: 90 0b 00 04 stw r0,4(r11)
90: 80 01 00 00 lwz r0,0(r1)
94: 90 0b 00 08 stw r0,8(r11)
98: 90 2b 00 0c stw r1,12(r11)
9c: 38 1f 00 18 addi r0,r31,24
a0: 7c 03 03 78 mr r3,r0
a4: 48 00 00 01 bl a4 <tryfunc()+0xa4>
a4: R_PPC_REL24 _Unwind_SjLj_Register
a8: 38 1f 00 08 addi r0,r31,8
ac: 7c 03 03 78 mr r3,r0
b0: 48 00 00 01 bl b0 <tryfunc()+0xb0>
b0: R_PPC_REL24 Command::Command()
b4: 38 60 00 04 li r3,4
b8: 48 00 00 01 bl b8 <tryfunc()+0xb8>
b8: R_PPC_REL24 __cxa_allocate_exception
bc: 7c 60 1b 78 mr r0,r3
c0: 7c 0b 03 78 mr r11,r0
c4: 7d 69 5b 78 mr r9,r11
c8: 38 00 00 01 li r0,1
cc: 90 09 00 00 stw r0,0(r9)
d0: 7d 63 5b 78 mr r3,r11
d4: 3d 20 00 00 lis r9,0
d6: R_PPC_ADDR16_HA typeinfo for int
d8: 38 00 00 01 li r0,1
dc: 90 1f 00 1c stw r0,28(r31)
e0: 38 89 00 00 addi r4,r9,0
e2: R_PPC_ADDR16_LO typeinfo for int
e4: 38 a0 00 00 li r5,0
e8: 48 00 00 01 bl e8 <tryfunc()+0xe8>
e8: R_PPC_REL24 __cxa_throw
ec: 3b ff ff f8 addi r31,r31,-8
f0: 80 1f 00 20 lwz r0,32(r31)
f4: 90 1f 00 50 stw r0,80(r31)
f8: 80 1f 00 50 lwz r0,80(r31)
fc: 90 1f 00 4c stw r0,76(r31)
100: 38 1f 00 08 addi r0,r31,8
104: 7c 03 03 78 mr r3,r0
108: 48 00 00 01 bl 108 <tryfunc()+0x108>
108: R_PPC_REL24 Command::~Command()
10c: 80 1f 00 4c lwz r0,76(r31)
110: 90 1f 00 50 stw r0,80(r31)
114: 38 00 ff ff li r0,-1
118: 90 1f 00 1c stw r0,28(r31)
11c: 80 7f 00 50 lwz r3,80(r31)
120: 48 00 00 01 bl 120 <tryfunc()+0x120>
120: R_PPC_REL24 _Unwind_SjLj_Resume
At addresses 0xa8-0xb0, the constructor is called with r31+8. At addresses
0x100-0x108, the destructor is also called with r31+8. However, r31 is
modified at address 0xec (it subtracts 8)! Is this not what you're seeing?
The problem is easier to spot in optimized disassemblies because the extra
subtraction has been optimized to coincide with the placing of the object's
address into r3.
Your code is a little different than mine. It was easier for me to reproduce
the bug with the ~Command() destructor virtual and when compiled with
-fno-inline. Otherwise, the functions would get inlined or the object would
get optimized away completely.
I spent a few hours on this problem on Saturday (Aug 5), doing my own little
regression hunt. I stopped the regression hunt at 3.4.0, because before that,
the exception handling code starts to look entirely different. As I said in
Comment #4, all versions from 3.4.0 display this problem at -O0, but only 4.1
and above display it at -O[s123] as well.
I'll retry the 4.0 series again as soon as I can.
Since some of my previous comments are confusing, I'll reiterate that Comments
#2 and #3 describe correct output, from gcc 4.1.1 with dwarf2-eh and from gcc
4.0.3 -Os respectively. Comments #0 and #4 describe buggy compiler output. So
you were correct when you said that "some of the submitter's examples look just
fine".
Thanks again for helping out. I'll be working on this problem as time permits.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28493
