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