https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the only odd behavior of VRP I see with the new iteration order is:
+Visiting PHI node: # PT = null { D.29657 } (nonlocal)
+__s_16 = PHI <_3(5), __s_19(8)>
+ Argument #0 (5 -> 6 executable)
+ _3: ~[0B, 0B]
+ Argument #1 (8 -> 6 executable)
+ __s_19: [&MEM[(void *)&__PRETTY_FUNCTION__ + 10B], &MEM[(void
*)&__PRETTY_FUNCTION__ + 10B]]
+Meeting
+ ~[0B, 0B]
+and
+ [&MEM[(void *)&__PRETTY_FUNCTION__ + 10B], &MEM[(void *)&__PRETTY_FUNCTION__
+ 10B]]
+to
+ ~[0B, 0B]
+Found new range for __s_16: [_3, -1B]
so how did we end up adjusting ~[0B, 0B] to [_3, -1B] (when we usually
prefer NULL/non-NULL for pointers)?
Then we are appearantly re-visiting the PHI node:
+Visiting PHI node: # PT = null { D.29657 } (nonlocal)
+__s_16 = PHI <_3(5), __s_19(8)>
+ Argument #0 (5 -> 6 executable)
+ _3: ~[0B, 0B]
+ Argument #1 (8 -> 6 executable)
+ __s_19: ~[0B, 0B]
+Meeting
+ ~[0B, 0B]
+and
+ ~[0B, 0B]
+to
+ ~[0B, 0B]
+
but not finding a new range (so we indeed prefer the "old" one somehow).
We first discover this via
+Visiting PHI node: # PT = null { D.29657 } (nonlocal)
+__s_16 = PHI <_3(5), __s_19(8)>
+ Argument #0 (5 -> 6 executable)
+ _3: ~[0B, 0B]
+ Argument #1 (8 -> 6 executable)
+ __s_19: [&MEM[(void *)&__PRETTY_FUNCTION__ + 10B], &MEM[(void
*)&__PRETTY_FUNCTION__ + 10B]]
+Meeting
+ ~[0B, 0B]
+and
+ [&MEM[(void *)&__PRETTY_FUNCTION__ + 10B], &MEM[(void *)&__PRETTY_FUNCTION__
+ 10B]]
+to
+ ~[0B, 0B]
+Found new range for __s_16: [_3, -1B]
