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: Roger Sayle <roger at eyesopen dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: 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 08:36:33 -0600 (MDT)
- Subject: Re: [patch] builtins.c, fold-const.c: Don't create type mismatches.
Hi Kazu,
On Sat, 16 Apr 2005, Kazu Hirata wrote:
> 2005-04-16 Kazu Hirata <kazu@cs.umass.edu>
>
> PR middle-end/21024
> * builtins.c (expand_builtin_strcat): Convert the result of
> strlen to the right type.
> * fold-const.c (fold_binary) <PLUS_EXPR>: Use fold_convert to
> avoid creating type mismatches.
> <GE_EXPR>: Pass op0 and op1 to fold_build2 to avoid creating
> type mismatches.
This is OK for mainline. Thanks.
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.
Perhaps, Dave Anglin or other maintainers have opinions/suggestions?
Converting "ptr + strlen(ptr)" into "ptr + (char*)strlen(ptr)" in
builtins.c, just appears a little strange at first sight. It might
be reasonable provided the backend and RTL optimizers know how to
transform "convert_to_pointer" follwed by an addition into a
regular offset calculation/addressing mode.
Roger
--