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: Robin Dapp <rdapp at linux dot vnet dot ibm dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>, Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 18 May 2017 16:45:45 +0200
- Subject: Re: [PATCH] Tree-level fix for PR 69526
- Authentication-results: sourceware.org; auth=none
- References: <5790A709.4060804@linux.vnet.ibm.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> <CAFiYyc1AcFG8JzoO3LYW9iyGsPj+7Kv17weZp+U3vTaeiqdhKA@mail.gmail.com> <260c4925-29e2-d50a-871e-397e2f9f4efb@linux.vnet.ibm.com> <CAFiYyc2_WX+3vzX27iRO9byK4zoc8N43F-d=Cg2xXoHwLRTgGQ@mail.gmail.com> <CAHFci299r3v3jbaZn0pzKPmk+yvF=Hwnbq+hxYGJCz-y8Qx0jg@mail.gmail.com>
> Hmm, won't (uint32_t + uint32_t-CST) doesn't overflow be sufficient
> condition for such transformation?
Yes, in principle this should suffice. What we're actually looking for
is something like a "proper" (or no) overflow, i.e. an overflow in both
min and max of the value range. In
(a + cst1) + cst2
an overflow of (a + cst1) will still produce a valid range as long as
overflow(a_min + cst1) == overflow(a_max + cst1). When max overflows
but min does not we must not simplify. Currently, I'm checking if the
range of (a + cst1) is still a VR_RANGE, for now disregarding
ANTI_RANGEs which could most likely be dealt with as well.
A major discussion point in my last try was to wrongly always use
sign-extend when extending cst1 to the outer type. This is now changed
to use sign-extension when (a + cst1) "properly" overflows as in
ASSUME (a > 0);
(unsigned long)(a + UINT_MAX) + 1;
resulting in (unsigned long)(a) + (unsigned long)0, or use the type sign
of the constant like in
ASSUME (a < 2);
(unsigned long)(a + 4294967294u) + 10;
resulting in (unsigned long)(a) + (unsigned long)((unsigned
long)4294967294 + (unsigned long)10). The additional flag from the last
patch is not necessary.
Test suite is clean on s390x and x86, bootstraps successful.
Regards
Robin