On 12/2/20 9:27 AM, Richard Sandiford via Gcc-patches wrote:
> This is a gcc-10 version of:
>
> Richard Sandiford writes:
>> This PR shows another problem with calculating value ranges for
>> POLY_INT_CSTs. We have:
>>
>> ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]>
>>
>> where the
This is a gcc-10 version of:
Richard Sandiford writes:
> This PR shows another problem with calculating value ranges for
> POLY_INT_CSTs. We have:
>
> ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]>
>
> where the VQ coefficient is unsigned but is effectively acting
> as a negative number
On 10/28/20 5:43 AM, Richard Sandiford via Gcc-patches wrote:
This PR shows another problem with calculating value ranges for
POLY_INT_CSTs. We have:
ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]>
where the VQ coefficient is unsigned but is effectively acting
as a negative number. W
On Wed, Oct 28, 2020 at 10:44 AM Richard Sandiford via Gcc-patches
wrote:
>
> This PR shows another problem with calculating value ranges for
> POLY_INT_CSTs. We have:
>
> ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]>
>
> where the VQ coefficient is unsigned but is effectively acting
>
This PR shows another problem with calculating value ranges for
POLY_INT_CSTs. We have:
ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]>
where the VQ coefficient is unsigned but is effectively acting
as a negative number. We wrongly give the POLY_INT_CST the range:
[9, INT_MAX]
and t
