On Thu, Jun 2, 2016 at 2:53 AM, Trevor Saunders <tbsau...@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.
