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: [patch] Fix pr23046


On Sun, Sep 18, 2005 at 05:27:19PM -0400, James A. Morrison wrote:
>  Sort of.  In cp/decl.c:finish_enum we have
>   /* The middle-end currently assumes that types with TYPE_PRECISION
>      narrower than their underlying type are suitably zero or sign
>      extended to fill their mode.  g++ doesn't make these guarantees.
>      Until the middle-end can represent such paradoxical types, we
>      set the TYPE_PRECISION to the width of the underlying type.  */
>   TYPE_PRECISION (enumtype) = TYPE_PRECISION (underlying_type);
> 
>  This was added last August by Roger to fix pr16372 and pr16693.

Roger's cop-out in the c++ front end is unfortunate, especially since
the middle-end does handle zero or sign extending values to fill the
mode -- it does exactly that for C.

I will claim that he also introduced a bug seen in the very next line:

  set_min_and_max_values_for_integral_type (enumtype, precision, unsignedp);

Note that we're passing the old, non-expanded precision, and thus
TYPE_MIN/MAX_VALUE do not match the actual width of the type.

All that said, I think we don't really have a coherent story about 
the Actual Rules.  For instance, I know Ada wants to be able to say
that the bounds are between 2 and 10, based on the user claiming
such things.  Whether or not these bounds are usable for anything
besides debug info is apparently a matter of debate.  There was some
random discussion about this among the Ada crowd that didn't lead to
any concensus that I can remember.

There are really only three options:

  (1) TYPE_MIN/MAX_VALUE must be set to match the actual width of the type.

  (2) Consider TYPE_MIN/MAX_VALUE as debugging info and never look at it
      in the optimizers.

  (3) TYPE_MIN/MAX_VALUE may be set arbitrarily.  In this case, the
      language must enforce this, such that it really Really is always
      true, by doing bounds checks and such in a different type.  And
      it means that things like the cast simplification thing in pr16693
      is a bug in fold.

We've got to pick one of these and stick with it.  Obviously, option 3
will be significantly more difficult, because I don't see anything we
can do for checking for invariants, and the places requiring auditing
are not localized.


r~


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