This is the mail archive of the
mailing list for the GCC project.
Re: Potential bug with wide_int_storage::set_len
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: "Andre Vieira (lists)" <Andre dot SimoesDiasVieira at arm dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 13 Oct 2016 10:50:07 +0200
- Subject: Re: Potential bug with wide_int_storage::set_len
- Authentication-results: sourceware.org; auth=none
- References: <57FE5EA6.email@example.com> <20161012164539.GU7282@tucnak.redhat.com> <57FF4718.firstname.lastname@example.org>
On Thu, Oct 13, 2016 at 10:34 AM, 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.
> Euhm, but then surely we must get rid of the is_sign_extended parameter
> Right now if you call that function for the same example, but with
> is_sign_extended set to true, the value will __NOT__ be sign extended.
I believe that is an optimization to cater for the difference between
storage used for INTEGER_CST trees and CONST_INT RTLs. INTEGER_CSTs
representation is _not_ sign-extended (but it carries precision and
Both CONST_INT and INTEGER_CST can be accessed as wide-ints without
copying the storage via some clever adaptor use but users need to care about
this subtle difference.