> Setting TREE_OVERFLOW here sounds like the bug.
Well, it's the standard semantics of the middle-end, nothing more:
/* A subroutine of fold_convert_const handling conversions of an
INTEGER_CST to another integer type. */
static tree
fold_convert_const_int_from_int (tree type, tree arg1)
{
tree t;
/* Given an integer constant, make new constant with new type,
appropriately sign-extended or truncated. */
t = build_int_cst_wide (type, TREE_INT_CST_LOW (arg1),
TREE_INT_CST_HIGH (arg1));
t = force_fit_type (t,
/* Don't set the overflow when
converting a pointer */
!POINTER_TYPE_P (TREE_TYPE (arg1)),
(TREE_INT_CST_HIGH (arg1) < 0
&& (TYPE_UNSIGNED (type)
< TYPE_UNSIGNED (TREE_TYPE (arg1))))
| TREE_OVERFLOW (arg1),
TREE_CONSTANT_OVERFLOW (arg1));
return t;
}
/* T is an INT_CST node. OVERFLOWABLE indicates if we are interested
in overflow of the value, when >0 we are only interested in signed
overflow, for <0 we are interested in any overflow. OVERFLOWED
indicates whether overflow has already occurred. CONST_OVERFLOWED
indicates whether constant overflow has already occurred. We force
T's value to be within range of T's type (by setting to 0 or 1 all
the bits outside the type's range). We set TREE_OVERFLOWED if,
OVERFLOWED is nonzero,
or OVERFLOWABLE is >0 and signed overflow occurs
or OVERFLOWABLE is <0 and any overflow occurs
We set TREE_CONSTANT_OVERFLOWED if,
CONST_OVERFLOWED is nonzero
or we set TREE_OVERFLOWED.
We return either the original T, or a copy. */
tree
force_fit_type (tree t, int overflowable,
bool overflowed, bool overflowed_const)
> Or, if some front ends require it for some test cases then it should be made
> language-specific whether conversions of constants set TREE_OVERFLOW in this
> case. (For C, gcc.dg/overflow-warn-*.c should adequately cover the
> diagnostics in this area.)
I'd think it's the other way around: signed overflow should stay the norm and
languages should use a new flag to tell the middle-end that they don't want
it under certain circumstances, modelled on flag_wrapv for Java.
> In the long run, TREE_OVERFLOW should go away and fold should
> provide front ends with information about the sorts of overflow happening
> so front ends can track their own information about what counts as
> overflow in each language.
Yes, that sounds like a good plan.
Thanks for your feedback.
--
Eric Botcazou
