This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: A serious -fpic and -fomit-frame-pointer bug in egcs 1.0.3/1.1
- To: hjl at lucon dot org (H.J. Lu)
- Subject: Re: A serious -fpic and -fomit-frame-pointer bug in egcs 1.0.3/1.1
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 08 Jul 1998 01:28:26 -0600
- cc: egcs-bugs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <m0ytZI0-000266C@ocean.lucon.org>you write:
> > If something changes after the big while loop in reload1.c::reload,
> > then that's a problem. But I get the feeling your call to
>
> Yes. It does happen.
It == ?? Please be precise -- "what" does happen.
On x86, some FP constants are allowed as an
> operand in some pattern. See CONST_DOUBLE_OK_FOR_LETTER_P. The problem
> is not all patterns take it. During the reload, a pattern, which allows
> a FP constant, is changed and a pattern, which has to take a memory
> operand, now has a FP constant as operand. See what find_reloads
> in reload.c does in this case:
The code in question is part of find_reloads.
It looks like find_reloads is called from within the big while loop
in reload1.c::reload and outside the loop via a call inside
reload_as_needed.
Of course, you could have told me that and saved me the time to go
wandering around reload trying to figure out what point you were
trying to make.
> As you can see, force_const_mem is called.
And this can cause a function which used to not use PIC to use PIC
which changes the offsets due to the definition of INITIAL_ELIMINATION_OFFSET
right?
If so, the bug is clearly in INITIAL_ELIMINATION_OFFSET.
jeff