This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: VRP: allow unsigned truncating conversions that will fit

From: Aldy Hernandez <aldyh at redhat dot com>
To: Michael Matz <matz at suse dot de>
Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
Date: Mon, 17 Sep 2018 05:54:12 -0400
Subject: Re: VRP: allow unsigned truncating conversions that will fit
References: <db121669-f55d-749d-2337-7827d1e82338@redhat.com> <alpine.LSU.2.21.1809141222420.7867@wotan.suse.de>



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 wespecial handled anti-ranges of pointers which make no sense when yousplit them up into it's pieces and try to do the math. And it made nosense because I missed that pointers are actually special and we onlycare about null / non-nullness.

Anyways...ignore the noise. I have a much cleaner patch to thetree-vrp.c conversion code that I'm testing now.


Thanks for your input.
Aldy

References:
- VRP: allow unsigned truncating conversions that will fit
  - From: Aldy Hernandez
- Re: VRP: allow unsigned truncating conversions that will fit
  - From: Michael Matz

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]