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]
Other format: [Raw text]

Re: possible bug in global allocation phase


On Thu, 2003-10-23 at 12:52, Heiko Panther wrote:
> 1. I could send in a patch with the changes that got my stuff working

I can't say for sure since I haven't seen them yet, but your patches do
not appear to be safe.  The problem here is that the TEST_HARD_REG_BIT
macro invokes undefined behavior.  If HARD_REG_SET is a scalar, we get
an out-of-range shift.  If HARD_REG_SET is an array, we get an
out-of-bounds array access.  Inverting the sense of the tests does not
solve this problem.  We still have undefined behavior.  Thus we either
have to check for out-of-range registers inside the TEST_HARD_REG_BIT
macro itself, or avoid passing out-of-range registers in the callers. 
The former is safer, the latter is faster.

I believe that the only place where we have out-of-range registers is
when we are checking regs with large modes that span multiple hard
regs.  This idiom is fairly easy to check for, and thus I think the
latter option is practical.

If we really want to be safer, we could add some enable-checking tests
to TEST_HARD_REG_BIT to check for the out-of-range register case.

> 2. You could implement your approach.

I am hoping to find time soon to do that.

My patch can be made a bit more efficient by moving the extra tests out
of the loop.  The extra tests are necessary for correctness; I see no
way to avoid a few extra cycles here.

> 3. I could just create a bug report.

I think this would be a useful thing to do so that the problem is
tracked.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


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