From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by sourceware.org (Postfix) with ESMTPS id D5AF73858C74 for ; Thu, 11 Aug 2022 16:40:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D5AF73858C74 Received: by mail-qk1-x736.google.com with SMTP id v14so8326987qkf.4 for ; Thu, 11 Aug 2022 09:40:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=4VSTdB6FveBGjhSnhmlQAmZ8mUBi+EPtCZfSAjE+8rk=; b=jOCWKHajZyfUdLoHVC7TcHyTHv4waLj1qG5Ktji8D7c+6nzIl6kEnPPwD5uKjPCscF H0afGxOPGGZqDQE0H6jKy5kuVoUhU8WK4Rr6rdUfmLms7xY/nEV95yWfzDHrX3K6Kh2l sM4/wzzFcH1jDsXqMa5UvPN2ZcD3FytTROo33SB7auHRugBrfZ5/yugaeIkzZ8wgNfRQ IkRfIc/nHJ/gEpEYlIjygQHbTJJcfl3oatIdoqmsIrvagKxwkhEpKgIGuYAfGrdtHMx5 GlTTiC3sog1+1a/Nydw4UOTxDhbZi6aWrh/J/aZ+vNQJdAum5oRNfR+2vRfqKcXXYIpO MOBA== X-Gm-Message-State: ACgBeo3sZQPt1UTcetl7yrN6XqSpYCu0osWs7TXaZOe4192PLPRJ/tCM 3RnPbqhpDFJY6OIX4yOKrFMu5582CD+jBmV/3ic= X-Google-Smtp-Source: AA6agR42Rg/VS1nVD7XbHRdWmzTDZM5n6NEyvfZOZiXqzrtf8ASOzyiVOMeR09Adw+lmLSbtMXk9atrMuqpPv7tIERU= X-Received: by 2002:a37:e20e:0:b0:6b6:1f7d:1c98 with SMTP id g14-20020a37e20e000000b006b61f7d1c98mr24634039qki.670.1660236058156; Thu, 11 Aug 2022 09:40:58 -0700 (PDT) MIME-Version: 1.0 References: <146313cd-154f-4001-05a8-6b25a90a14d2@suse.com> <4b800fb3-57a7-ee86-c530-ccf1b42e8105@suse.com> In-Reply-To: <4b800fb3-57a7-ee86-c530-ccf1b42e8105@suse.com> From: "H.J. Lu" Date: Thu, 11 Aug 2022 09:40:22 -0700 Message-ID: Subject: Re: [PATCH 06/12] revert "x86: Also pass -P to $(CPP) when processing i386-opc.tbl" To: Jan Beulich Cc: Michael Matz , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2022 16:41:00 -0000 On Tue, Aug 9, 2022 at 12:33 AM Jan Beulich via Binutils wrote: > > On 08.08.2022 14:49, Michael Matz wrote: > > On Fri, 5 Aug 2022, Jan Beulich via Binutils wrote: > >> This reverts commit 384f368958f2a5bb083660e58e5f8a010e6ad429, which > >> broke i386-gen's emitting of diagnostics. As a replacement to address > >> the original issue of newer gcc no longer splicing lines when dropping > >> the line continuation backslashes, switch to using + as the line > >> continuation character, doing the line splicing in i386-gen. > > > > I will note that all occurrences of the line continuation character are > > within the various <> templates, never in the opcodes themself. So their > > content is all bracketed, and there's no reason why they should even be > > considered to be single-lined. So all of this should be possible to be > > fixed in parse_template() alone, and then i386-opc.tbl wouldn't need any > > continuation characters at all. > > Well - that's possible in principle, yes. But it comes with downsides: > For one, it would require fetching further lines from parse_template(), > when imo it's better to have all fetching (and in particular all > incrementing of "lineno") in a central place (process_i386_opcodes(), > which at present "lineno" also is a local variable of). Then for a > mistakenly omitted closing angle bracket it would lead to consumption > of potentially all remaining lines of the file (quite likely resulting > in a not very helpful diagnostic). Having everything on one (virtual) > line in order to check for the closing angle bracket was actually the > original reason to use line continuation of some form). And finally it > would preclude further use of line continuation for other purposes, > albeit I'll admit doing so may be undesirable for other reasons. > > Jan Using '+' is fine. But please add a comment in i386-opc.tbl to document it. Thanks. -- H.J.