On Thu, Oct 17, 2019 at 03:15:28AM -0400, Aldy Hernandez wrote:
> On 10/16/19 3:46 AM, Jakub Jelinek wrote:
> > On Wed, Oct 16, 2019 at 03:38:38AM -0400, Aldy Hernandez wrote:
> > > Would you take care of this, or shall I?
> >
> > Will defer to you, I have quite a lot of stuff on my plate ATM.
> >
On 10/16/19 3:46 AM, Jakub Jelinek wrote:
On Wed, Oct 16, 2019 at 03:38:38AM -0400, Aldy Hernandez wrote:
Would you take care of this, or shall I?
Will defer to you, I have quite a lot of stuff on my plate ATM.
Jakub
No problem. Thanks for your analysis though.
The attached patch
On Wed, Oct 16, 2019 at 03:38:38AM -0400, Aldy Hernandez wrote:
> Would you take care of this, or shall I?
Will defer to you, I have quite a lot of stuff on my plate ATM.
Jakub
On 10/15/19 2:16 PM, Jakub Jelinek wrote:
On Tue, Oct 15, 2019 at 08:35:07AM -0400, Aldy Hernandez wrote:
I'm seeing this on 32-bit i386-pc-solaris2.11 and sparc-sun-solaris2.11,
with more reports for armv8l, pru, and s390x.
Comparing the dumps between 64 and 32-bit, I see
-_1: int * [1B, -1B]
On Tue, Oct 15, 2019 at 08:35:07AM -0400, Aldy Hernandez wrote:
> > I'm seeing this on 32-bit i386-pc-solaris2.11 and sparc-sun-solaris2.11,
> > with more reports for armv8l, pru, and s390x.
> >
> > Comparing the dumps between 64 and 32-bit, I see
> >
> > -_1: int * [1B, -1B]
> > +_1: int * [1B,
Hi Aldy,
Rainer Orth wrote:
>>
>> On 10/15/19 7:58 AM, Rainer Orth wrote:
>>> Hi Aldy,
>>>
>> ~[0,0] has been the accepted way for a long time, I'd really prefer to
>> keep that (for now).
> It has. Very true. But I don't necessarily think that means we should
> be introducing
Hi Aldy,
> On 10/15/19 7:58 AM, Rainer Orth wrote:
>> Hi Aldy,
>>
> ~[0,0] has been the accepted way for a long time, I'd really prefer to
> keep that (for now).
It has. Very true. But I don't necessarily think that means we should
be introducing even more of 'em.
>> [...]
>>>
On 10/15/19 7:58 AM, Rainer Orth wrote:
Hi Aldy,
~[0,0] has been the accepted way for a long time, I'd really prefer to
keep that (for now).
It has. Very true. But I don't necessarily think that means we should
be introducing even more of 'em.
[...]
Happily, normalizing into ~0 for sign
Hi Aldy,
>>> ~[0,0] has been the accepted way for a long time, I'd really prefer to
>>> keep that (for now).
>> It has. Very true. But I don't necessarily think that means we should
>> be introducing even more of 'em.
[...]
> Happily, normalizing into ~0 for signed and [1,MAX] for unsigned,
> si
On 10/7/19 6:28 AM, Aldy Hernandez wrote:
>
> Fair enough. I guess I don't care what we settle on, inasmuch as we
> canonicalize into one true value. For some reason, I thought the above
> nonzero would cause you to cringe, I guess not :).
:-) Takes more than that these days.. And just to rei
On 10/4/19 1:17 PM, Jeff Law wrote:
On 10/4/19 10:14 AM, Aldy Hernandez wrote:
On 10/4/19 12:02 PM, Jeff Law wrote:
On 10/4/19 9:49 AM, Aldy Hernandez wrote:
On 10/4/19 11:38 AM, Jeff Law wrote:
On 10/4/19 6:59 AM, Aldy Hernandez wrote:
When I did the value_range canonicalization work, I
On 10/4/19 10:14 AM, Aldy Hernandez wrote:
>
>
> On 10/4/19 12:02 PM, Jeff Law wrote:
>> On 10/4/19 9:49 AM, Aldy Hernandez wrote:
>>>
>>>
>>> On 10/4/19 11:38 AM, Jeff Law wrote:
On 10/4/19 6:59 AM, Aldy Hernandez wrote:
> When I did the value_range canonicalization work, I noticed that
On October 4, 2019 5:38:09 PM GMT+02:00, Jeff Law wrote:
>On 10/4/19 6:59 AM, Aldy Hernandez wrote:
>> When I did the value_range canonicalization work, I noticed that an
>> unsigned [1,MAX] and an ~[0,0] could be two different representations
>> for the same thing. I didn't address the problem t
On 10/4/19 12:02 PM, Jeff Law wrote:
On 10/4/19 9:49 AM, Aldy Hernandez wrote:
On 10/4/19 11:38 AM, Jeff Law wrote:
On 10/4/19 6:59 AM, Aldy Hernandez wrote:
When I did the value_range canonicalization work, I noticed that an
unsigned [1,MAX] and an ~[0,0] could be two different represent
On 10/4/19 9:49 AM, Aldy Hernandez wrote:
>
>
> On 10/4/19 11:38 AM, Jeff Law wrote:
>> On 10/4/19 6:59 AM, Aldy Hernandez wrote:
>>> When I did the value_range canonicalization work, I noticed that an
>>> unsigned [1,MAX] and an ~[0,0] could be two different representations
>>> for the same thin
On 10/4/19 11:38 AM, Jeff Law wrote:
On 10/4/19 6:59 AM, Aldy Hernandez wrote:
When I did the value_range canonicalization work, I noticed that an
unsigned [1,MAX] and an ~[0,0] could be two different representations
for the same thing. I didn't address the problem then because callers
to ra
On 10/4/19 6:59 AM, Aldy Hernandez wrote:
> When I did the value_range canonicalization work, I noticed that an
> unsigned [1,MAX] and an ~[0,0] could be two different representations
> for the same thing. I didn't address the problem then because callers
> to ranges_from_anti_range() would go int
When I did the value_range canonicalization work, I noticed that an
unsigned [1,MAX] and an ~[0,0] could be two different representations
for the same thing. I didn't address the problem then because callers
to ranges_from_anti_range() would go into an infinite loop trying to
extract ~[0,0] in
18 matches
Mail list logo