This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: don't sign-extend pointers when casting to unsigned long long
- From: Richard Henderson <rth at redhat dot com>
- To: Matt Austern <austern at apple dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 12 May 2003 14:07:25 -0700
- Subject: Re: PATCH: don't sign-extend pointers when casting to unsigned long long
- References: <A676FDE0-84A4-11D7-A94A-00039390D9E0@apple.com>
On Mon, May 12, 2003 at 11:07:53AM -0700, Matt Austern wrote:
> Suppose you're on a system where pointers are 32-bit and long long is
> 64-bit, and suppose you write
> "unsigned long long n = (unsigned long long) p".
> The results are counterintuitive. I would expect that the high 32 bits
> would all be 0. As it stands now, that may or may not be true: pointers get
> sign-extended.
I'd say this actually depends on what platform you're on.
If I were on a MIPS or Alpha, I *would* expect the value
to be sign-extended. Why? Because that's how the actual
ABI works with 32-bit pointers on 64-bit hardware.
If we're going to do anything of the sort, I think that
the most useful to honor POINTERS_EXTEND_UNSIGNED, if
defined. What this means for targets that neither sign
nor zero extend, like ia64-hpux, I'm not sure.
I certainly think that testing the result type of the cast,
> + && TREE_UNSIGNED (type))
as you do here, completely confuses the point about how
casting works in C, and is definitely wrong.
r~