From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::4]) by sourceware.org (Postfix) with ESMTP id 276903846457 for ; Tue, 16 Feb 2021 19:41:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 276903846457 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=macro@orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id F03F99200B3; Tue, 16 Feb 2021 20:41:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id E956292009E; Tue, 16 Feb 2021 20:41:04 +0100 (CET) Date: Tue, 16 Feb 2021 20:41:04 +0100 (CET) From: "Maciej W. Rozycki" To: Jeff Law cc: YunQiang Su , gcc-patches@gcc.gnu.org, syq@debian.org, jiaxun.yang@flygoat.com Subject: Re: [PATCH 1/3] MIPS: add -mcompact-branches=prefer option In-Reply-To: <1e45ab71-912e-0e1d-1754-452d8a604407@redhat.com> Message-ID: References: <20210205095338.28231-1-yunqiang.su@cipunited.com> <1e45ab71-912e-0e1d-1754-452d8a604407@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3488.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 19:41:07 -0000 On Tue, 16 Feb 2021, Jeff Law via Gcc-patches wrote: > I think this will be OK once the wording in patch 2/3 of this series is > fixed. As I noted with 2/3 I would like to know what this extra complication is exactly needed for, and then whether we can't reuse the existing options. Once settled I think it would best be placed in the change description for posterity, so that discussions do not have to be chased like I had to with the original change (when we had a different policy on commit messages). Maciej