This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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), unsignedp0);

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.

C99 just says that an enum must be compatible with some integral type;
AFAICT, that means the values of a C enum are all values which can be
expressed in the underlying type, which would suggest that
TYPE_MIN/MAX_VALUE and TYPE_PRECISION would be the same as for the
underlying type.  But then we don't know the minimum precision necessary to
represent all of the enumerators, as expressed by TYPE_PRECISION in the C++
frontend and computed from TYPE_MIN/MAX_VALUE in finish_struct in the C
frontend.  Thoughts?

One option would be to change the C frontend to use the same representation
as the C++ frontend and remove the above code.

Another would be to disable the above code for C++.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]