Re: [PATCH] Fix PR27529, a step towards fixing PR27039

[Andrew Haley <aph at redhat dot com>]

Richard Guenther writes:
 > On Tue, 29 Aug 2006, Andrew Haley wrote:
 > 
 > > 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).

Well, that's a far tighter requirement than was the case at the time
gcj was written.  The assumption then was that fold worked on
front-end trees, and (of course) there were no middle-end trees.  

Ideally, we'd have a real language-independent fold().

 > >  > 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.

I'm not surprised that you prefer such a fix.  However, I hope that
you are also able to understand my point of view.

I can see the logic of this.  I'd still want fold to see through
CHECKED_CONVERT_EXPR to the extent that 
fold (build (CHECKED_CONVERT_EXPR, t, exp)) would return exp if it
were already of type t.

I would rather not be performing such major surgery to the Java
language front-end at this point in the development cycle.  It seems
like a reasonable thing do do in Stage 1, though.

Andrew.