This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Tree-level fix for PR 69526
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Robin Dapp <rdapp at linux dot vnet dot ibm dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 13 Dec 2016 15:13:45 +0100
- Subject: Re: [PATCH] Tree-level fix for PR 69526
- Authentication-results: sourceware.org; auth=none
- References: <5790A709.4060804@linux.vnet.ibm.com> <CAFiYyc2XVcJA4ZsS5LSLfRD-V3U9tDRpbeU_FRwoNa2w8Z4cGw@mail.gmail.com> <fea2a49d-5f2a-ae24-8601-44e52a2d76b4@linux.vnet.ibm.com> <CAFiYyc2UKpz4krcaxow_=yF6_eFZU_=M5k+6VTHZscDz+g=2uw@mail.gmail.com> <6bc1abab-9b54-fb67-fe98-9aaf993859dd@linux.vnet.ibm.com> <CAFiYyc28DaMGuzcMPZQ+AmHXuuNDAyAorMbW0Vo02EEoyZ+xSg@mail.gmail.com> <aba5346a-027f-ee35-0406-3998ab484621@linux.vnet.ibm.com> <CAFiYyc0aExY-MmRczHKJuQ8UFOpMy_+dzV-n05UJJOhuZVywTg@mail.gmail.com> <CAFiYyc0gnMe7j+DgTeudnpH-zD22nK7Cuv4a2zj4Va-anApTBA@mail.gmail.com> <27be603c-4499-ca96-f252-40934d3e420d@linux.vnet.ibm.com> <CAFiYyc1s699beSC9bpDGxY_2ppenDLoP3nbjYSnThF1cp2YHDA@mail.gmail.com> <d6e24bfd-fc3e-4160-fe27-db3eda5b857c@linux.vnet.ibm.com>
On Wed, Dec 7, 2016 at 5:14 PM, Robin Dapp <rdapp@linux.vnet.ibm.com> wrote:
>> So we have (uint64_t)(uint32 + -1U) + 1 and using TYPE_SIGN (inner_type)
>> produces (uint64_t)uint32 + -1U + 1. This simply means that we cannot ignore
>> overflow of the inner operation and for some reason your change
>> to extract_range_from_binary_expr didn't catch this. That is _8 + 4294967295
>> overflows but we ignored that.
>
> In this case the range of _8 was [1,1] so no overflow.
> I think the problem is rather about the interpretation of the inner
> constant. I tried discerning two cases now, a range split (i.e. when the
> single range of a binop variable becomes an anti range or two ranges
> after combining it with the binop's other range) and an overflow of the
> range's min and max.
> If the range didn't split, we can perform the simplification. If there
> was a min and max overflow, we have to interpret the inner constant as
> signed and perform a sign extension before converting it to the outer
> type. Without overflow we can use TYPE_SIGN (inner_type).
> Does this make sense?
I'm not sure there is anything to "interpret" -- the operation is unsigned
and overflow is when the operation may wrap around zero. There might
be clever ways of re-writing the expression to
(uint64_t)((uint32_t)((int32_t)uint32 + -1) + 1)
avoiding the overflow and thus allowing the transform but I'm not sure that's
good.
A related thing would be canonicalizing unsigned X plus CST to
unsigned X minus CST'
if CST' has a smaller absolute value than CST. I think currently we
simply canonicalize
to 'plus CST' but also only in fold-const.c, not in match.pd (ah we
do, but only in a simplified manner).
That said, can we leave that "trick" out of the patch? I think your
more complicated
"overflows" result from extract_range_from_binary_expr_1 doesn't apply to all
ops (like MULT_EXPR where more complicated cases can arise).
Richard.
> Included the remarks and attached the new version.
>
> Regards
> Robin