This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix macho_correct_pic operands
- From: Geert Bosch <bosch at gnat dot com>
- To: Geoffrey Keating <gkeating at apple dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 18 Mar 2003 17:04:54 -0500
- Subject: Re: Fix macho_correct_pic operands
Geoff, while you're in macho pic mode, would there be any
chance you could look at the Ada bootstrap problem I reported
last october? I now filed this as bootstrap/10129 with links to
the original message http://gcc.gnu.org/ml/gcc/2002-10/msg00901.html
where I mentioned the problem, your patch that triggered it,
and your analysis in http://gcc.gnu.org/ml/gcc/2002-10/msg01071.html:
On Thursday, October 17, 2002, at 02:52 PM, Dale Johannesen wrote:
On Thursday, October 17, 2002, at 02:38 PM, Geoffrey Keating wrote:
On Thursday, October 17, 2002, at 02:10 PM, Dale Johannesen wrote:
Actually this looks like it is connected to Geoff's recent patch
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01259.html
which introduced the LSJR label. Geoff, is
current_function_uses_pic_offset_table not getting set anywhere?
That would account for his symptom.
It is supposed to be set by machopic_function_base_name, which is
called to generate the label. Looking at the code, my suspicion is
that the original load_macho_picbase pattern is getting deleted by
flow because it appears dead, but that also deletes the label that
the macho_correct_pic needs.
If so, the solution is to use a real CODE_LABEL instead of having the
label inside load_macho_picbase, but this will be a complex change.
Hmm. How do you keep the bcl and the following label together through
the scheduler?
SCHED_GROUP_P used to work on labels, but it doesn't any more, and I
never found
another way to do it. Would a USE of the label work?
That's a tricky one.
What you really want to do is say
(parallel [(set (pc) (label_ref (code_label ...)))
(set (reg:SI lr) (label_ref (code_label ...)))])
because that accurately describes what load_macho_picbase really does,
but reload can't deal with that, it doesn't like jump instructions that
have output reloads.
Since we can't do the nice thing, probably a good second-best is, for
functions that need this restore (perhaps those that have
current_function_has_nonlocal_label set) to ensure that the original
load_macho_picbase never gets deleted by adding a suitable USE of the
PIC register.