This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]