This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR27529, a step towards fixing PR27039
Richard Guenther writes:
> On Tue, 29 Aug 2006, Andrew Haley wrote:
>
> > Richard Guenther writes:
> > >
> > > This fixes a missing folding opportunity in the presence of casts of
> > > pointers with intermediate cast to integer and vice versa. This is needed
> > > to not regress in the testsuite if fixing PR27039 by always folding of
> > > pointer comparisons in signed size type.
> > >
> > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > > Ok for mainline?
> > >
> > > Thanks,
> > > Richard.
> > >
> > > :ADDPATCH middle-end:
> > >
> > > 2006-05-10 Richard Guenther <rguenther@suse.de>
> > >
> > > PR middle-end/27529
> > > * fold-const.c (fold_unary): Handle intermediate conversion
> > > to a pointer type like intermediate conversion to an integer
> > > type in folding of (T1)(T2)var to var.
> > > Match the code to the comment in the final conversion for
> > > (T1)(T2)var to (T1)var regarding to type precision. Rather
> > > than disallow T1 being of pointer type, assert that both T1
> > > and var are of pointer type or not. Make sure not to fall
> > > over the frontends lazyness wrt array to pointer decay though.
> > >
> > > * gcc.dg/tree-ssa/foldcast-1.c: New testcase.
> >
> > This breaks Java.
> >
> > The problem is that, as well as folding (ptrtype)(intttype)ptr, this
> > patch also folds (ptrtype1)(ptrtype2)ptr to (ptrtype1)ptr. This is
> > wrong for Java, because the conversion to ptrtype2 generates code in
> > some cases.
>
> Uh, but then why does the frontend generate NOP_EXPR or
> CONVERT_EXPRs for this? I guess a java-specific conversion tree
> code would be the better fix, and lowering that to middle-end
> representation by making the "code generated" explicit.
Why not? The idea that CONVERT_EXPR doesn't generate code is clearly
false: in many cases, such as floating-point conversions, it does
generate code.
Some languages generate code for pointer type conversions and some
languages don't. As far as I am aware, fold() doesn't necessarily
assume only C language semantics for all its conversions.
> Or am I missing something?
>
> Note that STRIP_NOPS and tree_ssa_useless_type_conversion removes
> this chains of conversions, too. Or are you only concerned about
> the cases where you call fold () from inside the frontend?
Exactly right. By the time we get to STRIP_NOPS and
tree_ssa_useless_type_conversion, we have inserted checks where we
need them. fold is special in that it works on language-specific
trees rather than GIMPLE.
> Thanks for clarifying,
> Richard.
>
> > @@ -7399,7 +7401,9 @@
> > && final_ptr == inside_ptr
> > && ! (inside_ptr
> > && TREE_CODE (TREE_TYPE (inside_type)) == ARRAY_TYPE
> > - && TREE_CODE (TREE_TYPE (type)) != ARRAY_TYPE))
> > + && TREE_CODE (TREE_TYPE (type)) != ARRAY_TYPE)
> > + && ! ((strcmp (lang_hooks.name, "GNU Java") == 0)
> > + && final_ptr))
> > return fold_build1 (code, type, TREE_OPERAND (op0, 0));
> > }
>
> This, of course, looks not acceptable.
Me either. However, there is some remarkably similar code in
fold_cond_expr_with_comparison().
Andrew.