Re: Type conversion and addition

[Eric Botcazou <ebotcazou at adacore dot com>]

> 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