From patchwork Fri Apr 5 06:54:48 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrey Belevantsev X-Patchwork-Id: 234055 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 522032C009B for ; Fri, 5 Apr 2013 17:55:01 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=WiQ1MScXfLkL5qkoE BtEr9pQIt7t9GzAZMmThQ1z/+8BaRWQg6EAulp2WRJVGT3CPap1LxumTd+LFVzH0 FJae7sv2aBEbsSBHD1ZPXRM6fkWPwmDlJOcJwgU2brT5pnKknvNmJuhlyV33dGVu us92SS4SYFjxnJ/DyPR8U61p6E= 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 :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=/XVuurGAg0yvEpBaBgyJmsb iC/Y=; b=oC9695GG044GLsZfPq+8ZAknI5YNY8lzeaj+vIj3tyUXQy61ab89+zI qeQush8uTC7YQeGMBE8V6olUD9lKjZfkHGTmmrpUt6/IJUb82LfkT8q3F+R4N3hu xa1aJkVPeihfOdCPJey+7NFHp5xgmGBnar83awhWY7lSXzfHQrgM= Received: (qmail 15271 invoked by alias); 5 Apr 2013 06:54:52 -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 15262 invoked by uid 89); 5 Apr 2013 06:54:51 -0000 X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL, BAYES_00, KHOP_THREADED, RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from mail.ispras.ru (HELO mail.ispras.ru) (83.149.199.45) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 05 Apr 2013 06:54:47 +0000 Received: from [10.10.3.52] (pluton2.ispras.ru [83.149.199.44]) by mail.ispras.ru (Postfix) with ESMTPSA id BF604540156; Fri, 5 Apr 2013 10:54:44 +0400 (MSK) Message-ID: <515E7538.4070408@ispras.ru> Date: Fri, 05 Apr 2013 10:54:48 +0400 From: Andrey Belevantsev User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: GCC Patches CC: Jakub Jelinek , Leonid Lisovskiy Subject: Re: Fix PR 56077 References: <512772F5.3040007@ispras.ru> <51594783.2050600@ispras.ru> In-Reply-To: <51594783.2050600@ispras.ru> X-Virus-Found: No On 01.04.2013 12:38, Andrey Belevantsev wrote: > On 22.02.2013 17:30, Andrey Belevantsev wrote: >> Hello, >> >> As found by Jakub and explained in the PR audit trail by Alexander, this >> patch fixes the selective scheduler merge glitch of 2008 that added the >> unnecessary JUMP_P check to the flush_pending_lists call. I have removed >> the check and expanded the binary negation for clarity. >> >> The patch was tested on x86-64, ia64, and ppc64 to be safe. The patch >> should be conservatively safe at this stage as it adds more flushes and >> thus more dependencies to the scheduler. The original test is fixed, but I >> don't know how to add the test checking assembly insns order to the >> testsuite. >> >> OK for trunk? >> >> Andrey >> >> 2012-02-22 Alexander Monakov >> Andrey Belevantsev >> >> PR middle-end/56077 >> * sched-deps.c (sched_analyze_insn): When reg_pending_barrier, >> flush pending lists also on non-jumps. > > Now backported to 4.7 and 4.6. Leonid has reported that this patch breaks the kernel build on mipsel-linux. I have quickly analyzed the issue. The patch removes the JUMP_P check when flushing pending lists at the reg_pending_barrier, restoring the 2008 year behavior. But at that time we didn't have debug insns. Now with the removed check we flush pending lists also on debug insns, which results in freeing pending_read_mems but not in freeing pending_read_insns, as in add_dependence_list_and_free we explicitly forbid freeing the dependency list for debug insns (that was for fixing PR 44013). This is inconsistent, and when proceeding with analysis we immediately hit 2451 t = canon_rtx (t); 2452 pending = deps->pending_read_insns; 2453 pending_mem = deps->pending_read_mems; 2454 while (pending) 2455 { 2456 if (read_dependence (XEXP (pending_mem, 0), t) and the line 2456 segfaults because pending is not NULL, but pending mem is NULL. I am testing the revert of this backport for 4.6 and will commit it in about an hour or so. However, I am surprised we don't hit this either on 4.7, 4.8 or trunk. Some flush_pending_lists calls are protected from debug insns as they check CALL_P or JUMP_P, but not all of them. It looks like flush_pending_lists should not be called on debug insns at all. And indeed, the attached patch fixes Leonid's test case. Jakub, you don't happen to remember any changes in this area that could hide the problem for 4.7 and later? Andrey Index: gcc/sched-deps.c =================================================================== *** gcc/sched-deps.c (revision 197492) --- gcc/sched-deps.c (working copy) *************** sched_analyze_insn (struct deps_desc *de *** 3044,3050 **** /* Don't flush pending lists on speculative checks for selective scheduling. */ ! if (!sel_sched_p () || !sel_insn_is_speculation_check (insn)) flush_pending_lists (deps, insn, true, true); if (!deps->readonly) --- 3044,3050 ---- /* Don't flush pending lists on speculative checks for selective scheduling. */ ! if (NONDEBUG_INSN_P (insn) && (!sel_sched_p () || !sel_insn_is_speculation_check (insn))) flush_pending_lists (deps, insn, true, true); if (!deps->readonly)