stdcall function does not return floating point result - bug in reg-stack.c

[Mumit Khan]

On Tue, 9 Mar 1999, Richard Henderson wrote:

> On Sun, Feb 14, 1999 at 07:54:08PM +1100, Tim Josling wrote:
> > I traced the problem down to a bug in reg-stack.c. See 5 for the patch.
> > The problem is that in routine stack_reg_life_analysis it tries to check
> > if the block does a return from the function by checking if the last
> > insn of each block is a jump with return, or for the last block any
> > instruction with return. However in a stdcall function, the return
> > instruction is a PARALLEL with the return under the parallel so the code
> > does not find it ...
> 
> Thanks for the analysis.  I've checked in the following to address 
> the problem.
> 
> 
> r~
> 
> 
>         * reg-stack.c (stack_reg_life_analysis): Use returnjump_p
>         instead of an explicit test for RETURN.
> 

I don't think this fixes the problem. Here's the testcase from my first
bug report regarding this:
  
  double __attribute__((stdcall))
  foo_local1 (double f) {
    return f;
  }

Here's egcs-1.1.2 + Tim Josling fix:
  
	  .file   "stdcall-bug.c"
  gcc2_compiled.:
  ___gnu_compiled_c:
  .text
	  .align 4
  .globl _foo_local1@8
	  .#define    _foo_local1@8;  .scl    2;      .type   32;     .endef
  _foo_local1@8:
	  pushl %ebp
	  movl %esp,%ebp
	  fldl 8(%ebp)
	  movl %ebp,%esp
	  popl %ebp
	  ret $8

Here's CVS 1999-04-10:

	  .file   "stdcall-bug.c"
  gcc2_compiled.:
  ___gnu_compiled_c:
  .text
	  .align 4
  .globl _foo_local1@8
	  .#define    _foo_local1@8;  .scl    2;      .type   32;     .endef
  _foo_local1@8:
	  pushl %ebp
	  movl %esp,%ebp
	  subl $8,%esp
	  fldl 8(%ebp)
	  fstp %st(0)          <<<<<<<<<<<<<<<<<<<<<<< oops.
	  movl %ebp,%esp
	  popl %ebp
	  ret $16

The line marked with '<<<<' shows that FP stack is being popped still.

There's this other bug with stdcall popping the wrong number of items,
but that's a different bug and has been reported already.

Tim's patch does handle this correctly. I had forwarded a copy of his
patch to egcs-bugs. See
  http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00610.html

Regards,
Mumit