http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #10 from Paul Koning <pkoning at gcc dot gnu.org> 2011-10-11 19:03:24 UTC --- Created attachment 25467 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25467 Tentative patch against 4.6.1 I chased the issue for a while, using 4.6.1 as the test version. The problem is in extract_range_from_assert. When processing < <= > >= assertions, it sets the min (for < <=) or max (for > >=) of the calculated range to be the type min or max of the right hand side. In the testcase, we have "m_timestamp > AT_END" where m_timestamp is unsigned int and AT_END is enum with value 2. The highest enum value of that enum type is 3, so if fstrict-enums is in effect, the type max is 3. Result: while the dump file shows the resulting range as [3,+INF] what that actually means is [3,3] because the upper bound of the enum is applied, *not* the upper bound of the variable being compared. The solution is for extract_range_from_assert to pick up type min or type max from the type of the left hand side (here m_timestamp, i.e., unsigned int). So the range still shows as [3,+INF] but now that represents [3,4294967295] and the resulting code is correct. The patch is just one line. The question I have is whether changing the way variable "type" is set is right, because it is also used in the != case and I don't fully understand that one.
