From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15955 invoked by alias); 17 Feb 2013 00:33:43 -0000 Received: (qmail 15624 invoked by uid 48); 17 Feb 2013 00:33:18 -0000 From: "hp at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/55030] [4.8 Regression]: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os (et al) Date: Sun, 17 Feb 2013 00:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: patch X-Bugzilla-Severity: normal X-Bugzilla-Who: hp at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hp at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 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: 2013-02/txt/msg01711.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55030 --- Comment #12 from Hans-Peter Nilsson 2013-02-17 00:33:17 UTC --- (In reply to comment #10) > I'm getting back to this because I think that we should reinstate the original > patch, now that the blockage patch has been installed. *wake-up reactions* > I have run into the same issue as your original issue with a private port on > the 4.7 branch: the clobber causes the restoring of the frame pointer to be > deleted > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01172.html > Later reload allocates a stack slot to a pseudo that is set before the setjmp > and used after, but the frame pointer doesn't have a consistent value... Yup, this far I remember. > Clearly the frame pointer needs to be restored so the clobber is wrong. It was > there because the final blockage wasn't blocking enough, but the blockage patch > is supposed to have fixed that. I've lost track. What was "the original patch", what do you mean by "the blockage patch" (that has been installed) and I'm pretty sure there were several follow-up patches, so I can't say I'm confident about reverting something from just this subset. (To wit: if it's something that causes volatile asms to again be treated different from (other) blockages, then that's wrong, as a volatile asm is the default blockage.) Can you please a candidate (reverting?) patch gcc-patches@ *and CC me* (I'm far behind on reading gcc lists).