public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/38952]  New: [4.4 Regression] EH does not work.
@ 2009-01-23 23:20 dave dot korn dot cygwin at gmail dot com
  2009-01-23 23:31 ` [Bug target/38952] " dave dot korn dot cygwin at gmail dot com
                   ` (26 more replies)
  0 siblings, 27 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-23 23:20 UTC (permalink / raw)
  To: gcc-bugs

SjLj EH (the default) is completely broken on Cygwin (and MinGW, confirmed by
Danny in private email).

  The failures have been occurring since at least November: see, e.g.
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02144.html

(The distro maintainers have all been so focussed recently on getting DW2 EH to
work on our platforms that this flew in under our radar; sorry for not noticing
sooner).

  A simple test case and some complicated low-level analysis will follow in
comments and attachments.  So far it looks like an error in frame pointer
elimination caused by a miscalculation of the initial frame pointer offset.  I
have filed this as a target problem since elimination is driven by the backend
but it could just as well be a bug in rtl-optimisation; we'll know more soon.

  cheers,
    DaveK


-- 
           Summary: [4.4 Regression] EH does not work.
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dave dot korn dot cygwin at gmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
  2009-01-23 23:31 ` [Bug target/38952] " dave dot korn dot cygwin at gmail dot com
@ 2009-01-23 23:31 ` dave dot korn dot cygwin at gmail dot com
  2009-01-23 23:32 ` dave dot korn dot cygwin at gmail dot com
                   ` (24 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-23 23:31 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from dave dot korn dot cygwin at gmail dot com  2009-01-23 23:31 -------
Created an attachment (id=17169)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17169&action=view)
Simple throw-catch testcase

