This is the mail archive of the gcc-bugs@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]

Re: egcs-19980803 (pre-1.1) solaris regressions



  In message <199808181650.JAA29001@dm.cobaltmicro.com>you write:
  > Actually I think it is a combination of bugs, 2 I can see at the
  > moment:
  > 
  > 1) As you mention reorg is broken.  I walked through the example and
  >    it does not find the basic blocks correctly and does not scan
  >    the necessary instructions to find resource usages while scheduling
  >    a delay instrution.  In this case, it does not set the ANNUL bit in
  >    the instruction because of lost information.
Yea.  This is nightmare code to deal with too.  The ability to clean
up this mess is one of the big wins if we recompute live/dead and
block start/end info after reload.

  > 2) Secondarily, I found another peculiar property of PIC during reload
  >    on Sparc.  When the reload insns are output, a reference to the
  >    PIC register (%l7) is created but I can't for the life of me figure
  >    out where the compiler accounts for this fact in the register
  >    tables in any way shape or form.  What gives?
Hmm.  Presumably the usage of the PIC register happens behind reload's
back.  ie, the pic reg is not a spill register and it's not already
mentioned elsewhere in the function before reload?

In that case I think it is the backend's responsibility to note that
the PIC register is in-use.

Note that having the PIC register come live behind reload's back can
lead to some problems.  We've run into this on the PA, m68k, x86 and ppc.

Hopefully your PIC register is fixed and not a pseudo?  And hopefully,
you always allocate a stack slot for it when -fpic/-fPIC?



targ




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