This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 2 Apr 2010 12:33:34 -0000
- Subject: [Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)
- References: <bug-42509-11764@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #22 from rguenth at gcc dot gnu dot org 2010-04-02 12:33 -------
Or a combination of both. In particular the code doesn't account for
the negative offsets we offset the spill-slot decl with when trying to
handle a NULL MEM_OFFSET conservatively.
I wonder what sizex / sizey is for the spill-slot-decl, or rather what
mode or size it has ...
Least pessimizing patch follows, it looks like nobody else would
disambiguate spill slots otherwise (apart from the tree oracle calls).
Index: gcc/alias.c
===================================================================
--- gcc/alias.c (revision 157942)
+++ gcc/alias.c (working copy)
@@ -2147,6 +2147,13 @@ nonoverlapping_memrefs_p (const_rtx x, c
if (exprx == 0 || expry == 0)
return 0;
+ /* For spill-slot accesses make sure we have valid offsets. */
+ if ((exprx == get_spill_slot_decl (false)
+ && ! MEM_OFFSET (x))
+ || (expry == get_spill_slot_decl (false)
+ && ! MEM_OFFSET (y)))
+ return 0;
+
/* If both are field references, we may be able to determine something. */
if (TREE_CODE (exprx) == COMPONENT_REF
&& TREE_CODE (expry) == COMPONENT_REF
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509