Checking out PR4483 (constant overflow on PPC, problems compiling Linux kernel)

Geoff Keating geoffk@geoffk.org
Fri Nov 30 04:54:00 GMT 2001


Corey Minyard <minyard@acm.org> writes:

> This is a multi-part message in MIME format.
> --------------060503040000080308090305
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> I tried to compile the Linux kernel on PowerPC, and I ran into a problem 
> someone previously reports (PR4483, 
> http://gcc.gnu.org/ml/gcc-prs/2001-10/msg00105.html ).  I've played 
> around with it some, and it looks like a constant is overflowing in the 
> gcse stage.  The PR has a testcase in it.
> 
> In the situation, an INSN references two other registers that are 
> constants (one is 0xffffffff80000000, the other is 42) and subtracts the 
> second from the first (MINUS code).  In validate_replace_rtx_1 
> (recog.c), it replaces the registers with constants, then adds them. 
>  This results in a constant 0xffffffff7fffffd6, which is obviously now 
> too negative to fit into an SI register.  The original constant was 
> positive (0x80000000UL in the source).  Since constants don't have 
> modes, the addition code doesn't handle this (and it doesn't look like 
> it cares, anyway).
> 
> I have attached a patch that adds a PowerPC production to truncate a 
> constant that is too large that goes into a register.  However, I'm not 
> sure if this is the right way to handle this, but it at least works 
> around the problem.  The  main production that handles this won't work 
> because it checks for constant overflows.

Yes, this is not the right way.  The problem is that something in GCSE
is not properly sign-extending the result when it folds

(insn 72 112 73 (set (reg:SI 130)
        (minus:SI (reg:SI 128)
            (reg/v:SI 125))) 44 {*rs6000.md:1692} (nil)
    (nil))

(it can fold it because it knows the values of REGs 128 and 125).  If
you're interested in debugging this further, the next step would be to
find the place in GCC where the (const_int 0xffffffff7fffffd6) is created,
and work out why it's not getting truncated.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>



More information about the Gcc-patches mailing list