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

[wilson at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


wilson at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-10-29 08:31:05
               date|                            |


------- Additional Comments From wilson at gcc dot gnu dot org  2003-10-29 08:30 -------
I have reproduced the problem.  The instructions for checking out the sources
are a little incomplete, but it wasn't hard to get the info I needed from the
web site at www.opencodes.org.

I have 3 ideas for how to fix this, none of which I am completely happy with.
1) Make HARD_REG_SET slightly bigger, so we can't accidentally read past the end
of it.  I suspect this will have a small effect on gcc compile time performance
for most targets.  This isn't foolproof, since we have to guess at how much
bigger to make HARD_REG_SET, and we might guess wrong.
2) Add a check for out of range registers in TEST_HARD_REG_BIT.  This is
guaranteed to work, but will have the biggest effect on gcc compile time.
3) Add checks for out of range registers at all call sites that might scan past
FIRST_PSEUDO_REGISTER accidentally.  This assumes we can identify all such
places, and avoid adding more in the future.  So this is the least safe
solution, but should have the least affect on gcc compile time.  The unsafe call
sites all use similar idioms, so it is possible to identify them.  See for
instance setup_save_areas in caller-save.c, and find_regs in global.c.

An advantage of solution 3 is that it also avoids other out-of-range accesses. 
setup_save_areas in caller-save.c also has out-of-bounds array accesses for
regno_save_mem and regno_save_mode for instance.

So for now I am investigating solution 3.

I believe that there is no problem with CLEAR_HARD_REG_BIT and SET_HARD_REG_BIT.
 Both of these are used only when we either already have a valid register, or we
have a register that passed a previous TEST_HARD_REG_BIT test, and therefore we
should never get out-of-range registers in the CLEAR and SET macros if the TEST
macro is used correctly.