Test cases don't come much simpler than this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
@ 2009-01-23 23:31 ` dave dot korn dot cygwin at gmail dot com
  2009-01-23 23:31 ` dave dot korn dot cygwin at gmail dot com
                   ` (25 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-23 23:31 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from dave dot korn dot cygwin at gmail dot com  2009-01-23 23:31 -------
Created an attachment (id=17170)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17170&action=view)
Pre-processed source of testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
  2009-01-23 23:31 ` [Bug target/38952] " dave dot korn dot cygwin at gmail dot com
  2009-01-23 23:31 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-23 23:32 ` dave dot korn dot cygwin at gmail dot com
  2009-01-23 23:44 ` dave dot korn dot cygwin at gmail dot com
                   ` (23 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-23 23:32 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from dave dot korn dot cygwin at gmail dot com  2009-01-23 23:32 -------
Created an attachment (id=17171)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17171&action=view)
Generated assembler for testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (2 preceding siblings ...)
  2009-01-23 23:32 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-23 23:44 ` dave dot korn dot cygwin at gmail dot com
  2009-01-24  0:10 ` dave dot korn dot cygwin at gmail dot com
                   ` (22 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-23 23:44 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from dave dot korn dot cygwin at gmail dot com  2009-01-23 23:44 -------
  The bug manifests itself as a crash on exit from main(); $eip is set to zero
and we get a SEGV.

  On entry to main(), the registers show:

esp            0x22cc40 0x22cc40
ebp            0x22cca8 0x22cca8

  Just before the epilogue at the end of main, we see:

esp            0x22cc40 0x22cc40
ebp            0x22cc90 0x22cc90

(gdb) x/32xw 0x22cc40
0x22cc40:       0x0022cc5c      0x0040e7e0      0x00000000      0x004f0584
0x22cc50:       0x005005c2      0x32200060      0x0022cc78      0x00000000
0x22cc60:       0x00000000      0x100325b8      0x00000001      0x61010173
0x22cc70:       0x00000001      0x00407600      0x00407bd4      0x0022cc90
0x22cc80:       0x004010ec      0x0022cc40      0x00000000      0x610df2c7
0x22cc90:       0x100324fa      0x00000000      0x611021a0      0x0040546c
0x22cca0:       0x611021a0      0x0040546c      0x0022cd98      0x610060e8
0x22ccb0:       0x00000001      0x100324a0      0x10030090      0x60030000
(gdb)

and so when we come to the ret instruction, ...

(gdb)

Breakpoint 2, 0x00401125 in main () at ./eh.C:11
11      }
(gdb) info reg
eax            0x0      0
ecx            0x22cb30 2280240
edx            0x0      0
ebx            0x0      0
esp            0x22cc94 0x22cc94
ebp            0x100324fa       0x100324fa
esi            0x611021a0       1628447136
edi            0x40546c 4215916
eip            0x401125 0x401125 <main+181>
eflags         0x202    [ IF ]
cs             0x1b     27
ss             0x23     35
ds             0x23     35
es             0x23     35
fs             0x38     56
gs             0x0      0
(gdb) stepi
0x00000000 in ?? ()

  Next comment will analyze how $ebp comes to have the wrong value.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (3 preceding siblings ...)
  2009-01-23 23:44 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-24  0:10 ` dave dot korn dot cygwin at gmail dot com
  2009-01-24  1:08 ` dave dot korn dot cygwin at gmail dot com
                   ` (21 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-24  0:10 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from dave dot korn dot cygwin at gmail dot com  2009-01-24 00:10 -------
  Here is a disassembly of the start of the main function:

(gdb) disass main
Dump of assembler code for function main:
0x00401070 <main+0>:    push   %ebp
0x00401071 <main+1>:    mov    %esp,%ebp
0x00401073 <main+3>:    and    $0xfffffff0,%esp
0x00401076 <main+6>:    sub    $0x60,%esp
0x00401079 <main+9>:    mov    %ebx,0x54(%esp)
0x0040107d <main+13>:   mov    %esi,0x58(%esp)
0x00401081 <main+17>:   mov    %edi,0x5c(%esp)
0x00401085 <main+21>:   movl   $0x407600,0x34(%esp)
0x0040108d <main+29>:   movl   $0x407bd4,0x38(%esp)
0x00401095 <main+37>:   lea    0x3c(%esp),%eax
0x00401099 <main+41>:   lea    0x50(%esp),%edx
0x0040109d <main+45>:   mov    %edx,(%eax)
0x0040109f <main+47>:   movl   $0x4010ec,0x4(%eax)
0x004010a6 <main+54>:   mov    %esp,0x8(%eax)
0x004010a9 <main+57>:   lea    0x1c(%esp),%eax
0x004010ad <main+61>:   mov    %eax,(%esp)
0x004010b0 <main+64>:   call   0x405068 <_Unwind_SjLj_Register>
0x004010b5 <main+69>:   call   0x40515c <__main>
0x004010ba <main+74>:   movl   $0x4,(%esp)
0x004010c1 <main+81>:   call   0x406b00 <__cxa_allocate_exception>
0x004010c6 <main+86>:   movl   $0x1,(%eax)
0x004010cc <main+92>:   movl   $0x0,0x8(%esp)
0x004010d4 <main+100>:  movl   $0x40e7e0,0x4(%esp)
0x004010dc <main+108>:  mov    %eax,(%esp)
0x004010df <main+111>:  movl   $0x1,0x20(%esp)
0x004010e7 <main+119>:  call   0x4075a0 <__cxa_throw>
0x004010ec <main+124>:  mov    0x24(%esp),%eax
0x004010f0 <main+128>:  mov    %eax,(%esp)
0x004010f3 <main+131>:  call   0x406da0 <__cxa_begin_catch>

  If we set a breakpoint on every function call, and run through it:

(gdb) r
Starting program: /win/i/FSF-Gcc/obj-sjlj/gcc/testsuite/g++/eh.exe
[New thread 648.0x754]
[New thread 648.0x31c]

Breakpoint 1, main () at ./eh.C:4
4       {
(gdb) print $esp
$2 = (void *) 0x22ccac
(gdb) c
Continuing.

Breakpoint 3, 0x004010b0 in main () at ./eh.C:4
4       {
(gdb) print $esp
$3 = (void *) 0x22cc40
(gdb) print $ebp
$14 = (void *) 0x22cca8
(gdb) c
Continuing.

Breakpoint 4, main () at ./eh.C:4
4       {
(gdb) print $ebp
$4 = (void *) 0x22cca8
(gdb) c
Continuing.

Breakpoint 5, 0x004010c1 in main () at ./eh.C:6
6           throw 1;
(gdb) print $ebp
$5 = (void *) 0x22cca8
(gdb) c
Continuing.

Breakpoint 6, 0x004010e7 in main () at ./eh.C:6
6           throw 1;
(gdb) print $ebp
$6 = (void *) 0x22cca8
(gdb) c
Continuing.

Breakpoint 10, _Unwind_SjLj_RaiseException (exc=0x100325b8)
    at /gnu/gcc/gcc/libgcc/../gcc/unwind-sjlj.c:148
148       if (use_fc_key < 0)
Current language:  auto; currently c
(gdb) print $ebp
$7 = (void *) 0x22cc18
(gdb) c
Continuing.

Breakpoint 7, 0x004010f3 in main () at ./eh.C:8
8         catch (...) {
Current language:  auto; currently c++
(gdb) print $ebp
$8 = (void *) 0x22cc90
(gdb) c
Continuing.

Breakpoint 8, 0x00401100 in main () at ./eh.C:8
8         catch (...) {
(gdb) print $ebp
$9 = (void *) 0x22cc90
(gdb) c
Continuing.

Breakpoint 9, 0x0040110c in main () at ./eh.C:8
8         catch (...) {
(gdb) print $ebp
$10 = (void *) 0x22cc90
(gdb) c
Continuing.

Breakpoint 11, 0x00401122 in main () at ./eh.C:11
11      }
(gdb) print $ebp
$11 = (void *) 0x22cc90
(gdb) c
Continuing.

Breakpoint 2, 0x00401125 in main () at ./eh.C:11
11      }
(gdb) print $ebp
$12 = (void *) 0x100324fa
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb)

... we can see that $ebp is correct right up until the call to __cxa_throw at
0x004010e7, but when we return to the catch landing site at 0x004010f3, $ebp is
incorrect.

  This incorrect value is calculated in the code at the start of main(), where 
the code generated by sjlj_emit_function_enter calls
expand_builtin_setjmp_setup to initialise the jbuf[] member of the struct
SjLj_Function_Context that it then passes to _Unwind_SjLj_Register.  From that
call:

0x004010a9 <main+57>:   lea    0x1c(%esp),%eax
0x004010ad <main+61>:   mov    %eax,(%esp)
0x004010b0 <main+64>:   call   0x405068 <_Unwind_SjLj_Register>

the struct is at an offset of 0x1c on the stack.  Looking at the memory dump,
just before the call:

0x22cc40:       0x0022cc5c      0xbdbdbdbd      0xbdbdbdbd      0xbdbdbdbd
0x22cc50:       0xbdbdbdbd      0xbdbdbdbd      0xbdbdbdbd      0xbdbdbdbd
0x22cc60:       0xbdbdbdbd      0xbdbdbdbd      0xbdbdbdbd      0xbdbdbdbd
0x22cc70:       0xbdbdbdbd      0x00407600      0x00407bd4      0x0022cc90
0x22cc80:       0x004010ec      0x0022cc40      0xbdbdbdbd      0xbdbdbdbd
0x22cc90:       0xbdbdbdbd      0x00000000      0x611021a0      0x0040546c
0x22cca0:       0xbdbdbdbd      0xbdbdbdbd      0x0022cd98      0x610060e8
0x22ccb0:       0x00000001      0x100324a0      0x10030090      0x60030000

.. shows that the struct has been initialised like so:

OFFS:0x001c:  prev = 0xbdbdbdbd, call_Site 0xbdbdbdbd
OFFS:0x0024:  data[4] = { 0xbdbdbdbd, 0xbdbdbdbd, 0xbdbdbdbd, 0xbdbdbdbd }
OFFS:0x0034:  personality = 0x00407600 = <__gxx_personality_sj0>
OFFS:0x0038:  lsda = 0x00407bd4 = <__DTOR_LIST__+16>:    0x010d00ff
OFFS:0x003c:  jbuf = void*[5] at 
   0x22cc7c:                                                       0x0022cc90
   0x22cc80:       0x004010ec      0x0022cc40      0xbdbdbdbd      0xbdbdbdbd

(note that I manually filled the empty stack frame with 0xbd bytes immediately
after it was allocated in this run).

  A comment in expand_builtin_setjmp_setup says 

  /* We store the frame pointer and the address of receiver_label in
     the buffer and use the rest of it for the stack save area, which
     is machine-dependent.  */

and 0x004010ec is indeed the receiver_label, but 0x0022cc90 is not the frame
pointer.  The code that initialises this struct is

0x00401085 <main+21>:   movl   $0x407600,0x34(%esp)
0x0040108d <main+29>:   movl   $0x407bd4,0x38(%esp)
0x00401095 <main+37>:   lea    0x3c(%esp),%eax
0x00401099 <main+41>:   lea    0x50(%esp),%edx
0x0040109d <main+45>:   mov    %edx,(%eax)
0x0040109f <main+47>:   movl   $0x4010ec,0x4(%eax)
0x004010a6 <main+54>:   mov    %esp,0x8(%eax)

and so it is clear that the "lea 0x50(%esp),%edx" is the source of the
incorrect value 0x0022cc90, that is stored into jbuf[0].

  As this is an offset relative to the stack pointer, yet it originates in the
line

  emit_move_insn (mem, targetm.builtin_setjmp_frame_value ());

I am working on the hypothesis that something has gone wrong with frame pointer
elimination.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (4 preceding siblings ...)
  2009-01-24  0:10 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-24  1:08 ` dave dot korn dot cygwin at gmail dot com
  2009-01-24  6:24 ` dave dot korn dot cygwin at gmail dot com
                   ` (20 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-24  1:08 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from dave dot korn dot cygwin at gmail dot com  2009-01-24 01:08 -------
Here is the RTL that is created by the .130r.eh pass: everything between note 2
and call_insn 3, was added after expand.

try_optimize_cfg iteration 2

(note 1 0 4 NOTE_INSN_DELETED)

(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 2 4 46 2 NOTE_INSN_FUNCTION_BEG)

(insn 46 2 47 2 (set (mem/c:SI (plus:SI (reg/f:SI 54 virtual-stack-vars)
                (const_int -28 [0xffffffe4])) [0 S4 A32])
        (symbol_ref:SI ("__gxx_personality_sj0") [flags 0x43])) -1 (nil))

(insn 47 46 48 2 (set (mem/c:SI (plus:SI (reg/f:SI 54 virtual-stack-vars)
                (const_int -24 [0xffffffe8])) [0 S4 A32])
        (symbol_ref:SI ("*LLSDA0") [flags 0x2])) -1 (nil))

(insn 48 47 49 2 (parallel [
            (set (reg:SI 63)
                (plus:SI (reg/f:SI 54 virtual-stack-vars)
                    (const_int -20 [0xffffffec])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil))

(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
        (reg/f:SI 54 virtual-stack-vars)) -1 (nil))

(insn 50 49 51 2 (set (reg/f:SI 64)
        (label_ref:SI 56)) -1 (insn_list:REG_LABEL_OPERAND 56 (nil)))

(insn 51 50 52 2 (set (mem:SI (plus:SI (reg:SI 63)
                (const_int 4 [0x4])) [0 S4 A8])
        (reg/f:SI 64)) -1 (nil))

(insn 52 51 53 2 (set (mem:SI (plus:SI (reg:SI 63)
                (const_int 8 [0x8])) [0 S4 A8])
        (reg/f:SI 7 sp)) -1 (nil))

(insn 53 52 54 2 (parallel [
            (set (reg:SI 65)
                (plus:SI (reg/f:SI 54 virtual-stack-vars)
                    (const_int -52 [0xffffffcc])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil))

(insn 54 53 55 2 (set (mem:SI (reg/f:SI 56 virtual-outgoing-args) [0 S4 A32])
        (reg:SI 65)) -1 (nil))

(call_insn 55 54 3 2 (call (mem:QI (symbol_ref:SI ("_Unwind_SjLj_Register")
[flags 0x43]) [0 S1 A8])
        (const_int 16 [0x10])) -1 (expr_list:REG_EH_REGION (const_int 0 [0x0])
        (nil))
    (nil))

(call_insn 3 55 6 2 ./eh.C:4 (call (mem:QI (symbol_ref:SI ("__main") [flags
0x43]) [0 S1 A8])
        (const_int 0 [0x0])) -1 (expr_list:REG_EH_REGION (const_int 0 [0x0])
        (nil))
    (nil))


Pass 133r.vregs turns this into:

(insn 46 2 47 2 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
                (const_int -28 [0xffffffe4])) [0 S4 A32])
        (symbol_ref:SI ("__gxx_personality_sj0") [flags 0x43])) 41 {*movsi_1}
(nil))

(insn 47 46 48 2 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
                (const_int -24 [0xffffffe8])) [0 S4 A32])
        (symbol_ref:SI ("*LLSDA0") [flags 0x2])) 41 {*movsi_1} (nil))

