[Bug optimization/12754] Faulty register allocation under certain circumstances

["wilson at specifixinc dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From wilson at specifixinc dot com  2004-01-16 22:21 -------
Subject: Re:  Faulty register allocation under
	certain circumstances

On Thu, 2004-01-15 at 05:25, giovannibajo at libero dot it wrote:
> Jim, is this a regression? Does it work correctly in 2.95? Can you also attach 
> a preprocessed testcase here so that others may look into it as well? Thanks.

The problem is more complicated than that.

The port in question, or32, does not exist in the FSF tree.  So this bug
is not reproducible against any FSF tree.  However, the problem is
present in the FSF tree, and has been for a long time.

The underlying problem here is that we have many out-of-range array
accesses because of how we use the TEST_HARD_REG_BIT macro.  An obvious
place is in caller-save.c, which has
  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
    for (j = MOVE_MAX_WORDS; j > 0; j--)
      {
	...
        for (k = 0; k < j; k++)
          if (! TEST_HARD_REG_BIT (hard_regs_used, i + k))
If MOVE_MAX_WORDS > 1, then this reads past the end of the
HARD_REG_SET.  However, what happens here depends on how many registers
you have, and which definition of a HARD_REG_SET gets used.  In the vast
majority of cases, nothing bad can happen here, as HARD_REG_SET
naturally has some padding unless you have exactly a multiple of 32
registers.  In the or32 case, they have exactly 32 (or maybe it is 64?)
registers, and thus just going one bit too far takes you the next word. 
This out-of-bounds access can cause various problems.  Most of these
problems are in the register allocator/reload, and that is where the
or32 port fails.

The same code is present in gcc-2.95, and I wouldn't be surprised if
there are examples of this problem as far back as gcc-2.0.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12754