Bug 36384 - folding of conversion for BOOLEAN_TYPE or ENUMERAL_TYPE
Summary: folding of conversion for BOOLEAN_TYPE or ENUMERAL_TYPE
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2008-05-30 07:50 UTC by Eric Botcazou
Modified: 2009-09-11 05:48 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-05-30 08:05:36


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Botcazou 2008-05-30 07:50:15 UTC
In fold_unary, CASE_CONVERT, the folding of the conversion into a bitwise AND
is performed only for INTEGER_TYPE, while it could very likely be performed
for BOOLEAN_TYPE and ENUMERAL_TYPE as well:

      /* 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.
	 ??? We don't do it for BOOLEAN_TYPE or ENUMERAL_TYPE because they
	 very likely don't have maximal range for their precision and this
	 transformation effectively doesn't preserve non-maximal ranges.  */
      if (TREE_CODE (type) == INTEGER_TYPE
	  && TREE_CODE (op0) == BIT_AND_EXPR
	  && TREE_CODE (TREE_OPERAND (op0, 1)) == INTEGER_CST)

The problem is that the transformation doesn't preserve non-maximal ranges for
a given precision and, as a consequence, VRP can draw different conclusions
on each side.

See gnat.dg/bit_packed_array3.adb.
Comment 1 Richard Biener 2008-05-30 08:05:36 UTC
Confirmed.