This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: More fun with aliasing - removing assignments?


On Mon, Aug 01, 2005 at 10:12:37PM -0700, Ian Lance Taylor wrote:
> Harald van D??k <truedfx@gentoo.org> writes:
> 
> > I finally managed to track down the problem I've been having to this
> > short code:
> > 
> > 	typedef struct {
> > 	    unsigned car;
> > 	    unsigned cdr;
> > 	} cons;
> > 
> > 	void nconc (unsigned x, unsigned y) {
> > 	    unsigned *ptr = &x;
> > 	    while(!(*ptr & 3))
> > 	        ptr = &((cons *)(*ptr))->cdr;
> > 	    *ptr = y;
> > 	}
> > 
> > With gcc 4.0-20050728 on i686-pc-linux-gnu, compiling this with -O2
> > appears to remove the assignment to *ptr. (I didn't prepare an example
> > program, but it's verifiable with objdump.) Obviously, this code is
> > non-portable, but still, I don't see why this can happen. Would anyone
> > be kind enough to explain this to me? It works as expected with -O2
> > -fno-strict-aliasing.
> 
> Well, I'd say it's a bug.  It works in 4.1.  The final assignment gets
> removed by tree-ssa-dce.c because it looks like a useless store.  This
> is because alias analysis thinks it knows what is going on, when it
> clearly does not.
> 
Are you sure?  I am not a language lawyer, but my understanding
is that you cannot legally make pointer 'p' point outside of
'x' using pointer arithmetic.  Since 'x' is a PARM_DECL passed by
value, the last assignment is a dead store.

In this case, 'ptr' should be marked as pointing anywhere.
However, alias analysis could also conclude that 'ptr' may not
point outside the current local frame.  So, the last store would
still be marked dead.

This distinction of different meanings for "points anywhere" will
be a feature of 4.2, most likely.

Having said that, I sent rth a 4.0 patch for a similar bug that
will "fix" this problem.  Richard, have you applied it yet?



	* tree-ssa-alias.c (add_pointed_to_var): If VALUE is of
	the form &(*PTR), take points-to information from PTR.

Index: tree-ssa-alias.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v
retrieving revision 2.71.2.1
diff -d -u -p -r2.71.2.1 tree-ssa-alias.c
--- tree-ssa-alias.c	26 Feb 2005 16:24:27 -0000	2.71.2.1
+++ tree-ssa-alias.c	21 Jul 2005 20:13:44 -0000
@@ -1904,7 +1904,11 @@ add_pointed_to_var (struct alias_info *a
   if (REFERENCE_CLASS_P (pt_var))
     pt_var = get_base_address (pt_var);
 
-  if (pt_var && SSA_VAR_P (pt_var))
+  if (pt_var == NULL)
+    {
+      pi->pt_anything = 1;
+    }
+  else if (SSA_VAR_P (pt_var))
     {
       uid = var_ann (pt_var)->uid;
       bitmap_set_bit (ai->addresses_needed, uid);
@@ -1918,6 +1922,18 @@ add_pointed_to_var (struct alias_info *a
       if (is_global_var (pt_var))
 	pi->pt_global_mem = 1;
     }
+  else if (TREE_CODE (pt_var) == INDIRECT_REF
+           && TREE_CODE (TREE_OPERAND (pt_var, 0)) == SSA_NAME)
+    {
+      /* If VALUE is of the form &(*P_j), then PTR will have the same
+	 points-to information as P_j.  */
+      add_pointed_to_expr (ai, ptr, TREE_OPERAND (pt_var, 0));
+    }
+  else
+    {
+      /* Give up.  PTR points anywhere.  */
+      set_pt_anything (ptr);
+    }
 }


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]