[Bug middle-end/50189] [4.5/4.6 Regression] Wrong code error in -O2 [-fstrict-enums] compile, target independent

["pkoning at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.