Re: Potential bug with wide_int_storage::set_len

2016-10-13 Thread Eric Botcazou
> 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

Re: Potential bug with wide_int_storage::set_len

2016-10-13 Thread Richard Biener
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

Re: Potential bug with wide_int_storage::set_len

2016-10-13 Thread Andre Vieira (lists)
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 >>

Re: Potential bug with wide_int_storage::set_len

2016-10-13 Thread Andre Vieira (lists)
> 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. >

Re: Potential bug with wide_int_storage::set_len

2016-10-12 Thread Eric Botcazou
> 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

Re: Potential bug with wide_int_storage::set_len

2016-10-12 Thread Jakub Jelinek
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

Re: Potential bug with wide_int_storage::set_len

2016-10-12 Thread Jakub Jelinek
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

Potential bug with wide_int_storage::set_len

2016-10-12 Thread Andre Vieira (lists)
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

Potential bug with wide_int_storage::set_len

2016-10-12 Thread Andre Vieira (lists)
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