From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 472 invoked by alias); 11 Feb 2009 07:09:29 -0000 Received: (qmail 402 invoked by uid 48); 11 Feb 2009 07:09:12 -0000 Date: Wed, 11 Feb 2009 07:09:00 -0000 Message-ID: <20090211070912.401.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ubizjak at gmail dot com" 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: 2009-02/txt/msg00948.txt.bz2 ------- Comment #15 from ubizjak at gmail dot com 2009-02-11 07:09 ------- (In reply to comment #12) > I didn't get around to commenting on the patch; I'll just note that it is > conservative. We don't have to block every instruction, just those which use > memory. True, but as described in the gcc-patches@ mailing list, this situation should not happen often. OTOTH, if there is some standard way to insert memory blockage no-ops, we can use these instead of unspec_volatile. > Do we have to worry about the function epilogue? I don't see any reason why > the scheduler would move any of the pop instructions ahead of something which > references off of %rbp. But I also don't see anything which explicitly > prevents that from happening. We should also add blockage there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118