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?
Consider
enum Foo
{
a = 0,
b = 2
};
Foo a = (Foo) 2;
That should fit in the minimum number of bits used to represent
the enum, but clearly isn't one of the enum's constants. I
guess if vrp only says its in the range [1, 3] then it doesn't
matter.
Then consider
Foo b = (Foo) 3;
If you assume two's complement (which I believe is
implementation defined) then it also fits in the minimum number
of bits, but is clearly outside the range for vrp.
I guess given the last bit, these are both ment to be invalid?
I guess the correct thing according to the docs is to optimize,
but personally I'd be pretty scared of turning that flag on.
Trev
>
>
> Thanks,
> Kugan
