This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Potential bug with wide_int_storage::set_len

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 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.

Here is what rtl.texi says on it:
@item (const_int @var{i})
This type of expression represents the integer value @var{i}.  @var{i}
is customarily accessed with the macro @code{INTVAL} as in
@code{INTVAL (@var{exp})}, which is equivalent to @code{XWINT (@var{exp}, 0)}.

Constants generated for modes with fewer bits than in
@code{HOST_WIDE_INT} must be sign extended to full width (e.g., with
@code{gen_int_mode}).  For constants for modes with more bits than in
@code{HOST_WIDE_INT} the implied high order bits of that constant are
copies of the top bit.  Note however that values are neither
inherently signed nor inherently unsigned; where necessary, signedness
is determined by the rtl operation instead.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]