This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/3] Simplify wrapped binops
- From: Robin Dapp <rdapp at linux dot vnet dot ibm dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 19 May 2017 12:09:54 +0200
- Subject: Re: [PATCH 2/3] Simplify wrapped binops
- Authentication-results: sourceware.org; auth=none
- References: <5790A709.4060804@linux.vnet.ibm.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> <803f5629-2a68-db02-a3a1-16fbe656f242@linux.vnet.ibm.com> <CAHFci2-zFEjPa4TokPca8EDF4zM5PU+0B8maFKa189=Pyrcj7Q@mail.gmail.com> <57eda9e0-8fbb-7508-f41e-d98000314012@linux.vnet.ibm.com> <CAHFci2-VJu5SbWzm43uozxRq2L=4Sxp0L573y-vPeK69RX_iaA@mail.gmail.com>
> I can guess what is happening here. It's a 40 bits unsigned long long
> field, (s.b-8) will be like:
> _1 = s.b
> _2 = _1 + 0xfffffffff8
> Also get_range_info returns value range [0, 0xFFFFFFFFFF] for _1.
> You'd need to check if _1(with range [0, 0xFFFFFFFFFF]) + 0xfffffffff8
> overflows against precision of the bit-field which is 40 bits
> precision. The failure might because overflowness is checked against
> unsigned long long's precision which is 64 bits.
>> Also, is there a possibility to know if there was an "ok" overflow or
>> not from get_range_info ()'s output? Would I have to compare the result
>> with the involved variable's range?
> I think you have to check it manually against max/min value of that
> type precision.
Currently, extract_... () does that all that for me, is it really too
expensive to call? I guess, using get_range_info first and calling
extract when get_range_info returns a VR_RANGE is not really a favorable
thing to do either? :)
Regards
Robin