From patchwork Mon Apr 29 20:13:33 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve Ellcey X-Patchwork-Id: 240498 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id E174F2C00CC for ; Tue, 30 Apr 2013 06:13:59 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; q=dns; s= default; b=LCLmqYUJnbRV4DDQEPTOKrMIDr45UGcJc2P9PvC46e/I6oxajxBuS kQ0oPcT1SMjQSp1u6hq1BSHrToE+vaPVrcJ9od2/xGQJ/85oNCe25+B1CtJK3pJ4 mioHIZXXGDJvSCwjpHpxTExGjuRRzmmAnL7zBBu+09xBsom8UViOPI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s=default; bh=onBJdh7L2V+oFwQ9wf8QLNRgrKM=; b=bwUjJXKURkfyldVwNYgWNBKeIKU2 1iwdTgNAcxS1VMF8ccpA8VOyTvCq0ruMoBIYIXw5Txae9ZXNrQqgJoc7kYm0P9wx kHlWvJFxP9qiVyZS1IgkAo/QvnAJ981lpK1d198NRwvajxcLX0VgjmuPxuKnHm0u stoduUjEQQ/DMTw= Received: (qmail 2473 invoked by alias); 29 Apr 2013 20:13:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 2463 invoked by uid 89); 29 Apr 2013 20:13:53 -0000 X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL, BAYES_00, KHOP_THREADED, RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from multi.imgtec.com (HELO multi.imgtec.com) (194.200.65.239) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 29 Apr 2013 20:13:51 +0000 Subject: Re: [patch, mips] Fix for PR target/56942 From: Steve Ellcey To: Richard Sandiford CC: , , In-Reply-To: <87ehdwiezi.fsf@talisman.default> References: <2c243f55-9b58-4e4a-86cf-9dd5be8ea183@BAMAIL02.ba.imgtec.org> <87sj2gifze.fsf@talisman.default> <1367016105.1650.43.camel@ubuntu-sellcey> <87ehdwiezi.fsf@talisman.default> Date: Mon, 29 Apr 2013 13:13:33 -0700 Message-ID: <1367266413.8625.3.camel@ubuntu-sellcey> MIME-Version: 1.0 X-SEF-Processed: 7_3_0_01181__2013_04_29_21_13_48 On Sat, 2013-04-27 at 08:56 +0100, Richard Sandiford wrote: > >> But using next_real_insn was at least as correct (IMO, more correct) > >> as next_active_insn before r197266. It seems counterintuitive that > >> something can be "active" but not "real". > >> > >> Richard > > > > So should we put the active_insn_p hack/FIXME into real_next_insn? That > > doesn't seem like much of a win but it would probably fix the problem. > > Yeah, I think so. If "=>" mean "accepts more than", then there used > to be a nice total order: > > next_insn > => next_nonnote_insn > => next_real_insn > => next_active_insn > > I think we should keep that if possible, even during the transition period. > > Thanks, > Richard OK, here is patch to next_real_insn to keep the ordering property intact and fix the bug. OK for checkin? Steve Ellcey sellcey@imgtec.com 2013-04-29 Andrew Bennett Steve Ellcey PR target/56942 * emit-rtl.c (next_real_insn): Accept jump table data as 'real' (like next_active_insn does). diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c index 538b1ec..9de3f1e 100644 --- a/gcc/emit-rtl.c +++ b/gcc/emit-rtl.c @@ -3248,7 +3248,8 @@ next_real_insn (rtx insn) while (insn) { insn = NEXT_INSN (insn); - if (insn == 0 || INSN_P (insn)) + if (insn == 0 || INSN_P (insn) + || JUMP_TABLE_DATA_P (insn)) /* FIXME */ break; }