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: ARM: Correct handling of CODE_LABELs in TLS support


On Mon, Nov 14, 2005 at 04:49:53PM +0000, Richard Earnshaw wrote:
> On Mon, 2005-11-14 at 16:40, Daniel Jacobowitz wrote:
> > There are a couple of places in both the existing PIC initialization, and
> > the new TLS code, where the ARM backend creates dummy LABEL_REFs for things
> > which will get forced to the constant pool and referenced, but the
> > CODE_LABEL is never emitted in the instruction stream.  Instead the label is
> > printed as part of the pc-relative calculation which it must be attached to.
> > 
> > One place that breaks down is in crossjumping; rtx_renumbered_equal_p uses
> > next_real_insn to compare two CODE_LABELs, and un-emitted CODE_LABELs all
> > have the same result (NULL_RTX).  So cross-jumping may combine two
> > incompatible instructions, leaving one of the setup instructions referring
> > to a now-deleted label.  This wasn't a problem for the PIC setup, since
> > there's only one of those per function to start with, but it's a problem for
> > TLS.
> > 
> 
> Hmm, this sounds similar to what is happening in PR-15231 (though that
> was non-pic).  I wonder if it's related -- I never did get to the bottom
> of that problem.

It does look like the same problem, though I don't see how this patch
could fix it.  Certainly the symptoms were the same: something was
deleting the pc-relative add, but the constant pool load preceeding it
was still considered live, so the minipool entry was emitted even
though it was no longer referenced.  Which means an unreferenced label.

Thanks, checked in.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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