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
On Tue, 29 Aug 2006, Andrew Haley wrote:
> 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.
Consensus is to merge NOP_EXPR and CONVERT_EXPR and get rid of one
making it a conversion that does not create code. For FP conversions
we have FIX_*_EXPR, FLOAT_EXPR - it is true that we use a NOP_EXPR for
converting float to double, so we would need to introduce tree codes
along the rtl ones FLOAT_EXTEND and FLOAT_TRUNCATE.
> 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.
fold() assumes middle-end semantics (which appearantly match C language
semantics very close).
> > 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.
So you can use a java tree code for these conversions instead of using
CONVERT_EXPR - this would be clearly the preferred fix.
> Me either. However, there is some remarkably similar code in
> fold_cond_expr_with_comparison().
Yay :/
Richard.
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs