[PATCH] Fix PR27529, a step towards fixing PR27039

[Richard Guenther]

On Tue, 29 Aug 2006, Andrew Haley wrote:

> 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?
>  > 
>  > Thanks,
>  > Richard.
>  > 
>  > :ADDPATCH middle-end:
>  > 
>  > 2006-05-10  Richard Guenther  <rguenther@suse.de>
>  > 
>  > 	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
> some cases.

Uh, but then why does the frontend generate NOP_EXPR or CONVERT_EXPRs for
this?  I guess a java-specific conversion tree code would be the better
fix, and lowering that to middle-end representation by making the
"code generated" explicit.

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?

Thanks for clarifying,
Richard.

> @@ -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));
>  	}

This, of course, looks not acceptable.

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