On 4/2/06, Roger Sayle <[EMAIL PROTECTED]> 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.
