Re: Your sizetype changes ...

[Mark Mitchell <mark at codesourcery dot com>]

  Didn't I add code to the size comparison code to handle that?  Or did I
  just do it in one direction and not teh other?

The assertions are failing *because* things are comparing equal, not
because they're not.

      *Anything* that is legal to do with a size_t is also legal to do with
      an unsigned int, and vice versa.  So, this comment:

  No.  The case is (x * 40) / 20.  If x is a normal unsigned type, you
  can't convert this to x*2 because the x*40 might have overflowed.  But
  if it's an actual sizetype, you can.

No, you can't.  This C++ code:

  unsigned int x;
  size_t s;

  x = UINT_MAX;
  s = (x * 40) / 20;

is exactly equivalent to this C++ code, in all respects:

  unsigned int x;
  unsigned int s;

  x = UINT_MAX;
  s = (x * 40) / 20;

assuming that `size_t' is `unsigned int'.  There are no legal
additional optimizations -- whatever you can conclude about overflow
in the second case, you can also conclude in the first.

      In any case, there's no reason to change the behavior of the C++
      front-end.  For instance, adding a NOP_EXPR to convert to a type with
      TYPE_IS_SIZETYPE set would be silly; it's semantically meaningless to
      the front-end, and the back-end can't make use of the information for
      any optimization since, say, a cast to `size_t' doesn't make for any
      different properties of the underlying expression.

  Right, I wasn't proposing doing it that way, just considering the
  two types as equivalent.

They are considered equivalent.  So, when we ask to convert an
expression with type `unsigned int' to `size_t', we don't do anything
-- we just leave the expression alone.  So, then, when we pass it to
size_binop, it aborts.

      2000-02-29  Mark Mitchell  <mark@codesourcery.com>

	  * fold-const.c (size_binop): Don't asert inputs are the same
	  and have TYPE_IS_SIZETYPE set.
	  (size_diffop): Likewise.

  I hope this is *very* temporary because this disables *critically important*
  internal check with sizes.  Indeed you were the person who was most concerned
  about misuse of sizetypes and were the motivation for that change.

It's as temporary as you make it.  I have no present intention of
making any further changes in this area.

No, I was not concerned about misuses of sizetypes.  I was concerned
about misengineering of GCC.  I was concerned about adding fields to
all structures such that a) those fields were related by an algebraic
identity but b) could be updated independently, leading to an
inconsistent state.  That's got very little to do with whether or not
size_binop gets arguments of type size_t, or some equivalent integer
type.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com