Richard Sandiford writes:
>> I've looked at the resulting wide-int.h and like it a lot
>> compared to what is on the branch (less code duplication for one).
>>
>> I think we should go ahead with this change (keeping the double-int
>> changes out for now, I didn't yet look at that patch). We can
>
Richard Biener writes:
>> * wide-int.h no longer includes tm.h.
>>
>> This is done by adding a new MAX_BITS_PER_UNIT to machmode.def,
>> so that the definition of MAX_BITSIZE_MODE_ANY_MODE no longer relies on
>> BITS_PER_UNIT. Although I think we usually assume that BITS_PER_UNIT
>> is a
Hi,
On Thu, 5 Sep 2013, Richard Biener wrote:
> > (1) whether it's OK for wide_ints to be writable.
> >
> > The interface already exposed the idea of an array of blocks,
> > via get_val() and get_len(). The question here is whether it is OK
> > to also have the corresponding write f
On Sun, 1 Sep 2013, Richard Sandiford wrote:
> This is an RFC and patch for an alternative way of organising the
> wide-int classes, along the lines I mentioned earlier. The main points
> are below, each with a "headline" and a bit of extra waffle that can be
> skipped if too long:
>
> * As Rich
On Thu, 5 Sep 2013, Richard Sandiford wrote:
> Kenneth Zadeck writes:
> > It is possible restore the privacy of the original patches but this
> > seems to involve using a private class inside the namespace and using
> > C++ friends.
> >
> > Adding visibility adds extra code
> >
> > namespace wi
Kenneth Zadeck writes:
> It is possible restore the privacy of the original patches but this
> seems to involve using a private class inside the namespace and using
> C++ friends.
>
> Adding visibility adds extra code
>
> namespace wi {
> class impl {
> private:
>
Richi, and the rest of the community,
Richard Sandiford has proposed a set of patches that change the wide-int
api in a significant way. We think that we really need some input from
the community as to if this is what we want using C++ in gcc is going to
look like. There are, as I see it, two
On Sep 2, 2013, at 1:22 AM, Richard Sandiford
wrote:
> What I'm saying is that the assert stops plain:
>
> max_wide_int x = wide_int_var;
Sorry for being slow. I see the point, indeed, from the preexisting code, we
did:
fixed_wide_int (const wide_int_ro w) : wide_int_ro (w) {
/* We o
"Joseph S. Myers" writes:
> On Sun, 1 Sep 2013, Richard Sandiford wrote:
>
>> like to get rid of them and just keep the genuine operators. The problem
>> is that I'd have liked the AND routine to be "wi::and", but of course that
>> isn't possible with "and" being a keyword, so I went for "w
On Sun, 1 Sep 2013, Richard Sandiford wrote:
> like to get rid of them and just keep the genuine operators. The problem
> is that I'd have liked the AND routine to be "wi::and", but of course that
> isn't possible with "and" being a keyword, so I went for "wi::bit_and"
> instead. Same fo
On 09/02/2013 05:35 AM, Richard Biener wrote:
On Mon, 2 Sep 2013, Richard Sandiford wrote:
Kenneth Zadeck writes:
There is no place for exactly two HWIs in the machine independent parts
of the compiler,
I totally agree. In fact I was taking that so much for granted that
I didn't even think
On Mon, 2 Sep 2013, Richard Sandiford wrote:
> Kenneth Zadeck writes:
> > There is no place for exactly two HWIs in the machine independent parts
> > of the compiler,
>
> I totally agree. In fact I was taking that so much for granted that
> I didn't even think to add a rider about it, sorry.
Kenneth Zadeck writes:
> There is no place for exactly two HWIs in the machine independent parts
> of the compiler,
I totally agree. In fact I was taking that so much for granted that
I didn't even think to add a rider about it, sorry. I didn't mean
to imply that we should keep double_int arou
Mike Stump writes:
>>> * A static assert also prevents fixed_wide_ints from being initialised
>>> from wide_ints. I think combinations like that would always be a
>>> mistake.
>
> I don't see why. In C, this:
>
> int i;
> long l = i;
>
> is not an error, and while a user might not want t
On Sep 1, 2013, at 7:37 PM, Kenneth Zadeck wrote:
> On 09/01/2013 03:21 PM, Richard Sandiford wrote:
>>
>> * As Richard requested, the main wide int class is parameterised by the
>> storage:
>>
>> template
>> class GTY(()) generic_wide_int : public storage
Careful of GTY, it gets fin
My main discomfort is the double-int part. At this point in time the
only usage of double-int left on the branch is because the fixed ints
use it as their underlying representation. I think that rather than
doing a lot of work to accommodate this, it would be better to just
change the fixed r
16 matches
Mail list logo
