On 09/14/2018 08:33 AM, Michael Matz wrote:
Hi,
On Fri, 14 Sep 2018, Aldy Hernandez wrote:
Is there a subtle reason why we're avoiding unsigned truncating conversions of
the form:
[X, +INF]
If the X fits in the new type, why can't we just build [X, +INF] in the new
type?
But (uin8_t)((unsigned)[255,+INF]) aka ([255,+INF] & 255) isn't [255,+INF]
but rather [0,+INF]. What am I missing? Even considering that the caller
must canonicalize, I don't see how that would transform [255,+INF] (which
is a normal range) into [0,+INF].
Ughh, yes. You're absolutely right. I was getting confused with how we
special handled anti-ranges of pointers which make no sense when you
split them up into it's pieces and try to do the math. And it made no
sense because I missed that pointers are actually special and we only
care about null / non-nullness.
Anyways...ignore the noise. I have a much cleaner patch to the
tree-vrp.c conversion code that I'm testing now.
Thanks for your input.
Aldy