Re: [PATCH] PR19100: truthvalue_conversion vs. TREE_OVERFLOW (take3)

[Roger Sayle <roger at eyesopen dot com>]

On Sun, 2 Jan 2005, Richard Kenner wrote:
> > >   * fold-const.c (fold_convert_const): Don't set TREE_OVERFLOW when
> > >    converting constants from one integer type to another.
> >
> > Is this OK with the Ada/Java folks?  It certainly makes sense to me
> > from a C/C++ perspective.
>
> It wouldn't be OK with me if it never got set, but my understanding is
> that it still will, but this change just affects *where* it's set.
> Please correct me if I'm wrong, Roger.

The change is that the responsibility for setting this flag, if it's
required, has moved from the middle-end to the language front-ends,
initially only for integer-integer conversions.  fold_convert no longer
sets this field, but each front-end's "convert" function may continue
to do so itself.  Alternatively, the various language parsers can detect
such constant overflow at parse-time using int_fits_type_p instead,
and thereby avoid using TREE_CONSTANT_OVERFLOW entirely.

Previously for example,

	int x = 257;
	char c = (int)x;
	if (c != 1)
	  link_error ();

would fail to be optimized at the tree level as the cast from integer
to char, was considered to have overflowed, even though the semantics
of this truncation are well-defined.

This change starts the ball rolling of restricting TREE*_OVERFLOW as
a "generic" concept, that after lowering into gimple, is subsequently
ignored by the middle-end.  Its current use, other than disabling
compile-time constant folding, is primarily to assist the front-ends
in generating diagnostics.


If there are any ACATs regressions with this patch, I'll be happy to
help investigate, but my understanding is that the Ada front-end has
its own more formal notion of overflow, and doesn't use GCC's trees
during parsing/diagnostic generation.

Roger
--