From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77935 invoked by alias); 7 Dec 2015 19:44:06 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 77919 invoked by uid 89); 7 Dec 2015 19:44:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Dec 2015 19:44:04 +0000 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Websense Email Security Gateway with ESMTPS id 7D78724776D36; Mon, 7 Dec 2015 19:43:58 +0000 (GMT) Received: from BAMAIL02.ba.imgtec.org (10.20.40.28) by hhmail02.hh.imgtec.org (10.100.10.20) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Dec 2015 19:44:02 +0000 Received: from [10.20.3.214] (10.20.3.214) by bamail02.ba.imgtec.org (10.20.40.28) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 7 Dec 2015 11:44:00 -0800 Message-ID: <1449517439.4788.91.camel@ubuntu-sellcey> Subject: Re: [Patch] Fix bug for frame instructions in annulled delay slots From: Steve Ellcey Reply-To: To: Bernd Schmidt CC: Date: Mon, 07 Dec 2015 19:44:00 -0000 In-Reply-To: <5665DDCB.5070003@redhat.com> References: <5665DDCB.5070003@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-SW-Source: 2015-12/txt/msg00789.txt.bz2 On Mon, 2015-12-07 at 20:28 +0100, Bernd Schmidt wrote: > On 12/07/2015 07:54 PM, Steve Ellcey wrote: > > if (must_annul) > > - used_annul = 1; > > + { > > + /* Frame related instructions cannot go into annulled delay > > + slots, it messes up the dwarf info. */ > > + if (RTX_FRAME_RELATED_P (trial)) > > + return; > > Don't you need to use break rather than return? I am not sure about this. There is an earlier if statement in the loop that does a 'return' instead of a break (or continue) and there is a return in the 'else' part of the if that sets must_annul. Both of these are inside the loop that looks at all the instructions in the sequence 'seq'. I think the code is looking at all the instructions in the sequence and if any of them fail one of the tests in the loop (in this case require annulling) then we can't handle any of the instructions in the sequence and so we return immediately without putting any of the instructions from 'seq' in the delay slot. I believe a frame related instruction in an annulled branch needs to be handled that way too. > > > + else if (!RTX_FRAME_RELATED_P (trial) \ > > Stray backslash. That is easily fixed. > Other than that I think this is OK. There are some preexisting tests for > frame related insns already in this code. > > > Bernd >