RE: Global Reload Problem

[Gyle Yearsley <gyearsley at zilog dot com>]

Thanks for you help. I will look at some of the changes you suggested.

Gyle


-----Original Message-----
From: James E Wilson [mailto:wilson@specifixinc.com] 
Sent: Wednesday, February 09, 2005 2:00 PM
To: Gyle Yearsley
Cc: gcc@gcc.gnu.org
Subject: RE: Global Reload Problem


On Thu, 2005-02-03 at 10:22, Gyle Yearsley wrote:
> I believe the seg fault is happening in the second TEST_HARD_REG_BIT since
> the regno(0)+n(-1) for regno = 0 is -1. The HARD_REGNO_MODE_OK is a c
> function and not a macro.

"i << -1" is undefined, and for some hosts, may result in a seg fault. 
Similarly, if HARD_REG_SET is an array, then indexing into it with an
offset of -1 gives an invalid out-of-bounds access, which can fail in
various ways.

There is a known problem with TEST_HARD_REG_BIT in that we can get
failures (out-of-bounds access, undefined shift) if regno+n is larger
than the number of hard registers.  I don't recall seeing a similar bug
reported when regno+n < 0.  See PR 12754.

I'd suggest filing a bug report for this problem, and making it depend
on PR 12754.  Fixing this is likely to be complicated, as these macros
are used in lots of different places in a number of different ways.

You might be able to workaround the problem by saying that register 0
can't hold an HI-mode value, to try to avoid creating the HImode subreg
in the first place.  It isn't obvious whether that helps though.  You
might need to reorder tests to put HARD_REGNO_MODE_OK checks before
TEST_HARD_REG_BIT checks.

For an additional laugh, check out the for loop in find_valid_class
      for (regno = 0; regno < FIRST_PSEUDO_REGISTER - n && ! bad;
regno++)
and consider what happens when n is negative.  Oops.  I wonder how
places there are that do this...
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com