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

[Richard Guenther <rguenther at suse dot de>]

On Tue, 29 Aug 2006, Andrew Haley wrote:

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

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

I agree that this would be not appropriate for stage3.  Though rather
than introducing string-compares, can you either try to eliminate
(the maybe few) places in the java frontend that call fold and are
problematic?  Or in spirit of the C++ frontend workaround make the
check something like

 && ! (!in_gimple_form
       && final_ptr
       && (strcmp (lang_hooks.name, "GNU Java") == 0))

and of course notice that this needs to go for LTO... (like the C++
workaround, too).  Even better would be a flag for this to avoid
the string compare like Ian suggested.

Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs