> 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)
{
On Fri, 24 Mar 2006, Eric Botcazou wrote:
> > This is of course a definition of C semantics rather than tree semantics,
> > but I believe our trees follow the C semantics here.
>
> Not quite, TREE_OVERFLOW is set on the result. And the C front-end has
> explicit code to unset it:
Setting TREE_
> This is of course a definition of C semantics rather than tree semantics,
> but I believe our trees follow the C semantics here.
Not quite, TREE_OVERFLOW is set on the result. And the C front-end has
explicit code to unset it:
build_c_cast:
/* Ignore any integer overflow caused by the c
On Fri, 24 Mar 2006, Eric Botcazou wrote:
> After the change it is simplified to (int)((unsigned int)j + (unsigned int)o).
> Now take j=0 and o=-1. There is signed-overflow undefinedness neither in the
> original expression nor in the original simplified expression while there is
> in the new s
Hi,
We have a problem with Kazu's following patch:
2005-12-26 Kazu Hirata <[EMAIL PROTECTED]>
PR tree-optimization/25125
* convert.c (convert_to_integer): Don't narrow the type of a
PLUX_EXPR or MINUS_EXPR if !flag_wrapv and the unwidened type
is signed.
that i
