This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: overflow check in extract_range_from_binary_1 useless?
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Aldy Hernandez <aldyh at redhat dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, Andrew MacLeod <amacleod at redhat dot com>
- Date: Thu, 5 Jul 2018 16:06:32 -0600
- Subject: Re: overflow check in extract_range_from_binary_1 useless?
- References: <276abf3c-53ab-c598-3329-16f5b39c2a5f@redhat.com> <CAFiYyc1JNPWj8vyiV4ztd+7356rP6-cn2WryNoG0_gTsam1yvg@mail.gmail.com>
On 06/13/2018 05:18 AM, Richard Biener wrote:
> On Fri, Jun 8, 2018 at 11:42 AM Aldy Hernandez <aldyh@redhat.com> wrote:
>>
>> Howdy.
>>
>> Am I missing something or are these two sets identical?
>>
>>> /* Get the lower and upper bounds of the type. */
>>> if (TYPE_OVERFLOW_WRAPS (expr_type))
>>> {
>>> type_min = wi::min_value (prec, sgn);
>>> type_max = wi::max_value (prec, sgn);
>>> }
>>> else
>>> {
>>> type_min = wi::to_wide (vrp_val_min (expr_type));
>>> type_max = wi::to_wide (vrp_val_max (expr_type));
>>> }
>>
>> Isn't wi::to_wide(TYPE_MIN/MAX_VALUE) the same as wi::min/max_value, or
>> is there some weird language (*cough ada*) subtlety I'm missing?
>
> It might have subtle differences for -fstrict-enums or other language specific
> types where the legal value-range doesn't cover all of the types precision.
>
> I think you can safely use the wi::max/min_value variant and IMHO
> vrp_val_min/max should use wi::min/max_value as well (well, it returns
> a tree so better not re-create that all the time).
Or even C++ perhaps where an enum object can take on values outside the
enum.
Jeff