"H.J. Lu" writes:
> On Fri, Apr 29, 2016 at 5:30 AM, Richard Sandiford
> wrote:
>> Following on from the comparison patch, I think it makes sense to
>> support << and >> for offset_int (int128_t) and widest_int (intNNN_t),
>> with >> being arithmetic shift. It doesn't make sense to use
>> logica
On Fri, Apr 29, 2016 at 2:30 PM, Richard Sandiford
wrote:
> Following on from the comparison patch, I think it makes sense to
> support << and >> for offset_int (int128_t) and widest_int (intNNN_t),
> with >> being arithmetic shift. It doesn't make sense to use
> logical right shift on a potentia
On Fri, Apr 29, 2016 at 2:26 PM, Richard Sandiford
wrote:
> offset_int and widest_int are supposed to be at least one bit wider
> than all the values they need to represent, with the extra bits
> being signs. Thus offset_int is effectively int128_t and widest_int
> is effectively intNNN_t, for ta
On Fri, Apr 29, 2016 at 5:30 AM, Richard Sandiford
wrote:
> Following on from the comparison patch, I think it makes sense to
> support << and >> for offset_int (int128_t) and widest_int (intNNN_t),
> with >> being arithmetic shift. It doesn't make sense to use
> logical right shift on a potentia
Following on from the comparison patch, I think it makes sense to
support << and >> for offset_int (int128_t) and widest_int (intNNN_t),
with >> being arithmetic shift. It doesn't make sense to use
logical right shift on a potentially negative offset_int, since
the precision of 128 bits has no mea
offset_int and widest_int are supposed to be at least one bit wider
than all the values they need to represent, with the extra bits
being signs. Thus offset_int is effectively int128_t and widest_int
is effectively intNNN_t, for target-dependent NNN.
Because the types are signed, there's not real
