Re: A serious -fpic and -fomit-frame-pointer bug in egcs 1.0.3/1.1

[Jeffrey A Law <law at cygnus dot com>]

  In message <m0ymYB0-00026AC@ocean.lucon.org>you write:
  > 
  > In my test case, reg_equiv_memory_loc[i] is 16(%ebp) and (%esp) is
  > returned since eliminate_regs knows 16(%ebp) == (%esp). But it is
  > in the global register allocation. It knows nothing about PIC and
  > ebx.
But eliminate_regs shouldn't need to know about PIC directly -- it just
need to be given proper offsets between the eliminable registers.

  > Now the fucntion prologue/epilogue do
  > 
  > exp__H1Zd_RCt7complex1ZX01_t7complex1ZX01:
  > 	subl $16,%esp
  > 	pushl %ebx
  >         call .L22
  > .L22:
  >         popl %ebx
  >         addl $_GLOBAL_OFFSET_TABLE_+[.-.L22],%ebx
  > 	......
  > 	fstpl (%esp)
  > 	......
  >         popl %ebx
  >         addl $16,%esp
  >         ret $4
  > 
  > Please tell me what happens to ebx. It is because the fucntion
  > prologue/epilogue do something behind the back of the compiler.
  > eliminate_regs doesn't know it. If we disable -fomit-frame-pointer
  > for PIC or change the prologue/epilogue to
Thank you.  You could still have been more explicit about the problem
you're seeing.  Ie the fstpl stores into the same memory location that
will be used to restore ebx in the epilogue.

Had you done this earlier, you would have saved much time for both of us.
Instead you've wasted our time by making suggestions for how to change the
prologue without the background information we need to understand the problem.

I think the real bug is in INITIAL_ELIMINATION_OFFSET and related code, not
in the x86 prologue code.

jeff