PR 22051

[Jeffrey A Law]

On Sun, 2005-06-26 at 15:52 -0700, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> >>>It's on my list.  What's the timeframe for getting something into
> >>>4.0.1?
> >>
> >>I've held up the release on account of this PR, so, on the one hand, 
> >>there's no risk of shipping before this is fixed; on the other hand, 
> >>it's one of just a few PRs in the way, so sooner is better.
> > 
> > OK.  Sorry I didn't know this was holding up 4.0.1, I'll move it to
> > the front of my queue.  I've got family in town right now, but I ought
> > to be able to get a fix into testing Tuesday.  
> 
> Thanks.  Arguably, we could ship with this problem, but it's broken on 
> PA HP-UX (one of our primary platforms), and it's pretty likely to break 
> real apps, including things like Apache.
Here's the right fix for 22051 as well a closely related problem that
John Anglin has run into (basically the inverse of 22051 where we
introduce a function pointer canonicalization when we should not,
which could lead to rather undesirable behavior).


I still need to cobble up a testcase we can put in the testsuite
for 22051 and its inverse, but I figured getting the patch out and
approved for the 4.0 branch ASAP was more important.


I've bootstrapped and regression tested this on hppa2.0-hp-hpux11.00 as
well as i686-pc-linux-gnu.  I've verified it fixes the problems by
visually inspecting the assembly code (for various reasons the testcase
isn't directly usable on all versions of hpux11) and John Anglin has
verified the test works correctly on hpux11.11.







-------------- next part --------------
	* tree-ssa-dom.c (find_equivalent_equality_comparison): Do not
	a eliminate type conversion which feeds an equality comparison
	if the original type or either operand in the comparison is a
	function pointer. 
	
Index: tree-ssa-dom.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-dom.c,v
retrieving revision 2.94
diff -c -p -r2.94 tree-ssa-dom.c
*** tree-ssa-dom.c	24 Feb 2005 21:47:26 -0000	2.94
--- tree-ssa-dom.c	30 Jun 2005 23:07:18 -0000
*************** find_equivalent_equality_comparison (tre
*** 1929,1934 ****
--- 1929,1946 ----
      {
        tree def_rhs = TREE_OPERAND (def_stmt, 1);
  
+ 
+       /* If either operand to the comparison is a pointer to
+ 	 a function, then we can not apply this optimization
+ 	 as some targets require function pointers to be
+ 	 canonicalized and in this case this optimization would
+ 	 eliminate a necessary canonicalization.  */
+       if ((POINTER_TYPE_P (TREE_TYPE (op0))
+ 	   && TREE_CODE (TREE_TYPE (TREE_TYPE (op0))) == FUNCTION_TYPE)
+ 	  || (POINTER_TYPE_P (TREE_TYPE (op1))
+ 	      && TREE_CODE (TREE_TYPE (TREE_TYPE (op1))) == FUNCTION_TYPE))
+ 	return NULL;
+ 	      
        /* Now make sure the RHS of the MODIFY_EXPR is a typecast.  */
        if ((TREE_CODE (def_rhs) == NOP_EXPR
  	   || TREE_CODE (def_rhs) == CONVERT_EXPR)
*************** find_equivalent_equality_comparison (tre
*** 1942,1947 ****
--- 1954,1969 ----
  	      > TYPE_PRECISION (TREE_TYPE (def_rhs)))
  	    return NULL;
  
+ 	  /* If the inner type of the conversion is a pointer to
+ 	     a function, then we can not apply this optimization
+ 	     as some targets require function pointers to be
+ 	     canonicalized.  This optimization would result in
+ 	     canonicalization of the pointer when it was not originally
+ 	     needed/intended.  */
+ 	  if (POINTER_TYPE_P (def_rhs_inner_type)
+ 	      && TREE_CODE (TREE_TYPE (def_rhs_inner_type)) == FUNCTION_TYPE)
+ 	    return NULL;
+ 
  	  /* What we want to prove is that if we convert OP1 to
  	     the type of the object inside the NOP_EXPR that the
  	     result is still equivalent to SRC.