wide-int branch now up for public comment and review

[Richard Sandiford]

Kenneth Zadeck <zadeck@naturalbridge.com> writes:
> On 08/24/2013 08:05 AM, Richard Sandiford wrote:
>> Richard Sandiford <rdsandiford@googlemail.com> writes:
>>> I wonder how easy it would be to restrict this use of "zero precision"
>>> (i.e. flexible precision) to those where primitive types like "int" are
>>> used as template arguments to operators, and require a precision when
>>> constructing a wide_int.  I wouldn't have expected "real" precision 0
>>> (from zero-width bitfields or whatever) to need any special handling
>>> compared to precision 1 or 2.
>> I tried the last bit -- requiring a precision when constructing a
>> wide_int -- and it seemed surprising easy.  What do you think of
>> the attached?  Most of the forced knock-on changes seem like improvements,
>> but the java part is a bit ugly.  I also went with "wide_int (0, prec).cmp"
>> for now, although I'd like to add static cmp, cmps and cmpu alongside
>> leu_p, etc., if that's OK.  It would then be possible to write
>> "wide_int::cmp (0, ...)" and avoid the wide_int construction altogether.
>>
>> I wondered whether you might also want to get rid of the build_int_cst*
>> functions, but that still looks a long way off, so I hope using them in
>> these two places doesn't seem too bad.
>>
>> This is just an incremental step.  I've also only run it through a
>> subset of the testsuite so far, but full tests are in progress...
> So i am going to make two high level comments here and then i am going 
> to leave the ultimate decision to the community.   (1) I am mildly in 
> favor of leaving prec 0 stuff the way that it is (2) my guess is that 
> richi also will favor this.   My justification for (2) is because he had 
> a lot of comments about this before he went on leave and this is 
> substantially the way that it was when he left. Also, remember that one 
> of his biggest dislikes was having to specify precisions.

Hmm, but you seem to be talking about zero precision in general.
(I'm going to call it "flexible precision" to avoid confusion with
the zero-width bitfield stuff.)  Whereas this patch is specifically
about constructing flexible-precision _wide_int_ objects.  I think
wide_int objects should always have a known, fixed precision.

Note that fixed_wide_ints can still use primitive types in the
same way as before, since there the precision is inherent to the
fixed_wide_int.  The templated operators also work in the same
way as before.  Only the construction of wide_int proper is affected.

As it stands you have various wide_int operators that cannot handle two
flexible-precision inputs.  This means that innocent-looking code like:

  extern wide_int foo (wide_int);
  wide_int bar () { return foo (0); }

ICEs when combined with equally innocent-looking code like:

  wide_int foo (wide_int x) { return x + 1; }

So in practice you have to know when calling a function whether any
paths in that function will try applying an operator with a primitive type.
If so, you need to specify a precison when constructing the wide_int
argument.  If not you can leave it out.  That seems really unclean.

The point of this template stuff is to avoid constructing wide_int objects
from primitive integers whereever possible.  And I think the fairly
small size of the patch shows that you've succeeded in doing that.
But I think we really should specify a precision in the handful of cases
where a wide_int does still need to be constructed directly from
a primitive type.

Thanks,
Richard