(insn 48 47 49 2 (parallel [
            (set (reg:SI 63)
                (plus:SI (reg/f:SI 20 frame)
                    (const_int -20 [0xffffffec])))
            (clobber (reg:CC 17 flags))
        ]) 213 {*addsi_1} (nil))

(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
        (reg/f:SI 20 frame)) 41 {*movsi_1} (nil))

(insn 50 49 51 2 (set (reg/f:SI 64)
        (label_ref:SI 56)) 41 {*movsi_1} (insn_list:REG_LABEL_OPERAND 56
(nil)))

(insn 51 50 52 2 (set (mem:SI (plus:SI (reg:SI 63)
                (const_int 4 [0x4])) [0 S4 A8])
        (reg/f:SI 64)) 41 {*movsi_1} (nil))

(insn 52 51 53 2 (set (mem:SI (plus:SI (reg:SI 63)
                (const_int 8 [0x8])) [0 S4 A8])
        (reg/f:SI 7 sp)) 41 {*movsi_1} (nil))

(insn 53 52 54 2 (parallel [
            (set (reg:SI 65)
                (plus:SI (reg/f:SI 20 frame)
                    (const_int -52 [0xffffffcc])))
            (clobber (reg:CC 17 flags))
        ]) 213 {*addsi_1} (nil))

(insn 54 53 55 2 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
        (reg:SI 65)) 41 {*movsi_1} (nil))

(call_insn 55 54 3 2 (call (mem:QI (symbol_ref:SI ("_Unwind_SjLj_Register")
[flags 0x43]) [0 S1 A8])
        (const_int 16 [0x10])) 466 {*call_0} (expr_list:REG_EH_REGION
(const_int 0 [0x0])
        (nil))
    (nil))


Note that insn 49 is the crucial one here that stores the (later miscalculated)
value of the frame pointer (i.e., $ebp - before elimination) into the jmp_buf.

At pass 174r.ira, this becomes:

(insn 48 47 73 2 (parallel [
            (set (reg/f:SI 0 ax [63])
                (plus:SI (reg/f:SI 7 sp)
                    (const_int 60 [0x3c])))
            (clobber (reg:CC 17 flags))
        ]) 213 {*addsi_1} (expr_list:REG_EQUIV (plus:SI (reg/f:SI 7 sp)
            (const_int 60 [0x3c]))
        (nil)))

(insn 73 48 49 2 (set (reg:SI 1 dx)
        (plus:SI (reg/f:SI 7 sp)
            (const_int 80 [0x50]))) 209 {*lea_1} (nil))

