This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR27529, a step towards fixing PR27039
- From: Andrew Haley <aph at redhat dot com>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 29 Aug 2006 16:00:02 +0100
- Subject: Re: [PATCH] Fix PR27529, a step towards fixing PR27039
- References: <Pine.LNX.email@example.com>
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?
> :ADDPATCH middle-end:
> 2006-05-10 Richard Guenther <firstname.lastname@example.org>
> 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
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 <email@example.com>
* fold-const.c (fold_unary): Dont fold (t1)(t2) to (t1) if this is
a Java program.
--- fold-const.c (revision 116343)
+++ fold-const.c (working copy)
@@ -7384,6 +7384,8 @@
- the final type is a pointer type and the initial type not
- the initial type is a pointer to an array and the final type
+ /* Java pointer type conversions generate checks in some
+ cases, so we explicitly disallow this optimization. */
if (! inside_float && ! inter_float && ! final_float
&& ! inside_vec && ! inter_vec && ! final_vec
&& (inter_prec >= inside_prec || inter_prec >= final_prec)
@@ -7399,7 +7401,9 @@
&& final_ptr == inside_ptr
&& ! (inside_ptr
&& TREE_CODE (TREE_TYPE (inside_type)) == ARRAY_TYPE
- && TREE_CODE (TREE_TYPE (type)) != ARRAY_TYPE))
+ && TREE_CODE (TREE_TYPE (type)) != ARRAY_TYPE)
+ && ! ((strcmp (lang_hooks.name, "GNU Java") == 0)
+ && final_ptr))
return fold_build1 (code, type, TREE_OPERAND (op0, 0));