https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
Andrew Macleod <amacleod at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #48008|0 |1
is obsolete| |
--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 49601
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49601&action=edit
patch to discard invalid ranges
We can do as Jakub suggests and mask out invalid ranges, processing only whats
left.
We can get the first test case if we tweak it into the third one I have added.
The first one will require the next release of ranger:
<bb 2> :
_1 = arg_4(D) + 4294967293;
a_5 = (int) _1;
x_7 = 1 << arg_4(D);
if (a_5 < 0)
goto <bb 3>; [INV]
else
goto <bb 4>; [INV]
2->3 (T) _1 : unsigned int [2147483648, +INF]
2->3 (T) arg_4(D) : unsigned int [0, 2][2147483651, +INF]
2->3 (T) a_5 : int [-INF, -1]
2->4 (F) _1 : unsigned int [0, 2147483647]
2->4 (F) arg_4(D) : unsigned int [3, 2147483650]
2->4 (F) a_5 : int [0, +INF]
=========== BB 3 ============
x_7 int VARYING
<bb 3> :
b_8 = (unsigned int) x_7;
Ranger currently doesn't mark ssa-names which are not in the calculation chain
of the outgoing edge.. x_7 has not direct effect on the edge, but rather it
happens to use a value which later changes on the edge.
These secondary effect re-calculations are slated for the next release of
ranger. I moved the x_7 into the following block in the third testcase, which
demonstrates that the value can be recalculated properly with the available
information.
