This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] builtins.c, fold-const.c: Don't create type mismatches.
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Kazu Hirata <kazu at cs dot umass dot edu>, gcc-patches at gcc dot gnu dot org, dnovillo at redhat dot com, dan at codesourcery dot com, John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Date: Sat, 16 Apr 2005 19:19:37 -0400
- Subject: Re: [patch] builtins.c, fold-const.c: Don't create type mismatches.
- References: <Pine.LNX.4.44.0504160817320.20291-100000@www.eyesopen.com>
> I believe that Dan Berlin is currently working on a semantics document
> for GCC's tree codes. It might be worthwhile checking his proposed
> semantics for "ptr + C". Your builtins.c change above seems to suggest
> that PLUS_EXPR *always* has operands of the same type as its' result.
> For "pointer + integer" addition it isn't clear that enforcing this as
> a "pointer + pointer" addition is always a good idea. Especially on
> targets such as PA/HP-UX where integer<->pointer conversion isn't a
> no-op, and accurately tracking REG_POINTER improves code quality.
>
I also should note that the MEM_REF stuff that is scheduled for stage2
would obviate the need for supporting ptr + integer directly, at least
when it comes to
*ptr++, ptr[i], and friends
It's a generic dereference operation, taking a pointer and an integer
index, and returning *(ptr + (index * sizeof(*ptr))).
Of course, my main motivation for MEM_REF was to get rid of incredibly
ugly casts that come along with pointer addition and then dereference,
and to try to keep "array-like" accesses on pointers looking like them
for as long as possible.
--Dan