[4.1 Committed] PR middle-end/26729: Fold vs. TREE_OVERFLOW

Richard Guenther richard.guenther@gmail.com
Sun May 14 14:07:00 GMT 2006


On 5/14/06, Roger Sayle <roger@eyesopen.com> wrote:
>
> The following patch resolves PR middle-end/26729, which is a P1
> invalid-code regression on the 4.0 and 4.1 branches.  I've spent
> several days attempting to backport the various TREE_OVERFLOW
> clean-ups that have fixed this problem on mainline, to discover
> that this issue has been cured by the cumulative effects of a
> large number of minor improvements.  I eventually gave up trying
> to backport the five or six (at least) patches, including changes
> to integer_zerop, convert_to_pointer, fold_binary, const_binop
> and various places in the C/C++ front-end.  At least, I now have
> a much better appreciation for how small incremental improvements
> can combine to correct significant middle-end design issues.
>
> Instead, I decided to investigate a more direct fix for the
> wrong-code regression described in the PR, and was surprised at
> how simple/safe a fix I found.  This seems like a much better
> short-term workaround that a series of invasive clean-ups for
> the 4.1.2 release.
>
> The problem is that the current code is checking "!integer_zerop"
> to determine whether an integer constant is not zero, which is
> tripping over the odd semantics that overflowed constants are
> treated like NaNs and always test false.  The quick fix is to
> instead test "integer_nonzerop", which inverts the sense of the
> comparison, so now TREE_CONSTANT_OVERFLOW does the right thing.

I don't see how this avoids the problem in general.  In fact,
integer_nonzerop will return false for an integer != 0 with
TREE_CONSTANT_OVERFLOW
set - so it will fail the same way, just for different overflowed constants.

Or am I missing something?

At least it looks like you would only get bogus warnings in this case and
not wrong-code.

Richard.



More information about the Gcc-patches mailing list