This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fstrict-enums and value ranges in VRP


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]