On 11/11/20 10:45 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 11/10/20 3:35 PM, Richard Sandiford wrote:
Aldy Hernandez writes:
p.s. If POLY_INT_CST_P are not supported in ranges, but are
INTEGRAL_TYPE_P, perhaps we should also tweak irange::supports_type_p so
it doesn't leak in
Aldy Hernandez writes:
> On 11/10/20 3:35 PM, Richard Sandiford wrote:
>> Aldy Hernandez writes:
(actually I can see 3245 ICEs on aarch64)
Can you fix it?
>>>
>>> Sure can.
>>>
>>> Richard, I seem to have incorrectly removed the early exit for varying,
>>> and that affected the cha
On 11/10/20 3:35 PM, Richard Sandiford wrote:
Aldy Hernandez writes:
(actually I can see 3245 ICEs on aarch64)
Can you fix it?
Sure can.
Richard, I seem to have incorrectly removed the early exit for varying,
and that affected the changes you made for poly ints. Is there any
reason we c
Aldy Hernandez writes:
>> (actually I can see 3245 ICEs on aarch64)
>>
>> Can you fix it?
>
> Sure can.
>
> Richard, I seem to have incorrectly removed the early exit for varying,
> and that affected the changes you made for poly ints. Is there any
> reason we can't just exit and set varying w
(actually I can see 3245 ICEs on aarch64)
Can you fix it?
Sure can.
Richard, I seem to have incorrectly removed the early exit for varying,
and that affected the changes you made for poly ints. Is there any
reason we can't just exit and set varying without checking for kind !=
VR_VARYING?
This breaks aarch64.
spawn -ignore SIGHUP /opt/gcc/test/Build/gcc/xgcc -B/opt/gcc/test/Build/gcc/
-mabi=lp64 -fdiagnostics-plain-output -march=armv8.2-a+sve -O3 --save-temps
-ffat-lto-objects -fno-ident -c -o abs_1.o
/opt/gcc/test/gcc/testsuite/gcc.target/aarch64/sve/abs_1.c
during GIMPLE pass:
Hi,
On Mon, 9 Nov 2020 at 15:43, Aldy Hernandez via Gcc-patches
wrote:
>
> [This is actually part of a larger patch that actually changes
> behavior, but I thought I'd commit the non-invasive cleanups first
> which will simplify the upcoming work.]
>
> irange::set was doing more work than it shou
[This is actually part of a larger patch that actually changes
behavior, but I thought I'd commit the non-invasive cleanups first
which will simplify the upcoming work.]
irange::set was doing more work than it should for legacy ranges.
I cleaned up various unnecessary calls to swap_out_of_order_en
