From patchwork Fri Sep 1 20:33:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 808985 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-461331-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Px4LgYqG"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3xkWCm2mZ8z9s7M for ; Sat, 2 Sep 2017 06:33:23 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=AN7MDh3Vo40ShC/DckpSDMOmpcUkU 62Kd4YgwbO1XpZxcEkP0zT206840pi/1fQzo6saEWx0hiUU2Nrr5kBxFF2IZRxiC 833wy9h+N+CHwPVX/QkgH2r3X850Ygm1oqCAErwDSMjE0kTscpUm04Je6plmBWrx I1AMyM6vIvqOkU= 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:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=Wg0RJoGYRZKPZ3UbewsgRInSlCk=; b=Px4 LgYqGqiwz6UiPUNG50EU/vx/KFxg9edS9CApdy8OvAsRn9a7DVGgWNpzFvWZIudO bblJ5dfuflAEzakEKxqbiQZy1J8UR5t4zrYIDyIg0LnVgsJvfS1ibUJinltzhbnQ EgEtV9oQrRhe1wUBmeutU7fjfZ4n/A0lCbOk5j0E= Received: (qmail 20752 invoked by alias); 1 Sep 2017 20:33:17 -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 20564 invoked by uid 89); 1 Sep 2017 20:33:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=privately, Hx-languages-length:1144, HTo:U*vmakarov 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; Fri, 01 Sep 2017 20:33:15 +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 3329568CE; Fri, 1 Sep 2017 20:33:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3329568CE Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jakub@redhat.com Received: from tucnak.zalov.cz (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B85C9781E5; Fri, 1 Sep 2017 20:33:13 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v81KXB6h012698; Fri, 1 Sep 2017 22:33:11 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v81KXAuX012697; Fri, 1 Sep 2017 22:33:10 +0200 Date: Fri, 1 Sep 2017 22:33:10 +0200 From: Jakub Jelinek To: Vladimir Makarov , Jeff Law , Bernd Schmidt Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix a pasto in lra-remat.c (reg_overlap_for_remat_p) Message-ID: <20170901203310.GS2323@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes Hi! This is something that has been reported privately to me. This is in code introduced in https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00660.html and looks indeed like a pasto to me, before the loop there is a very similar set of stmts without the 2 suffix, and unless regno being a hard reg (after possible reg_renumber) implies that regno2 (after possible reg_renumber) is a hard reg, if unlucky we might access out of bounds. I don't have a testcase for this, but have bootstrapped/regtested it on x86_64-linux and i686-linux, ok for trunk? 2017-09-01 Jakub Jelinek * lra-remat.c (reg_overlap_for_remat_p): Fix a pasto. Jakub --- gcc/lra-remat.c.jj 2017-05-25 10:37:00.000000000 +0200 +++ gcc/lra-remat.c 2017-09-01 19:42:07.615291583 +0200 @@ -684,7 +684,7 @@ reg_overlap_for_remat_p (lra_insn_reg *r if (regno2 >= FIRST_PSEUDO_REGISTER && reg_renumber[regno2] >= 0) regno2 = reg_renumber[regno2]; - if (regno >= FIRST_PSEUDO_REGISTER) + if (regno2 >= FIRST_PSEUDO_REGISTER) nregs2 = 1; else nregs2 = hard_regno_nregs[regno2][reg->biggest_mode];