Re: [PATCH] integer overflow checking builtins in constant expressions

[Martin Sebor <msebor at gmail dot com>]

On 05/17/2016 12:54 PM, Jason Merrill wrote:
> On 05/01/2016 12:39 PM, Martin Sebor wrote:
> > +  if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) ==
> > INTEGER_CST)
> > +    {
> > +      if (tree result = size_binop_loc (EXPR_LOC_OR_LOC (t,
> > input_location),
> > +                    opcode, arg0, arg1))
> > +    {
> > +      if (TREE_OVERFLOW (result))
> > +        {
> > +          /* Reset TREE_OVERFLOW to avoid warnings for the overflow.  */
> > +          TREE_OVERFLOW (result) = 0;
> > +
> > +          return build_complex (TREE_TYPE (t), result,
> > integer_one_node);
> > +        }
> > +
> > +      return build_complex (TREE_TYPE (t), result, integer_zero_node);
> > +    }
> > +    }
>
> Should this be in the middle-end somewhere, perhaps shared with
> fold_builtin_arith_overflow?  I notice that the comment for that
> function says that it folds into normal arithmetic if the operation can
> never overflow, but I don't see any code that would accomplish that.

I'm not quite sure where to move this hunk so that it could be
shared or with what.

With the patch, fold_builtin_arith_overflow returns the overflow
bit alone when the last argument is null.  Otherwise it returns
a complex number with both the overflow bit and the result.  Here
we need both parts of the result.  I suppose I could factor out
the call to size_binop_loc into its own function, have it return
the overflow bit, and set a by-reference argument to the arithmetic
result so that it could be built into a complex result here but
that doesn't seem like it would gain us much, if anything.

Do you have any suggestions?

Martin