[Bug c++/15330] inconsistent slicing on cast of int to enum

["mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From mark at codesourcery dot com  2004-05-06 21:53 -------
Subject: Re:  inconsistent slicing on cast of int to enum

sebor at roguewave dot com wrote:

>------- Additional Comments From sebor at roguewave dot com  2004-05-06 21:46 -------
>Subject: Re:  inconsistent slicing on cast of int to enum
>
>bangerth at dealii dot org wrote:
>
>  
>
>>------- Additional Comments From bangerth at dealii dot org  2004-05-06 21:31 -------
>>So do I (and I'll take action :-) 
>> 
>>The enum is supposed to be represented in a bitfield that is just as large 
>>as to hold the biggest possible enum value. We shouldn't prohibit the 
>>compiler to not honor this information. 
>>    
>>
>
>Does the compiler actually take advantage of this to implement some
>useful optimization? If so, I agree with closing the issue as NAD.
>(I would appreciate if you could explain what this optimization is).
>Otherwise, i.e., if the change between 3.3 and 3.4 was accidental,
>I consider it a regression, certainly in the quality of the
>implementation of the compiler.
>
I think that there are some optimizations that are performed already and 
others that will be added in the future. 

For example, there is prototype code to do range-propagation, which (I 
believe) assumes that values of the enumeration type can be assumed to 
have values no larger than permitted by the number of bits assigned.  
Therefore, certain tests can be optimized away.

Another example of an optimization (which we may or not currently 
perform) is that if you have an appropriately-located bit-field of the 
enum type, and you assign an enum quantity to it, you can just do 
bitwise-operations on the entire containing 32-bit word without first 
masking the value you are storing (because you "know" that the 
high-order bits must be zero.)



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15330