Re: [RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 4/2/06, Roger Sayle <roger@eyesopen.com> wrote:
>
> Following some of my recent middle-end clean-ups, I believe that
> we're now at the point where incrementally the middle-end can
> start ignoring the TREE_OVERFLOW bits on constant tree nodes.
> As a step in this direction, the patch below removes the
> TREE_CONSTANT_OVERFLOW checks from integer_zerop, integer_onep,
> and friends in tree.c.  This patch bootstraps and regression
> tests on i686-pc-linux-gnu (including Ada) with no new failures.
>
> The major true user of TREE_CONSTANT_OVERFLOW is the C front-end,
> which doesn't use any of these functions to determine whether it
> should issue a diagnostic when an overflowed integer is used in
> a context requiring a compile-time constant.
>
> Over the years, this overflow testing in the middle-end has caused
> numerous bugs, the most recent being last week's PR26859.  Removing
> this test cleans up the semantics of integer constants a little.
> In the unlikely event that any problems are discovered, by routines
> relying on these functions testing checking for overflow, the trivial
> fix is to rewrite the callers as:
>
>         if (integer_zerop (t)
>             && ! TREE_CONSTANT_OVERFLOW (t))
>           ...
>
>
> There is now a stronger requirement on fold-const.c and friends that
> it now be extra careful preserving TREE_CONSTANT_OVERFLOW for the
> C front-end.  Optimizations such as "0 * x" -> "0" where we
> test for zero using integer_zerop, have been checked to make sure
> that we return the original zero, which the overflow bits set as
> appropriate.
>
> Once this patch is approved there's some follow-up clean-up that
> can be done, removing the duplication in the many "local" functions
> that test for zero but couldn't previously use integer_zerop due
> to the historical overflow semantics.
>
>
> Presumably everyone agrees that this evolution is a good thing.
> The contention is whether everyone agrees that we're ready for
> such a step.  Is such a transition safe for stage 3 mainline,
> and/or would front-ends prefer some time to double check that
> this won't cause problems on conformance tests not part of GCC's
> testsuite.
>
> Thoughts?

That fixes my problem that I have with PR27018.

Richard.