(insn 49 73 51 2 (set (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
        (reg:SI 1 dx)) 41 {*movsi_1} (nil))


And this is the point at which the incorrect offset first appears.

Ouch.  I hope this isn't an IRA bug, I know nothing about that.  Is it valid to
do frame pointer elimination before reload like that?  Because the other
possibility is that the x86 backend is suddenly growing the frame size during
some later pass.  (Well, I guess we *know* that has to be happening, the
question is whether it's allowed to or not.  I think it's allowed to change its
mind any time while the middle end is still trying combines and splits and
repeatedly re-layouting the stack and calling INITIAL_FRAME_POINTER_OFFSET over
and again, and I know it's not allowed once we're in strict after reload, but I
don't know when exactly it gets crystallized).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (5 preceding siblings ...)
  2009-01-24  1:08 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-24  6:24 ` dave dot korn dot cygwin at gmail dot com
  2009-01-24  8:47 ` rguenth at gcc dot gnu dot org
                   ` (19 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-24  6:24 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from dave dot korn dot cygwin at gmail dot com  2009-01-24 06:23 -------
Not IRA-related, it seems, but reload-backend interaction.  -fno-ira doesn't
make any difference to the generated code to calculate the frame pointer for
the jmp_buf.  In a non-IRA build, pass 172r.lreg has:

(insn 49 48 51 2 (set (mem:SI (reg/f:SI 63) [0 S4 A8])
        (reg/f:SI 20 frame)) 41 {*movsi_1} (nil))

and pass 173r.greg has

(insn 73 48 49 2 (set (reg:SI 1 dx)
        (plus:SI (reg/f:SI 7 sp)
            (const_int 80 [0x50]))) 209 {*lea_1} (nil))

(insn 49 73 51 2 (set (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
        (reg:SI 1 dx)) 41 {*movsi_1} (nil))

and here we can see that it's reload doing the FP elimination:

Reloads for insn # 49
Reload 0: reload_out (SI) = (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
        NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
        reload_out_reg: (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 7 sp)
                                                    (const_int 80 [0x50]))
        GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
        reload_in_reg: (plus:SI (reg/f:SI 7 sp)
                                                    (const_int 80 [0x50]))
        reload_reg_rtx: (reg:SI 1 dx)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (6 preceding siblings ...)
  2009-01-24  6:24 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-24  8:47 ` rguenth at gcc dot gnu dot org
  2009-01-24 17:07 ` ubizjak at gmail dot com
                   ` (18 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-01-24  8:47 UTC (permalink / raw)
  To: gcc-bugs



-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (7 preceding siblings ...)
  2009-01-24  8:47 ` rguenth at gcc dot gnu dot org
@ 2009-01-24 17:07 ` ubizjak at gmail dot com
  2009-01-24 18:12 ` dave dot korn dot cygwin at gmail dot com
                   ` (17 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: ubizjak at gmail dot com @ 2009-01-24 17:07 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #8 from ubizjak at gmail dot com  2009-01-24 17:06 -------
There are numerous g++ EH failures even for x86-pc-linux-gnu, when gcc is
configured with --enable-sjlj-exceptions, so something is serious FUBAR w.r.t
to SJLJ exceptions.

                === g++ tests ===


Running target unix
FAIL: g++.dg/abi/forced.C execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -Os  execution test
FAIL: g++.old-deja/g++.law/weak.C (test for excess errors)

                === g++ Summary for unix ===

# of expected passes            19034
# of unexpected failures        110
# of expected failures          141
# of unsupported tests          248

Running target unix/-m32
FAIL: g++.dg/abi/forced.C execution test
FAIL: g++.dg/cpp0x/variadic73.C execution test
FAIL: g++.dg/eh/alias1.C execution test
FAIL: g++.dg/eh/cond1.C execution test
FAIL: g++.dg/eh/crossjump1.C execution test
FAIL: g++.dg/eh/ctor1.C execution test
FAIL: g++.dg/eh/ctor2.C execution test
FAIL: g++.dg/eh/elide1.C execution test
FAIL: g++.dg/eh/forced4.C execution test
FAIL: g++.dg/eh/fp-regs.C execution test
FAIL: g++.dg/eh/ia64-2.C execution test
FAIL: g++.dg/eh/loop1.C execution test
FAIL: g++.dg/eh/loop2.C execution test
FAIL: g++.dg/eh/new1.C execution test
FAIL: g++.dg/eh/omit-frame-pointer.C execution test
FAIL: g++.dg/eh/simd-3.C execution test
FAIL: g++.dg/eh/spec3.C execution test
FAIL: g++.dg/eh/spec7.C execution test
FAIL: g++.dg/eh/spec9.C execution test
FAIL: g++.dg/eh/synth2.C execution test
FAIL: g++.dg/eh/template1.C execution test
FAIL: g++.dg/eh/uncaught1.C execution test
FAIL: g++.dg/eh/unexpected1.C execution test
FAIL: g++.dg/eh/weak1.C execution test
FAIL: g++.dg/init/array16.C execution test
FAIL: g++.dg/init/array5.C execution test
FAIL: g++.dg/init/ctor1.C execution test
FAIL: g++.dg/init/placement2.C execution test
FAIL: g++.dg/opt/eh2.C execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-0.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/unwind-0.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-0.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-0.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-0.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-0.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/unwind-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/unwind-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-1.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-1.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/unwind-2.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/unwind-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-2.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-2.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/unwind-3.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/unwind-3.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-3.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-3.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-3.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-3.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/unwind-4.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/unwind-4.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-4.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-4.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-4.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/unwind-4.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/unwind-4.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-4.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/unwind-5.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/unwind-5.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-5.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-5.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-5.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-5.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/unwind-6.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/unwind-6.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-6.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-6.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-6.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-6.C  -Os  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-global-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O0  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -g  execution test
FAIL: g++.old-deja/g++.eh/badalloc1.C execution test
FAIL: g++.old-deja/g++.eh/cleanup1.C execution test
FAIL: g++.old-deja/g++.eh/cleanup2.C execution test
FAIL: g++.old-deja/g++.eh/flow1.C execution test
FAIL: g++.old-deja/g++.eh/fntry1.C execution test
FAIL: g++.old-deja/g++.eh/inline2.C execution test
FAIL: g++.old-deja/g++.eh/new1.C execution test
FAIL: g++.old-deja/g++.eh/new2.C execution test
FAIL: g++.old-deja/g++.eh/pdel1.C execution test
FAIL: g++.old-deja/g++.eh/pdel2.C execution test
FAIL: g++.old-deja/g++.eh/ptr1.C execution test
FAIL: g++.old-deja/g++.eh/rethrow1.C execution test
FAIL: g++.old-deja/g++.eh/rethrow2.C execution test
FAIL: g++.old-deja/g++.eh/rethrow4.C execution test
FAIL: g++.old-deja/g++.eh/rethrow5.C execution test
FAIL: g++.old-deja/g++.eh/rethrow6.C execution test
FAIL: g++.old-deja/g++.eh/spec1.C execution test
FAIL: g++.old-deja/g++.eh/spec2.C execution test
FAIL: g++.old-deja/g++.eh/spec3.C execution test
FAIL: g++.old-deja/g++.eh/tmpl1.C execution test
FAIL: g++.old-deja/g++.eh/vbase1.C execution test
FAIL: g++.old-deja/g++.eh/vbase2.C execution test
FAIL: g++.old-deja/g++.eh/vbase4.C execution test
FAIL: g++.old-deja/g++.law/weak.C (test for excess errors)
FAIL: g++.old-deja/g++.mike/dyncast1.C execution test
FAIL: g++.old-deja/g++.mike/dyncast2.C execution test
FAIL: g++.old-deja/g++.mike/eh10.C execution test
FAIL: g++.old-deja/g++.mike/eh12.C execution test
FAIL: g++.old-deja/g++.mike/eh14.C execution test
FAIL: g++.old-deja/g++.mike/eh16.C execution test
FAIL: g++.old-deja/g++.mike/eh17.C execution test
FAIL: g++.old-deja/g++.mike/eh18.C execution test
FAIL: g++.old-deja/g++.mike/eh21.C execution test
FAIL: g++.old-deja/g++.mike/eh24.C execution test
FAIL: g++.old-deja/g++.mike/eh26.C execution test
FAIL: g++.old-deja/g++.mike/eh27.C execution test
FAIL: g++.old-deja/g++.mike/eh28.C execution test
FAIL: g++.old-deja/g++.mike/eh29.C execution test
FAIL: g++.old-deja/g++.mike/eh3.C execution test
FAIL: g++.old-deja/g++.mike/eh31.C execution test
FAIL: g++.old-deja/g++.mike/eh33.C execution test
FAIL: g++.old-deja/g++.mike/eh35.C execution test
FAIL: g++.old-deja/g++.mike/eh36.C execution test
FAIL: g++.old-deja/g++.mike/eh37.C execution test
FAIL: g++.old-deja/g++.mike/eh38.C execution test
FAIL: g++.old-deja/g++.mike/eh39.C execution test
FAIL: g++.old-deja/g++.mike/eh40.C execution test
FAIL: g++.old-deja/g++.mike/eh41.C execution test
FAIL: g++.old-deja/g++.mike/eh44.C execution test
FAIL: g++.old-deja/g++.mike/eh49.C execution test
FAIL: g++.old-deja/g++.mike/eh5.C execution test
FAIL: g++.old-deja/g++.mike/eh50.C execution test
FAIL: g++.old-deja/g++.mike/eh51.C execution test
FAIL: g++.old-deja/g++.mike/eh6.C execution test
FAIL: g++.old-deja/g++.mike/eh8.C execution test
FAIL: g++.old-deja/g++.mike/p7912.C execution test
FAIL: g++.old-deja/g++.mike/p9706.C execution test
FAIL: g++.old-deja/g++.other/array1.C execution test
FAIL: g++.old-deja/g++.other/eh3.C execution test
FAIL: g++.old-deja/g++.other/init7.C execution test
FAIL: g++.old-deja/g++.other/new7.C execution test
FAIL: g++.old-deja/g++.other/singleton.C execution test
FAIL: g++.old-deja/g++.other/vbase2.C execution test
FAIL: g++.old-deja/g++.robertl/eb31.C execution test
FAIL: g++.old-deja/g++.robertl/eb50.C execution test
FAIL: g++.old-deja/g++.robertl/eb66.C execution test
FAIL: g++.old-deja/g++.robertl/eb88.C execution test

                === g++ Summary for unix/-m32 ===

# of expected passes            19223
# of unexpected failures        234
# of expected failures          141
# of unsupported tests          98

                === g++ Summary ===

# of expected passes            38257
# of unexpected failures        344
# of expected failures          282
# of unsupported tests          346

I think this PR should be marked as critical P1.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |critical
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Priority|P3                          |P1
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-24 17:06:59
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (8 preceding siblings ...)
  2009-01-24 17:07 ` ubizjak at gmail dot com
@ 2009-01-24 18:12 ` dave dot korn dot cygwin at gmail dot com
  2009-01-24 21:41 ` hjl dot tools at gmail dot com
                   ` (16 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-24 18:12 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #9 from dave dot korn dot cygwin at gmail dot com  2009-01-24 18:12 -------
Thanks for the test results and confirmation, Uros.  It looks like more or less
exactly the same list of FAILs as I see on Cygwin, so I think this confirms a
generic issue with frame pointer elimination in the i386 backend.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (9 preceding siblings ...)
  2009-01-24 18:12 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-24 21:41 ` hjl dot tools at gmail dot com
  2009-01-25  5:33 ` dave dot korn dot cygwin at gmail dot com
                   ` (15 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-01-24 21:41 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #10 from hjl dot tools at gmail dot com  2009-01-24 21:41 -------
This is caused by stack alignment change, revision 138335. Joey and
Xuepeng will look into it after holiday, Feb. 1.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joey dot ye at intel dot
                   |                            |com, xuepeng dot guo at
                   |                            |intel dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (10 preceding siblings ...)
  2009-01-24 21:41 ` hjl dot tools at gmail dot com
@ 2009-01-25  5:33 ` dave dot korn dot cygwin at gmail dot com
  2009-01-25  5:56 ` dave dot korn dot cygwin at gmail dot com
                   ` (14 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-25  5:33 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #11 from dave dot korn dot cygwin at gmail dot com  2009-01-25 05:33 -------
Thanks for your help HJ.  I'll do some more debugging and add notes while
you're away.  Happy New Year!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (11 preceding siblings ...)
  2009-01-25  5:33 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-25  5:56 ` dave dot korn dot cygwin at gmail dot com
  2009-01-25  5:58 ` dave dot korn dot cygwin at gmail dot com
                   ` (13 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-25  5:56 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #12 from dave dot korn dot cygwin at gmail dot com  2009-01-25 05:56 -------
Created an attachment (id=17177)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17177&action=view)
Correct code compiled with -mpreferred-stack-boundary=2

Adding "-mpreferred-stack-boundary=2" to the compile line generates a correct,
functioning executable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (12 preceding siblings ...)
  2009-01-25  5:56 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-25  5:58 ` dave dot korn dot cygwin at gmail dot com
  2009-01-25  6:05 ` dave dot korn dot cygwin at gmail dot com
                   ` (12 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-25  5:58 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #13 from dave dot korn dot cygwin at gmail dot com  2009-01-25 05:58 -------
Created an attachment (id=17178)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17178&action=view)
Diffs between good and bad versions

This shows a diff between the testcase compiled with
-mpreferred-stack-boundary=2 and with -mpreferred-stack-boundary=4 (the
default).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (13 preceding siblings ...)
  2009-01-25  5:58 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-25  6:05 ` dave dot korn dot cygwin at gmail dot com
  2009-01-25  6:34 ` dave dot korn dot cygwin at gmail dot com
                   ` (11 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-25  6:05 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #14 from dave dot korn dot cygwin at gmail dot com  2009-01-25 06:05 -------
Adding "-mpreferred-stack-boundary=2" to the command line generates correct
code.

Here are the diffs between code generated by that setting and the default
(-mpreferred-stack-boundary=4) for the start of the function:

--- eh-sb2.s    2009-01-25 05:24:46.718750000 +0000
+++ eh-sb4.s    2009-01-25 05:26:19.187500000 +0000
@@ -10,19 +10,20 @@
 _main:
        pushl   %ebp
        movl    %esp, %ebp
+       andl    $-16, %esp
        pushl   %edi
        pushl   %esi
        pushl   %ebx
-       subl    $68, %esp
-       movl    $___gxx_personality_sj0, -40(%ebp)
-       movl    $LLSDA0, -36(%ebp)
-       leal    -32(%ebp), %eax
-       leal    -12(%ebp), %edx
+       subl    $84, %esp
+       movl    $___gxx_personality_sj0, 52(%esp)
+       movl    $LLSDA0, 56(%esp)
+       leal    60(%esp), %eax
+       leal    80(%esp), %edx
        movl    %edx, (%eax)
        movl    $L5, %edx
        movl    %edx, 4(%eax)
        movl    %esp, 8(%eax)
-       leal    -64(%ebp), %eax
+       leal    28(%esp), %eax
        movl    %eax, (%esp)
        call    __Unwind_SjLj_Register


So.... I think I'm starting to grok what's happening here.  Because of the
larger stack alignment required, and because the incoming stack alignment is
only 8, not 16, we have to use an AND to mask and align the incoming esp.  Now
that means then that we have a hole of unknown size in our stack frame, just
below the frame pointer at the top end.  So because this gap is unkown, we
can't index down from the frame pointer %ebp to the rest of the stack frame any
more, which is why we have to turn the elimination basis upside down and
calculate all the eliminations upward from esp instead.

(The gap is in fact composed of two components.  The dynamic adjustment needed
to align the incoming stack, which cannot be known at compile time, and then
the extra space allocated to the stack frame to ensure its size is a multiple
of the alignment so that the lower end of the frame is also aligned.  Although
this second part is known at compile-time, as long as the first part is
unpredictable we have to do the eliminations from the stack base, not frame
pointer).

This is all fine for most stack frame contents, but it goes wrong in exactly
the same-but-opposite way if we're trying to access items of the stack frame
*above* the gap - and that's what's happening in my test case, because we're
trying to get the address of HARD_FRAME_POINTER, aka the value in $ebp, aka 4
or 8 bytes below the ARG_POINTER (compile-time known constant offset).

So the one or two items above the gap - the frame pointer and the return pc
value (Does this bug affect __builtin_return_address(0) as well, by any chance?
 I haven't checked) - would have to still be eliminated against
HARD_FRAME_POINTER and denied elimination against STACK_POINTER in the case
where there is going to be stack realignment in the prologue.  

And that is presumably the intention of this if clause in ix86_can_eliminate:

  if (stack_realign_fp)
    return ((from == ARG_POINTER_REGNUM
             && to == HARD_FRAME_POINTER_REGNUM)
            || (from == FRAME_POINTER_REGNUM
                && to == STACK_POINTER_REGNUM));
  else [ ... ]

I'll look at why it's not doing what it's supposed to.  One possibility is that
stack_realign_fp isn't becoming true until after the elimination has already
taken place.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (14 preceding siblings ...)
  2009-01-25  6:05 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-25  6:34 ` dave dot korn dot cygwin at gmail dot com
  2009-01-25  6:40 ` dave dot korn dot cygwin at gmail dot com
                   ` (10 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-25  6:34 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #15 from dave dot korn dot cygwin at gmail dot com  2009-01-25 06:33 -------
(In reply to comment #14)
> And that is presumably the intention of this if clause in ix86_can_eliminate:
> 
>   if (stack_realign_fp)
>     return ((from == ARG_POINTER_REGNUM
>              && to == HARD_FRAME_POINTER_REGNUM)
>             || (from == FRAME_POINTER_REGNUM
>                 && to == STACK_POINTER_REGNUM));
>   else [ ... ]
> 

  I just looked twice at that and it seemed odd to me.  Testing this:

   if (stack_realign_fp)
     return ((from == ARG_POINTER_REGNUM
              && to == HARD_FRAME_POINTER_REGNUM)
             || (from == FRAME_POINTER_REGNUM
-                && to == STACK_POINTER_REGNUM));
+                && to == HARD_FRAME_POINTER_REGNUM));


gives me this:

(gdb) disass main
Dump of assembler code for function main:
0x00401070 <main+0>:    push   %ebp
0x00401071 <main+1>:    mov    %esp,%ebp
0x00401073 <main+3>:    and    $0xfffffff0,%esp
0x00401076 <main+6>:    push   %edi
0x00401077 <main+7>:    push   %esi
0x00401078 <main+8>:    push   %ebx
0x00401079 <main+9>:    sub    $0x54,%esp
0x0040107c <main+12>:   movl   $0x4075f0,-0x34(%ebp)
0x00401083 <main+19>:   movl   $0x407bc4,-0x30(%ebp)
0x0040108a <main+26>:   lea    -0x2c(%ebp),%eax
0x0040108d <main+29>:   lea    -0x18(%ebp),%edx
0x00401090 <main+32>:   mov    %edx,(%eax)
0x00401092 <main+34>:   mov    $0x4010e2,%edx
0x00401097 <main+39>:   mov    %edx,0x4(%eax)
0x0040109a <main+42>:   mov    %esp,0x8(%eax)
0x0040109d <main+45>:   lea    -0x4c(%ebp),%eax
0x004010a0 <main+48>:   mov    %eax,(%esp)
0x004010a3 <main+51>:   call   0x405058 <_Unwind_SjLj_Register>

Which works, but now I suspect the address calculations accessing the jmp_buf
are going to be wrong.  Argh.  It looks like we have to know whether there's
an offset in the mem rtx relating to FRAME_POINTER_REGNUM and if it's negative
we have to allow elimination against STACK_POINTER but if its zero or positive
we'd have to only allow elimination against HARD_FRAME_POINTER ... ouch.

Guess the next thing I'll try is simply not allowing elimination against
FRAME_POINTER at all in this context.  That'll mean we can't
-fomit-frame-pointer
in functions which have stack_realign_fp true, but it beats wrong code and
maybe there's a way of avoiding it that I haven't thought of.  Now testing:

   if (stack_realign_fp)
     return ((from == ARG_POINTER_REGNUM
              && to == HARD_FRAME_POINTER_REGNUM)
             || (from == FRAME_POINTER_REGNUM
-                && to == STACK_POINTER_REGNUM));
+                && 0));


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (15 preceding siblings ...)
  2009-01-25  6:34 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-25  6:40 ` dave dot korn dot cygwin at gmail dot com
  2009-01-25  7:47 ` dave dot korn dot cygwin at gmail dot com
                   ` (9 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-25  6:40 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #16 from dave dot korn dot cygwin at gmail dot com  2009-01-25 06:40 -------
./eh.C: In function 'int main()':
./eh.C:11: internal compiler error: in print_reg, at config/i386/i386.c:10466
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

LOL, no, that didn't help.  Will try again tomorrow.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (16 preceding siblings ...)
  2009-01-25  6:40 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-25  7:47 ` dave dot korn dot cygwin at gmail dot com
  2009-01-25 21:36 ` dave dot korn dot cygwin at gmail dot com
                   ` (8 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-25  7:47 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #17 from dave dot korn dot cygwin at gmail dot com  2009-01-25 07:47 -------
And this is what I'll try:

 -- Target Hook: bool TARGET_BUILTIN_SETJMP_FRAME_VALUE ()
     This target hook should return an rtx that is used to store the
     address of the current frame into the built in `setjmp' buffer.
     The default value, `virtual_stack_vars_rtx', is correct for most
     machines.  One reason you may need to define this target hook is if
     `hard_frame_pointer_rtx' is the appropriate value on your machine.

(The first patch fixed all the failing eh testcases, but accessing the local
variables downward through %ebp would mean they'd be misaligned, not starting
down at the bottom of the frame, and differently aligned according to the
dynamic component of the gap, so it would be bound to go wrong in situations
involving vectors or other higher-alignment datatypes.)

If I leave the can_eliminate test alone but define this target hook, I figure
we should still get local vars indexed upward from $esp but will get the frame
pointer indexed down from $ebp, or at least that's how I read the above.  So
hopefully a target hook that overrides the default return value with
hard_frame_pointer_rtx if stack_realign_fp is true and otherwise returns
virtual_stack_vars_rtx like the default might be what we're looking for. 
AFAICT it's not currently defined for i386.

Need sleep nowzzzzzzZZZZZZZ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (17 preceding siblings ...)
  2009-01-25  7:47 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-25 21:36 ` dave dot korn dot cygwin at gmail dot com
  2009-01-25 23:08 ` dave dot korn dot cygwin at gmail dot com
                   ` (7 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-25 21:36 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #18 from dave dot korn dot cygwin at gmail dot com  2009-01-25 21:36 -------
Created an attachment (id=17183)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17183&action=view)
Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE.

Now testing this patch which should fix setjmp calculations of the frame base
pointer without affecting the way ordinary stack local variable slots are
computed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (18 preceding siblings ...)
  2009-01-25 21:36 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-25 23:08 ` dave dot korn dot cygwin at gmail dot com
  2009-01-26 11:49 ` Joey dot ye at intel dot com
                   ` (6 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-25 23:08 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #19 from dave dot korn dot cygwin at gmail dot com  2009-01-25 23:07 -------
Created an attachment (id=17184)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17184&action=view)
Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE *correctly*.

Dur.  Corrected patch for return type thinko.


-- 

dave dot korn dot cygwin at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #17183|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (19 preceding siblings ...)
  2009-01-25 23:08 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-26 11:49 ` Joey dot ye at intel dot com
  2009-01-26 19:03 ` dave dot korn dot cygwin at gmail dot com
                   ` (5 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: Joey dot ye at intel dot com @ 2009-01-26 11:49 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #20 from Joey dot ye at intel dot com  2009-01-26 11:49 -------
(In reply to comment #10)
> This is caused by stack alignment change, revision 138335. Joey and
> Xuepeng will look into it after holiday, Feb. 1.
This must be stack alignment change. Looks we didn't handle stack unwinding on
Cygwin correctly.

Dave, comparing the the EH mechanism in Linux, what's the difference of SjLj EH
in Cygwin? Answer to this question might help solving the problem sooner.

Thanks - Joey


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (20 preceding siblings ...)
  2009-01-26 11:49 ` Joey dot ye at intel dot com
@ 2009-01-26 19:03 ` dave dot korn dot cygwin at gmail dot com
  2009-01-26 22:29 ` hjl dot tools at gmail dot com
                   ` (4 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-01-26 19:03 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #21 from dave dot korn dot cygwin at gmail dot com  2009-01-26 19:03 -------
  Hi Joey, thanks for helping look at this bug.

  If you catch up with all the comments, you'll see that it's not just Cygwin,
SjLj was broken on Linux too; the mechanism works the same way on both, but
only Cygwin uses it as the default EH mechanism, so it doesn't get as much
testing!

  I'm fairly confident I've analyzed the problem correctly and that the patch
I'm testing (attached, and submitted to gcc-patches at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01258.html) is the right solution
to the problem, and my PC is running through all the regression tests now, so
what would help most is if you could just look over my analysis and tell me if
you think I've got the right understanding of your code and the loophole that
caused the bug.

  cheers,
    DaveK


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (21 preceding siblings ...)
  2009-01-26 19:03 ` dave dot korn dot cygwin at gmail dot com
@ 2009-01-26 22:29 ` hjl dot tools at gmail dot com
  2009-01-26 23:39 ` hjl at gcc dot gnu dot org
                   ` (3 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-01-26 22:29 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #22 from hjl dot tools at gmail dot com  2009-01-26 22:29 -------
(In reply to comment #18)
> Created an attachment (id=17183)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17183&action=view) [edit]
> Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE.
> 
> Now testing this patch which should fix setjmp calculations of the frame base
> pointer without affecting the way ordinary stack local variable slots are
> computed.
> 

I investigated C++ failures with --enable-sjlj-exceptions on Linux/Intel64

http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02626.html

All of them are expected. This looks good to me.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ubizjak at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (22 preceding siblings ...)
  2009-01-26 22:29 ` hjl dot tools at gmail dot com
@ 2009-01-26 23:39 ` hjl at gcc dot gnu dot org
  2009-01-31 17:21 ` ktietz at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  26 siblings, 0 replies; 28+ messages in thread
From: hjl at gcc dot gnu dot org @ 2009-01-26 23:39 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #23 from hjl at gcc dot gnu dot org  2009-01-26 23:39 -------
Subject: Bug 38952

Author: hjl
Date: Mon Jan 26 23:39:02 2009
New Revision: 143689

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143689
Log:
2009-01-26  H.J. Lu  <hongjiu.lu@intel.com>

        PR target/38952
        * g++.dg/torture/stackalign/test-unwind.h (main): Also return 0
        if __USING_SJLJ_EXCEPTIONS__ is defined.

        * g++.dg/torture/stackalign/unwind-0.C (foo): Don't define if
        __USING_SJLJ_EXCEPTIONS__ is defined.
        * g++.dg/torture/stackalign/unwind-1.C (foo): Likewise.
        * g++.dg/torture/stackalign/unwind-2.C (foo): Likewise.
        * g++.dg/torture/stackalign/unwind-3.C (foo): Likewise.
        * g++.dg/torture/stackalign/unwind-4.C (foo): Likewise.
        * g++.dg/torture/stackalign/unwind-5.C (foo): Likewise.
        * g++.dg/torture/stackalign/unwind-6.C (foo): Likewise.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h
    trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-0.C
    trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-1.C
    trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-2.C
    trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-3.C
    trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-4.C
    trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-5.C
    trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-6.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (23 preceding siblings ...)
  2009-01-26 23:39 ` hjl at gcc dot gnu dot org
@ 2009-01-31 17:21 ` ktietz at gcc dot gnu dot org
  2009-01-31 17:34 ` hjl at gcc dot gnu dot org
  2009-01-31 17:35 ` hjl dot tools at gmail dot com
  26 siblings, 0 replies; 28+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2009-01-31 17:21 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #24 from ktietz at gcc dot gnu dot org  2009-01-31 17:21 -------
(In reply to comment #21)
>   Hi Joey, thanks for helping look at this bug.
> 
>   If you catch up with all the comments, you'll see that it's not just Cygwin,
> SjLj was broken on Linux too; the mechanism works the same way on both, but
> only Cygwin uses it as the default EH mechanism, so it doesn't get as much
> testing!

I tested it for w64, too. And it solved most EH/SjLj issue we had for this
target. Btw w64 has it as default mechanism, too. The regression runs are
complete and shown no new bug.
So for me this patch is ok.

Cheers,
Kai


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (24 preceding siblings ...)
  2009-01-31 17:21 ` ktietz at gcc dot gnu dot org
@ 2009-01-31 17:34 ` hjl at gcc dot gnu dot org
  2009-01-31 17:35 ` hjl dot tools at gmail dot com
  26 siblings, 0 replies; 28+ messages in thread
From: hjl at gcc dot gnu dot org @ 2009-01-31 17:34 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #25 from hjl at gcc dot gnu dot org  2009-01-31 17:34 -------
Subject: Bug 38952

Author: hjl
Date: Sat Jan 31 17:34:03 2009
New Revision: 143823

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143823
Log:
2009-01-31  Dave Korn  <dave.korn.cygwin@gmail.com>

        PR target/38952
        * config/i386/i386.c (ix86_builtin_setjmp_frame_value): New.
        (TARGET_BUILTIN_SETJMP_FRAME_VALUE): Override default to point
        at it.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [Bug target/38952] [4.4 Regression] EH does not work.
  2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
                   ` (25 preceding siblings ...)
  2009-01-31 17:34 ` hjl at gcc dot gnu dot org
@ 2009-01-31 17:35 ` hjl dot tools at gmail dot com
  26 siblings, 0 replies; 28+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-01-31 17:35 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #26 from hjl dot tools at gmail dot com  2009-01-31 17:34 -------
Fixed.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952


^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2009-01-31 17:35 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-23 23:20 [Bug target/38952] New: [4.4 Regression] EH does not work dave dot korn dot cygwin at gmail dot com
2009-01-23 23:31 ` [Bug target/38952] " dave dot korn dot cygwin at gmail dot com
2009-01-23 23:31 ` dave dot korn dot cygwin at gmail dot com
2009-01-23 23:32 ` dave dot korn dot cygwin at gmail dot com
2009-01-23 23:44 ` dave dot korn dot cygwin at gmail dot com
2009-01-24  0:10 ` dave dot korn dot cygwin at gmail dot com
2009-01-24  1:08 ` dave dot korn dot cygwin at gmail dot com
2009-01-24  6:24 ` dave dot korn dot cygwin at gmail dot com
2009-01-24  8:47 ` rguenth at gcc dot gnu dot org
2009-01-24 17:07 ` ubizjak at gmail dot com
2009-01-24 18:12 ` dave dot korn dot cygwin at gmail dot com
2009-01-24 21:41 ` hjl dot tools at gmail dot com
2009-01-25  5:33 ` dave dot korn dot cygwin at gmail dot com
2009-01-25  5:56 ` dave dot korn dot cygwin at gmail dot com
2009-01-25  5:58 ` dave dot korn dot cygwin at gmail dot com
2009-01-25  6:05 ` dave dot korn dot cygwin at gmail dot com
2009-01-25  6:34 ` dave dot korn dot cygwin at gmail dot com
2009-01-25  6:40 ` dave dot korn dot cygwin at gmail dot com
2009-01-25  7:47 ` dave dot korn dot cygwin at gmail dot com
2009-01-25 21:36 ` dave dot korn dot cygwin at gmail dot com
2009-01-25 23:08 ` dave dot korn dot cygwin at gmail dot com
2009-01-26 11:49 ` Joey dot ye at intel dot com
2009-01-26 19:03 ` dave dot korn dot cygwin at gmail dot com
2009-01-26 22:29 ` hjl dot tools at gmail dot com
2009-01-26 23:39 ` hjl at gcc dot gnu dot org
2009-01-31 17:21 ` ktietz at gcc dot gnu dot org
2009-01-31 17:34 ` hjl at gcc dot gnu dot org
2009-01-31 17:35 ` hjl dot tools at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).