This is the mail archive of the gcc-patches@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: [PATCH] Fix PR15791


On Thu, Jan 27, 2005 at 04:25:57PM +0100, Richard Guenther wrote:
> > On Thu, Jan 27, 2005 at 03:57:36PM +0100, Richard Guenther wrote:
> > > + 	  tree addr0, addr1, off0, off1;
> > > + 	  if (TREE_CODE (arg0) == ADDR_EXPR)
> > > + 	    {
> > > + 	      addr0 = arg0;
> > > + 	      off0 = integer_zero_node;
> > > + 	    }
> > > + 	  else
> > > + 	    {
> > > + 	      addr0 = TREE_OPERAND (arg0, 0);
> > > + 	      off0 = TREE_OPERAND (arg0, 1);
> > > + 	    }
> > > + 	  if (TREE_CODE (arg1) == ADDR_EXPR)
> > > + 	    {
> > > + 	      addr1 = arg1;
> > > + 	      off1 = integer_zero_node;
> > > + 	    }
> > > + 	  else
> > > + 	    {
> > > + 	      addr1 = TREE_OPERAND (arg1, 0);
> > > + 	      off1 = TREE_OPERAND (arg1, 1);
> > > + 	    }
> > > + 	  if (operand_equal_p (addr0, addr1, 0))
> > > + 	    return fold (build2 (code, type, off0, off1));
> >
> > Don't both arguments of the compare need to have the
> > same type?  With the above code, you might very well
> > use (int) for one of the operand and likely size_t
> > for the other one.
> 
> I honestly don't know - doesn't build2 handle this?  Also

No.

> this would question the validity of the optimization, no?
> The simplest way to fix this would probably be to check
> for type equality of the offsets.

If both args are PLUS_EXPRs, then they likely will be the
same (and you can of course verify that and don't optimize
if they aren't).
But if one of them is PLUS_EXPR and one is just ADD_EXPR,
you set e.g. off0 to integer_zero_node instead of
build_int_cst (TREE_TYPE (off1), 0).

	Jakub


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