On 7/14/23 15:37, Richard Biener wrote:
On Fri, 14 Jul 2023, Aldy Hernandez wrote:
I don't know what you're trying to accomplish here, as I haven't been
following the PR, but adding all these helper functions to the ranger header
file seems wrong, especially since there's only one use of them. I see you're
tweaking the irange API, adding helper functions to range-op (which is only
for code dealing with implementing range operators for tree codes), etc etc.
If you need these helper functions, I suggest you put them closer to their
uses (i.e. wherever the match.pd support machinery goes).
Note I suggested the opposite beacuse I thought these kind of helpers
are closer to value-range support than to match.pd.
Oh sorry, I missed that.
But I take away from your answer that there's nothing close in the
value-range machinery that answers the question whether A op B may
overflow?
Not currently.
I vaguely recall we talked about some mechanism for doing range
operations in a wider precision and comparing them with the result of
doing it in the natural precision, and if the results differ, it must
have overflowed.
*hunts down PR*
Comment 23 here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499#c23
Would something like that work?
I would prefer something more general, rather than having to re-invent
every range-op entry to check for overflow.
Aldy
