Thanks for you help. I will look at some of the changes you suggested. Gyle
-----Original Message----- From: James E Wilson [mailto:[EMAIL PROTECTED] 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
