From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 301 invoked by alias); 17 Jun 2012 15:36:35 -0000 Received: (qmail 32631 invoked by uid 22791); 17 Jun 2012 15:36:33 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,TW_TX X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 17 Jun 2012 15:36:21 +0000 From: "matz at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/53705] wrong code with custom flags - stores to memory are lost Date: Sun, 17 Jun 2012 15:36:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: matz at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-06/txt/msg01121.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705 --- Comment #2 from Michael Matz 2012-06-17 15:36:19 UTC --- Or alternatively cselib doesn't respect one invariant in constructing the locations of its VALUEs. As seen above it constructs two values for the same memory area, one referring to stack pointer, the other to (hard) frame pointer. But alias.c explains: 2. stack_pointer_rtx, frame_pointer_rtx, hard_frame_pointer_rtx (if distinct from frame_pointer_rtx) and arg_pointer_rtx. Each of these rtxes has a separate ADDRESS associated with it, each with a negative id. GCC is (and is required to be) precise in which register it chooses to access a particular region of stack. We can therefore assume that accesses based on one of these rtxes do not alias accesses based on another of these rtxes. Note the last paragraph. The RTL instructions themself respect this invariant (there are no accesses via [sp], only via [bp] or derived values). But the cselib values don't. I'd say value 5 (the one referring to sp and value 2) is the broken one. It should only refer to value 2.