> If set_len really does 'ignore' signedness, then we are not treating X
> as having signedness SGN.
It does not, my interpretation is that it sign-extends when the value is not
already sign-extended, probably for the reason exposed by Richard. But that's
admittedly quite confusing so a comment
On Thu, Oct 13, 2016 at 10:34 AM, Andre Vieira (lists)
wrote:
>
>> That is correct. In RTL constants are always sign-extended from their
>> precision to HOST_BITS_PER_WIDE_INT, regardless if it is "signed" or
>> "unsigned" constant. Whether you treat the low precision bits of the
>> constant as
On 12/10/16 18:59, Eric Botcazou wrote:
>> During the development of a patch I encountered some strange behavior
>> and decided to investigate. The result of which is I think I found a bug
>> with 'wide_int_storage::set_len' in gcc/wide-int.h.
>>
>> The function reads:
>> inline void
>> wide_int_st
> That is correct. In RTL constants are always sign-extended from their
> precision to HOST_BITS_PER_WIDE_INT, regardless if it is "signed" or
> "unsigned" constant. Whether you treat the low precision bits of the
> constant as signed or unsigned is something encoded in the operation on it.
>
>
> During the development of a patch I encountered some strange behavior
> and decided to investigate. The result of which is I think I found a bug
> with 'wide_int_storage::set_len' in gcc/wide-int.h.
>
> The function reads:
> inline void
> wide_int_storage::set_len (unsigned int l, bool is_sign_e
On Wed, Oct 12, 2016 at 06:45:39PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 12, 2016 at 05:02:46PM +0100, Andre Vieira (lists) wrote:
> > Say you are running it on a 64-bit host:
> > #define HOST_BITS_PER_WIDE_INT 64
> >
> > and you call 'result.set_len (1, false);'
> >
> > Then this will sign e
On Wed, Oct 12, 2016 at 05:02:46PM +0100, Andre Vieira (lists) wrote:
> Say you are running it on a 64-bit host:
> #define HOST_BITS_PER_WIDE_INT 64
>
> and you call 'result.set_len (1, false);'
>
> Then this will sign extend the first element of val, to
> 0x, and I don't think th
Hello,
During the development of a patch I encountered some strange behavior
and decided to investigate. The result of which is I think I found a bug
with 'wide_int_storage::set_len' in gcc/wide-int.h.
The function reads:
inline void
wide_int_storage::set_len (unsigned int l, bool is_sign_extende
Hello,
During the development of a patch I encountered some strange behavior
and decided to investigate. The result of which is I think I found a bug
with 'wide_int_storage::set_len' in gcc/wide-int.h.
The function reads:
inline void
wide_int_storage::set_len (unsigned int l, bool is_sign_extende
