Re: Problems building GNAT on OS X with top-of-tree

[Geoffrey Keating <geoffk at apple dot com>]

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.