This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR27529, a step towards fixing PR27039
- From: Ian Lance Taylor <iant at google dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Richard Guenther <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org
- Date: 29 Aug 2006 08:17:52 -0700
- Subject: Re: [PATCH] Fix PR27529, a step towards fixing PR27039
- References: <Pine.LNX.email@example.com> <firstname.lastname@example.org>
Andrew Haley <email@example.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
> 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.
> 2006-08-29 Andrew Haley <firstname.lastname@example.org>
> * 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?