This is the mail archive of the
mailing list for the GCC project.
Re: Problems building GNAT on OS X with top-of-tree
- From: Geoffrey Keating <geoffk at apple dot com>
- To: Dale Johannesen <dalej at apple dot com>
- Cc: Geert Bosch <bosch at gnat dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 17 Oct 2002 15:22:40 -0700
- Subject: Re: Problems building GNAT on OS X with top-of-tree
On Thursday, October 17, 2002, at 02:52 PM, Dale Johannesen wrote:
That's a tricky one.
On Thursday, October 17, 2002, at 02:38 PM, Geoffrey Keating wrote:
Hmm. How do you keep the bcl and the following label together through
On Thursday, October 17, 2002, at 02:10 PM, Dale Johannesen wrote:
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.
Actually this looks like it is connected to Geoff's recent patch
which introduced the LSJR label. Geoff, is
current_function_uses_pic_offset_table not getting set anywhere?
That would account for his symptom.
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.
SCHED_GROUP_P used to work on labels, but it doesn't any more, and I
another way to do it. Would a USE of the label work?
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