From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61922 invoked by alias); 10 Jun 2015 15:46:40 -0000 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 Received: (qmail 61839 invoked by uid 48); 10 Jun 2015 15:46:34 -0000 From: "bernhard.kaindl at thalesgroup dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux Date: Wed, 10 Jun 2015 15:46: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-Version: 5.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: bernhard.kaindl at thalesgroup dot com X-Bugzilla-Status: SUSPENDED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-06/txt/msg00959.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 Bernhard Kaindl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhard.kaindl@thalesgroup | |.com --- Comment #20 from Bernhard Kaindl --- For people reviewing this, I want to summarize: Eric submitted a fix for this and explains it [required read]: https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01200.html The archive has no objections and Richard Biener said: Looks reasonable to me. The basic bug is that gcc does not eliminate the load of e[2837] (which is dead code) right way - which may never be reached since b is limited to < 2: for (; b < 2; b++) { a = 0; if (b == 2837) a = e[b]; As written in Comment 3: > Note how the load at insn 28 is guarded by comparing ax against #2837. CE3 > transforms that into an unconditional load and we blow up reading the > out-of-range stack slot. As far as I understand: The patch fixes a bug in rtx_addr_can_trap_p_1() which is called to check if an access can trap, where the bug is that rtx_addr_can_trap_p_1() does not take the offset of the object (in this case e[2837]) into account, and returns the info that the access is safe, which it is not, because it is out of bounds (and out of the stack too) The patch only fixes the wrong information returned by this function that the access is safe by returning 1 when the offset causes the access to be outside of the stack. So this patch fixes a clear bug which leads to wrong code generated by gcc. I think that the patch is clear in scope, only fixes a specific case unless rtx_addr_can_trap_p_1() was refactored, it should be feasible to apply to trunk, 5.1 and 4.9.