This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Remove build_int_cst_wide_type function.
On Mon, May 10, 2010 at 11:24 AM, Anatoly Sokolov <aesok@post.ru> wrote:
> Hi.
>
> ----- Original Message ----- From: "Richard Guenther"
> <richard.guenther@gmail.com>
> To: "Anatoly Sokolov" <aesok@post.ru>
> Cc: <gcc-patches@gcc.gnu.org>; <java-patches@gcc.gnu.org>
> Sent: Saturday, May 08, 2010 12:31 AM
> Subject: Re: Remove build_int_cst_wide_type function.
>
>
>> Use build_int_cstu instead and retain using HOST_WIDE_INTs. ?Btw,
>> both build_int_cst and build_int_cstu should do proper sign/zero
>> extension as the types precision may be lower than that of
>> HOST_WIDE_INT.
>
> ?The build_int_cst and build_int_cstu function don't clear extra bits
> outside
> of the type precision. The build_int_ct_type function truncate signed
> HOST_WIDE_INT constant to the type precision. Comment before
> build_int_cst_type
> say:
> /* ... ?Constants
> ?with these extra bits may confuse the fold so that it detects overflows
> ?even in cases when they do not occur, and in general should be avoided.
> ?We cannot however make this a default behavior of build_int_cst without
> ?more intrusive changes, since there are parts of gcc that rely on the extra
> ?precision of the integer constants. ?*/
>
> ?Consequently, need both build_int_cst and build_int_cstu functions which
> don't truncate constant and new build_int_cstu_type function which truncate
> unsigned HOST_WIDE_INT constants.
>
> ?How about rename build_int_cst_type/build_int_cstu_type function to
> hwi_to_tree/uhwi_to_tree by analogy with the double_int_to_tree function?
I don't think the comment is valid. The problem is that INTEGER_CSTs
are shared and non-canonical ones should never be entered into the
shared pool. Which means that build_int_cst_wide should assert
that the constant is properly zero-/sign-extended according to its
type (at least with ENABLE_CHECKING). Currently build_int_cst_wide
is used as an optimization (to avoid the zero-/sign-extension when its
already done), but really it is the low-level interface that shouldn't
be exposed ... (we have way too many ways to build INTEGER_CSTs...)
Richard.
> Anatoly.
>