Leaf optimization/call stuff?

[Mark Mitchell]

Here's a test-case, distilled from a recent bug report, that looks
to me like something is going wrong with our attempts at aligning the
stack.  The test case is attached and is checked in as
g++.other/static4.C.  It fails on x86-linux-gnu.

  struct A {
	  A(int, int);
  };
  A::A(int, int) {}
  static A _A(0);
  int main() { return(0); }

Compile with -O2 and see a segfault at run-time.

The problem *seems* to my untrained eye to be in this function:

  _GLOBAL_.I.__1Aii:
  .LFB3:
	  pushl %ebp
  .LCFI4:
	  movl %esp,%ebp
  .LCFI5:
	  subl $8,%esp
  .LCFI6:
	  addl $16,%esp
	  addl $-4,%esp
	  pushl $0
	  pushl $0
	  pushl $_A
  .LCFI7:
	  call __1Aii
	  movl %ebp,%esp
	  popl %ebp
	  ret

Note that here we subtract 8, add 16, and subtract 4 from the
oft-moved stack pointer.  To me, that looks the same as add 4.  (BTW,
these aren't simplified to `addl 4' even with -O2, which also seems
odd.)  But, on x86 aren't we supposed to be subtracting from the stack
pointer to create a stack frame, not adding to it?  So isn't the first
`pushl' pushing into some spot it shouldn't?

Feel free to correct me if I don't know how to read assembly.  If I'm
right, though, I'd much appreciate it if someone could look into this
problem, along with the possibly related problem I reported yesterday
whereby our DWARF2 debug info is bad.  (This is g++.eh/unwind1.C,
again on x86-linux-gnu.)

Right now, we're kinda hosed in C++-land by these things.  I'd *love*
it if these turned out to somehow be my fault, because then I could
fix them, but I think they're not.  If you could invesitgate and let
me know, I'd much appreciate it.

-- 
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com