[Bug optimization/14669] [3.4/3.5 Regression] Wrong code with -O for enum values expression E4 <= t && t <= E6

["roger at eyesopen dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From roger at eyesopen dot com  2004-03-22 06:15 -------
Hi Kazu,
I agree with your analysis that this was a latent problem in fold exposed by
my fold_convert change.  To prevent the unbounded recursion with your patch you
also need to check that TREE_TYPE (tem) != TREE_TYPE (arg0), [ow whatever the
correct type comparison is].  I suspect that lang_hooks.types.{un}signed_type is
returning a widening type, hence the call to recursive call to fold triggers the
exact same transformation.

On expressions such as (unsigned)x < 1, it is often impossible to remove the
NOP_EXPR as it's required to determine the width and signedness of the
comparison.

Perhaps another solution to the recursion is to add the following clause:

 	       && (tem = get_unwidened (arg0, NULL_TREE)) != arg0
+	       && (tem = (TREE_UNSIGNED (TREE_TYPE (arg0))
+			  ? fold_convert (lang_hooks.types.unsigned_type ...
+			  : fold_convert (lang_hooks.types.signed_type ...
>>>            && get_unwidened (tem, NULL_TREE) == tem 
 	       && (t1 = get_unwidened (arg1, TREE_TYPE (tem))) != 0

It might also be worthwhile calling lang_hooks.types.{un}signed_type if
TREE_UNSIGNED (TREE_TYPE (arg0)) != TREE_UNSIGNED (TREE_TYPE (tem)), as
tested in your first version.  Similarly, we could also avoid these calls
for EQ_EXPR and NE_EXPR, its only the ordering comparisons that require
that we cast the operands back to the correctly signed type.

Sorry for the inconvenience, but it looks like you're/we're close to a fix.


-- 


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