Re: fstrict-enums and value ranges in VRP

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Jun 2, 2016 at 2:53 AM, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
> On Thu, Jun 02, 2016 at 08:54:36AM +1000, kugan wrote:
>> Hi All,
>>
>> When I compile the following code with g++ using -fstrict-enums and -O2
>>
>> enum v
>> {
>>   OK = 0,
>>   NOK = 1,
>> };
>>
>> int foo0 (enum v a)
>> {
>>   if (a > NOK)
>>     return 0;
>>   return 1;
>> }
>>
>> vrp1 dump looks like:
>> Value ranges after VRP:
>>
>> a.0_1: VARYING
>> _2: [0, 1]
>> a_3(D): VARYING
>>
>>
>> int foo0(v) (v a)
>> {
>>   int a.0_1;
>>   int _2;
>>
>>   <bb 2>:
>>   a.0_1 = (int) a_3(D);
>>   if (a.0_1 > 1)
>>     goto <bb 4>;
>>   else
>>     goto <bb 3>;
>>
>>   <bb 3>:
>>
>>   <bb 4>:
>>   # _2 = PHI <0(2), 1(3)>
>>   return _2;
>>
>> }
>>
>> Should we infer value ranges for the enum since this is -fstrict-enums and
>> optimize it?
>>
>> @item -fstrict-enums
>> @opindex fstrict-enums
>> Allow the compiler to optimize using the assumption that a value of
>> enumerated type can only be one of the values of the enumeration (as
>> defined in the C++ standard; basically, a value that can be
>> represented in the minimum number of bits needed to represent all the
>> enumerators).  This assumption may not be valid if the program uses a
>> cast to convert an arbitrary integer value to the enumerated type.
>
> It seems like the "basically" part contradicts the first sentence?

It really depends on what the standard says exactly ;)  VRP just uses
TYPE_MIN/MAX_VALUE and the FE is responsible for setting them.

But yes, we have -fno-strict-enums by default for a reason ;)

Richard.