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

[Ian Lance Taylor <iant at google dot com>]

Andrew Haley <aph@redhat.com> writes:

> 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.
> 
> In the past, this optimization was disallowed if the final type was a
> pointer.
> 
> So, we have a case where the generic folder is affected by the C
> language assumption that pointer type conversions don't do anything.
> I can work round this problem by carefully not calling fold() in some
> cases, but that is very fragile.
> 
> Patching fold_unary() is much more robust, but is rather gaggy.
> 
> Andrew.
> 
> 
> 2006-08-29  Andrew Haley  <aph@redhat.com>
> 
> 	* fold-const.c (fold_unary): Dont fold (t1)(t2) to (t1) if this is
> 	a Java program.

Um, no.  Adding language dependencies to the middle-end is very much
the wrong way to go.

In general we need to move toward language-independent semantics in
the middle-end.  So the choices I see are:
1) Remove this particular folding for all languages.
2) Have Java mark pointers in some language independent way that
   fold_unary can test.
3) Add a global variable or parameter front_end_fold and check that
   before applying this sort of fold.
4) Separate fold into a front-end-safe version and a middle-end
   version which does more.

None of these options are especially palatable.  Can you give more
details about when Java needs to generate code for pointer
conversions?  Does this requirement disappear after gimplification?

Ian