[Bug optimization/14381] New: [3.3/3.4/3.5 Regression] sched2 moving "may throw" instructions into epilogue

["aph at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

g++ is compiling

------------------------------------------------------------------------
typedef struct kkclass;
typedef struct kkclass *jclass;

struct _Jv_VTable
{
  jclass clas;
};

jclass
getClass (void *p)
{
  _Jv_VTable **dt = (_Jv_VTable **) p;
  return (*dt)->clas;
}
------------------------------------------------------------------------

into 

_Z8getClassPv:
.LFB2:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        movl    8(%ebp), %edx
        popl    %ebp
        movl    (%edx), %eax
        movl    (%eax), %eax
        ret
.LFE2:

where, as you can see, the code for the memory access is moved after
the stack adjustment in the epilogue.

This is despite the fact that this code was compiled with
-fnon-call-exceptions and -fno-omit-frame-pointer.

This causes a runtime failure to catch a null pointer exception.
Insns that may trap must not be move into the epilogue, because stack
unwinding when throwing exceptions will not work correctly.

g++ 3.2.2 does this, which is correct:

_Z8getClassPv:
.LFB2:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        movl    8(%ebp), %eax
        movl    (%eax), %eax
        movl    (%eax), %eax
        leave
        ret
.LFE2:

The movement of the popl %ebp instruction seems to be in sched2.

Compiler options used were -O3 -fno-omit-frame-pointer -fnon-call-exceptions.

-- 
           Summary: [3.3/3.4/3.5 Regression] sched2 moving "may throw"
                    instructions into epilogue
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: aph at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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