This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [FORTRAN mainline] dereference POINTER_PLUS_EXPR check (was tuples)
On Nov 22, 2007 6:23 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
> On Wed, Nov 21, 2007 at 05:09:22PM -0800, Andrew Pinski wrote:
> > On 11/21/07, Aldy Hernandez <aldyh@redhat.com> wrote:
> > > u_t_c(lhs_type, rhs1_type) fails because it doesn't look far enough
> > > down, but you're saying it shouldn't. Is u_t_c wrong then?
> >
> > No it is correct. So we have char* = char[]& . That is incorrect
> > where are the cast or address expression.
>
> Thanks for the help guys.
>
> The culprit is the fortran FE which is building a P_P_E with no regards
> to type. The patch below uses [void *] when building BUILT_IN_MEMSET.
> It has been tested on x86-linux, with no regressions on the Fortran test
> cases.
It should use the type of DEST, all pointers are trivially convertible
to void *,
which is the formal argument of memset (in the ChangeLog you have memmove).
Not that it makes a big difference here (in the end we try to be type-exact in
one expression tree, but as the expression result type will vanish with tuples,
there won't a difference for both cases).
I wonder if the problem you see has been fixed with the fix for PR31608 which
went in a few days ago?
Richard.
> OK for *mainline*, as it suffers from the same problem?
>
> Aldy
>
> * fortran/trans-expr.c (gfc_trans_string_copy): Use "void *" * when
> building a memmove.
>
> === fortran/trans-expr.c
> ==================================================================
> --- fortran/trans-expr.c (revision 130317)
> +++ fortran/trans-expr.c (local)
> @@ -2701,7 +2701,7 @@
> tmp3 = build_call_expr (built_in_decls[BUILT_IN_MEMMOVE],
> 3, dest, src, slen);
>
> - tmp4 = fold_build2 (POINTER_PLUS_EXPR, pchar_type_node, dest,
> + tmp4 = fold_build2 (POINTER_PLUS_EXPR, ptr_type_node, dest,
> fold_convert (sizetype, slen));
> tmp4 = build_call_expr (built_in_decls[BUILT_IN_MEMSET], 3,
> tmp4,
>
>