Re: wider-than-int enums broken in C++

[law at redhat dot com]

In message <wvlznj3g2r0.fsf@prospero.boston.redhat.com>, Jason Merrill writes:
 >On 24 Jul 2003 15:13:00 -0300, Alexandre Oliva <aoliva@redhat.com> wrote:
 >
 >> Doh.  I realize now I forgot to include Richard's analysis.  Quoted
 >> without permission, with the following caveats: his testcase had gx as
 >> the variable name, and int is a 16-bit HImode on this target:
 >>
 >> <quote author="Richard Sandiford">
 >> When compiling "gx == 0", we call shorten_compare with:
 >>
 >>     op0 = <nop_expr type <integer_type SI> arg 0 <var_decl gx>>
 >>     op1 = <integer_cst type <int> constant 0>
 >>     result_type = <integer_type SI>
 >>
 >> The first thing shorten_compare does is to remove integer promotions, so:
 >>
 >>     primop0 = <var_decl gx>
 >>     primop1 = <integer_cst type <int> constant 0>
 >>
 >> We then have:
 >>[...]
 >>       /* If TYPE is an enumeration, then we need to get its min/max
 >> 	 values from it's underlying integral type, not the enumerated
 >> 	 type itself.  */
 >>       if (TREE_CODE (type) == ENUMERAL_TYPE)
 >> --->	type = c_common_type_for_size (TYPE_PRECISION (type), unsignedp
 >0);
 >
 >This seems like the broken bit.  Seems to me that we want the min/max
 >values of the enum, not of its underlying type.  And if we change 'type',
 >we need to repeat the TYPE_PRECISION comparison from the controlling 'if'.
 >
 >Ah, it seems that the C frontend just sets TYPE_MIN/MAX_VALUE to the lowest
 >and highest enums; that explains why this code wouldn't want to use them.
Right.  I'm pretty sure this code was added in response to a bug where we
used the high/low value for an enum and incorrectly narrowed a type for
a comparison against an enum.  I'm pretty sure we had a test in the c-torture
testsuite for it.

jeff