[Bug middle-end/16693] [3.4/3.5 regression] Bitwise AND is lost when used within a cast to an enum of the same precision

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-22 23:30 -------
I agree.

Roger, I think this is a problem in fold with this code:

      /* Convert (T)(x & c) into (T)x & (T)c, if c is an integer
         constants (if x has signed type, the sign bit cannot be set
         in c).  This folds extension into the BIT_AND_EXPR.  */
      if (INTEGRAL_TYPE_P (type)
          && TREE_CODE (type) != BOOLEAN_TYPE
          && TREE_CODE (TREE_OPERAND (t, 0)) == BIT_AND_EXPR
          && TREE_CODE (TREE_OPERAND (TREE_OPERAND (t, 0), 1)) == INTEGER_CST)
 
The problem is that we turn:

  (enum E) ((unsigned int) (expr) & 0xf)

into:

  (E) (unsigned int) (expr) & (E) 0xf

which is not valid because "expr" may not be within the range of "E".  (In this
case "E" has the range [0, 0xf].)  The original code has a well-defined meaning;
the resulting code has an "unspecified" meaning according to the C++ standard. 
I think this transformation is only safe if the values can be shown to be in
range, as would be the case if the TYPE_PRECISION of "E" was as big as that of
"unsigned int".

Therefore, I've assigned this bug to you.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at eyesopen dot com
         AssignedTo|unassigned at gcc dot gnu   |roger at eyesopen dot com
                   |dot org                     |
             Status|REOPENED                    |ASSIGNED


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