From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96783 invoked by alias); 29 Mar 2017 20:35:35 -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 96769 invoked by uid 89); 29 Mar 2017 20:35:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sigh, million X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Mar 2017 20:35:33 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 80A5CC05AA42; Wed, 29 Mar 2017 20:35:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 80A5CC05AA42 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 80A5CC05AA42 Received: from localhost.localdomain (ovpn-116-218.phx2.redhat.com [10.3.116.218]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1578E84702; Wed, 29 Mar 2017 20:35:33 +0000 (UTC) Subject: Re: [PATCH] combine: Fix PR80233 To: Segher Boessenkool , gcc-patches@gcc.gnu.org References: Cc: jakub@redhat.com From: Jeff Law Message-ID: Date: Wed, 29 Mar 2017 20:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg01495.txt.bz2 On 03/29/2017 12:23 PM, Segher Boessenkool wrote: > If combine has added an unconditional trap there will be a new basic > block as well. It will then end up considering the NOTE_INSN_BASIC_BLOCK > as the last_combined_insn, but then it tries to take the DF_INSN_LUID > of that and that dereferences a NULL pointer (since such a note is not > an INSN_P). > > This fixes it by not taking non-insns as last_combined_insn. > > Bootstrapped and tested on powerpc64-linux {-m32,-m64}. > > > Segher > > > 2017-03-29 Segher Boessenkool > > PR rtl-optimization/80233 > * combine.c (combine_instructions): Only take NONDEBUG_INSN_P insns > as last_combined_insn. Do not test for BARRIER_P separately. > > gcc/testsuite/ > PR rtl-optimization/80233 > * gcc.c-torture/compile/pr80233.c: New testcase. No strong opinions on this vs Jakub's patch. I guess yours may walk more objects on the chain, but in doing so is more likely to find a useful LAST_COMBINED_INSN. Jakub's stops earlier, but is less likely to have stopped on something useful. Your call Segher. jeff ps. Never in a million years would I have expected isolation of division by zero to have exposed as many latent issues as it has. Sigh.