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]

[PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions


This was a latent bug unmasked by the fix for PR28690. It causes libgcj to fail on MIPS.

To quote from Richard Sandiford in comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519#c5

The wrapping check was added by:

http://gcc.gnu.org/ml/gcc-patches/2002-10/msg00360.html

I think this check is wrong for exactly the reason seen here;
without type information, and without context, there's no
guarantee that the PLUS itself is a pointer, or indeed that
the constant was originally positive.  We could only do
something like this if we know the address is being
dereferenced -- but in that case, we generally care about
whether the value might trap, not whether it's zero
(and rtlanal.c rightly says that (plus reg (const_int ...))
can trap).

For example, something like:

(uintptr_t) foo == 0x90000000

could legitimately be implemented as:

(eq (plus foo (const_int 0x70000000)) (const_int 0))

And AIUI, gcc allows things like:

(uintptr_t) foo - 0x90000000

and allows the result to be zero (assuming the result is not
dereferenced).

All uses of nonzero_address_p appear to using it for
general rtx simplification, i.e. in cases where the value
is not known to be a pointer.  So I think this check should
just be removed.

Hopefully the check is less important now than it was when
it was originally committed.  This sort of optimisation can
be done at the tree level instead.

The fix, as Richard indicated is to remove the check for values wrapping.


Bootstrapped and regression tested with all default languages on i686-pc-linux-gnu.

Bootstrapped with c,c++, and java on mipsel-linux-gnu, testing in progress.
Both on gcc-4_2-branch.

If mips test is ok,

OK to commit to 4.2 and mainline?

An alternative would be to revert the patch for PR28690 and re-mask the problem.

Thanks,
David Daney

:ADDPATCH middle-end:


2006-10-22 Richard Sandiford <richard@codesourcery.com> David Daney <ddaney@avtrex.com>

       PR middle-end/29519
       * rtlanal.c (nonzero_address_p):  Remove check for values wrapping.



Index: rtlanal.c
===================================================================
--- rtlanal.c	(revision 117947)
+++ rtlanal.c	(working copy)
@@ -368,17 +368,7 @@
 
     case PLUS:
       if (GET_CODE (XEXP (x, 1)) == CONST_INT)
-	{
-	  /* Pointers aren't allowed to wrap.  If we've got a register
-	     that is known to be a pointer, and a positive offset, then
-	     the composite can't be zero.  */
-	  if (INTVAL (XEXP (x, 1)) > 0
-	      && REG_P (XEXP (x, 0))
-	      && REG_POINTER (XEXP (x, 0)))
-	    return true;
-
-	  return nonzero_address_p (XEXP (x, 0));
-	}
+        return nonzero_address_p (XEXP (x, 0));
       /* Handle PIC references.  */
       else if (XEXP (x, 0) == pic_offset_table_rtx
 	       && CONSTANT_P (XEXP (x, 1)))

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