On Thu, 10 Oct 2019 at 17:19, Aldy Hernandez wrote:
> It's not that particular commit, but the previous one, but yeah, that's
> all me.
Interesting, bisect really identified r276654.
I think that's what Steve reported as PR 92051 (although his backtrace is
different, but it's also for a differe
It's not that particular commit, but the previous one, but yeah, that's
all me.
(gdb)
#4 0x0145bf44 in value_range_base::lower_bound
(this=0x7fffc360,
pair=0) at /home/cygnus/aldyh/src/gcc/gcc/tree-vrp.c:6148
6148 return wi::to_wide (t);
(gdb)
#5 0x01ccb1d9 in ra
On Mon, 7 Oct 2019 at 13:53, Aldy Hernandez wrote:
>
> > +bool
> > +ipa_vr::nonzero_p (tree expr_type) const
> > +{
> > + if (type == VR_ANTI_RANGE && wi::eq_p (min, 0) && wi::eq_p (max, 0))
> > +return true;
> > +
> > + unsigned prec = TYPE_PRECISION (expr_type);
> > + return (type == VR_
Hi,
On Tue, Oct 08 2019, Marc Glisse wrote:
> On Mon, 7 Oct 2019, Aldy Hernandez wrote:
>>
>> In testing this patch in isolation from the non-zero canonicalization patch,
>> I found one regression due to the fact that:
>>
>> a) As discussed, two non-zero representations currently exist for unsign
On Mon, 7 Oct 2019, Aldy Hernandez wrote:
On 10/4/19 2:09 PM, Jeff Law wrote:
You're right. Easier to refer to the before/after directly. Sometimes
diffs just suck.
OK
jeff
In testing this patch in isolation from the non-zero canonicalization patch,
I found one regression due to the fact
+bool
+ipa_vr::nonzero_p (tree expr_type) const
+{
+ if (type == VR_ANTI_RANGE && wi::eq_p (min, 0) && wi::eq_p (max, 0))
+ return true;
+
+ unsigned prec = TYPE_PRECISION (expr_type);
+ return (type == VR_RANGE
+ && wi::eq_p (min, wi::one (prec))
+ && wi::eq_p (max, wi::m
On 10/4/19 2:09 PM, Jeff Law wrote:
You're right. Easier to refer to the before/after directly. Sometimes
diffs just suck.
OK
jeff
In testing this patch in isolation from the non-zero canonicalization
patch, I found one regression due to the fact that:
a) As discussed, two non-zero repre
On 10/4/19 7:25 AM, Aldy Hernandez wrote:
> I promised I would clean up the VRP/range-ops interface once the patch
> went in. I was afraid of shuffling things too much initially, because I
> was trying to keep to the original structure of
> extract_range_from_*ary_expr. Now that things are in pla
I promised I would clean up the VRP/range-ops interface once the patch
went in. I was afraid of shuffling things too much initially, because I
was trying to keep to the original structure of
extract_range_from_*ary_expr. Now that things are in place, it's easier
to abstract things out, and cl
