On Mon, 19 Mar 2012, Eric Botcazou wrote:

> > It does make sense to give the target control over the mode used for
> > sizetype.  Of course a global change of the default (for example to
> > use Pmode as Ada did) will require testing each affected target,
> > so I think it makes sense to keep the default as-is.
> No disagreement here.
> > Btw, we still have the issue on which _precision_ we should use for
> > sizetype -- if we expect modulo-semantics of arithmetic using it
> > (thus basically sign-less arithmetic) then the precision has to match
> > the expectation the C frontend (and other frontends) assume how pointer
> > offsets are handled.  Currently the C frontend gets this not correct
> > which means negative offsets will be not correctly handled.
> Is this theoritical or practical?  Are you talking about GET_MODE_BITSIZE vs 

No, about the disagreement of the precision of ptrdiff_t and that
of sizetype.  See c-common.c:pointer_int_sum:

  /* Convert the integer argument to a type the same size as sizetype
     so the multiply won't overflow spuriously.  */
  if (TYPE_PRECISION (TREE_TYPE (intop)) != TYPE_PRECISION (sizetype)
      || TYPE_UNSIGNED (TREE_TYPE (intop)) != TYPE_UNSIGNED (sizetype))
    intop = convert (c_common_type_for_size (TYPE_PRECISION (sizetype),
                                             TYPE_UNSIGNED (sizetype)), 

and consider what happens for example on m32c - we truncate the
24bit ptrdiff_t to the 16bit sizetype, losing bits.  And we are
performing the index * size multiplication in a maybe artificially
large type, losing information about overflow behavior and possibly
generating slow code for no good reason.

ISTR there was a correctness issue here, too, but maybe I've fixed
that already.

> > Similar issues arise from the mode/precision chosen for the bitsize
> > types.  We choose a way to wide precision for them, so the
> > modulo-semantics assumption does not usually hold for bitsize
> > quantities.
> Again because of GET_MODE_PRECISION vs GET_MODE_BITSIZE?  Otherwise we round 
> up 
> the precision since GCC 4.5 so there should be no more weird precision.

Well, because if sizetype is SImode (with -m32) and bitsizetype DImode
(we round up its precision to 64bits) then a negative byte-offset
in the unsigned sizetype is 0xffff for example.  When we then perform
arithmetic on bits, say (bitsizetype)sz * BITS_PER_UNIT + 9 we get
0xffff * 8 == 0x80001 (oops) + 9 == 0x80001.  bitsizetype is of too
large precision to be a modulo-arithmetic bit-equivalent to sizetype
(at least for our constant-folding code) for "negative" offsets.
Probably one of the reasons of the weird 
sizetype-is-unsigned-but-constants-are-sign-extended rule.


Reply via email to