A serious bug on x86 with inline, PIC and omit frame pointer.

[H.J. Lu]

Hi,

There is a serious bug with floating pointer number, PIC, omit frame
pointer and reload. It is very tricky bug. I will try to explain
it. On x86, some FP numbers are allowed as immediate operand. Some
patterns allow

	set (reg: DF X) (const DF 0.0)

With -fomit-frame-pointer, reload replaces bp with sp. For
	
	set (ebp+i) (reg: DF I)

it becomes

	set (esp+j) (reg: DF J)

At that time, current_function_uses_const_pool is 0. Later in reload,

	set (reg: DF X) (const DF 0.0)

is removed and (const DF 0.0) is put in another pattern which doesn't
allow any immediate FP operands. reload then calls force_const_mem ()
to put DF X in memory. In the process, current_function_uses_const_pool
is set 1. The function changes from not use any const via PIC to use
const via PIC. As the result, (esp+j) is no longer (ebp+i). This
generates incorrect asm codes.

I can see 2 approaches to fix it:

1. Disable -fomit-frame-pointer for PIC. Or
2. Delay sp subsititution to the right time.

I saw 2 places where sp subsititution happens. It is where
INITIAL_ELIMINATION_OFFSET is used. Can we reliminate one of
them?


-- 
H.J. Lu (hjl@gnu.org)