[PATCH] Re: Checking out PR4483 (constant overflow on PPC, problems compiling Linux kernel)

[Corey Minyard]

Richard Kenner wrote:

>    The problem has to do with certain calculations overflowing and
>    producing constants that would not fit into the mode of the operation
>
>Well, my view is that such an overflow is a prima facia bug.  Why are we
>producing constants that overflow?  Now, if it's the case here that the
>overflow is due to simulating a user-level overflow, that's another issue,
>but when I look at the PR, I don't see such.
>
The PR didn't go into very much analysis.  The actual constants the 
front-end produces are
correct; it's the simulation of the user-level overflow that's the problem.

In one situation, we have an expression (0x80000000UL - u).  "u" get 
substituted with 42
though inlining.  This ends up with an RTL of:
   (plus:SI (CONST_INT 0xffffffff80000000) (CONST_INT 0xffffffffffffffd6))
whose first and second operands are passed in to plus_constant (this is 
the situation in recog.c).
Since plus_constant has no mode to work with, it does the calculation in 
DImode, which
produces (CONST_INT 0xffffffff7fffffd6), which will no longer fit into a 
32-bit value.

In the second situation (in simplify-rtx.c), we get an RTL of:
  (minus:SI (REG:SI xxx) (CONST_INT 0xffffffff80000000))
The transformation converts the minus to a plus and does a negation of 
the constant.  But
if you negate this constant, it overflows a 32-bit integer.

I can generate RTL, if you like, or if you need more detail elsewhere I 
can supply it.

-Corey