This is the mail archive of the
mailing list for the GCC project.
Re: Potential bug with wide_int_storage::set_len
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "Andre Vieira (lists)" <Andre dot SimoesDiasVieira at arm dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 12 Oct 2016 18:45:39 +0200
- Subject: Re: Potential bug with wide_int_storage::set_len
- Authentication-results: sourceware.org; auth=none
- References: <57FE5EA6.firstname.lastname@example.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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
> 0xFFFFFFFFFFFFFFFF, and I don't think this is what you want.
> Due to this, 'expand_expr' will expand a constant tree with unsigned
> integer type and value MAX_UINT to a rtx node (const_int -1).
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.