From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27075 invoked by alias); 2 Apr 2010 12:33:53 -0000 Received: (qmail 26890 invoked by uid 48); 2 Apr 2010 12:33:34 -0000 Date: Fri, 02 Apr 2010 12:33:00 -0000 Message-ID: <20100402123334.26889.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression) In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenth at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00204.txt.bz2 ------- 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