public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Michael Matz <matz@suse.de>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: [PATCH 06/12] revert "x86: Also pass -P to $(CPP) when processing i386-opc.tbl"
Date: Tue, 9 Aug 2022 09:33:14 +0200	[thread overview]
Message-ID: <4b800fb3-57a7-ee86-c530-ccf1b42e8105@suse.com> (raw)
In-Reply-To: <alpine.LSU.2.20.2208081245030.13939@wotan.suse.de>

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

  reply	other threads:[~2022-08-09  7:33 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-05 12:17 [PATCH 00/12] x86: more templatization of insn templates Jan Beulich
2022-08-05 12:19 ` [PATCH 01/12] x86/Intel: split certain AVX512-FP16 VCVT*2PH templates Jan Beulich
2022-08-05 22:28   ` H.J. Lu
2022-08-05 12:20 ` [PATCH 02/12] x86: allow use of broadcast with X/Y/Z-suffixed AVX512-FP16 insns Jan Beulich
2022-08-05 22:31   ` H.J. Lu
2022-08-05 12:20 ` [PATCH 03/12] x86: fold AVX VGATHERDPD / VPGATHERDQ Jan Beulich
2022-08-05 22:32   ` H.J. Lu
2022-08-05 12:21 ` [PATCH 04/12] x86: adjust MOVSD attributes Jan Beulich
2022-08-05 22:46   ` H.J. Lu
2022-08-05 12:22 ` [PATCH 05/12] x86-64: adjust MOVQ to/from SReg attributes Jan Beulich
2022-08-05 23:00   ` H.J. Lu
2022-08-05 12:23 ` [PATCH 06/12] revert "x86: Also pass -P to $(CPP) when processing i386-opc.tbl" Jan Beulich
2022-08-05 23:17   ` H.J. Lu
2022-08-09  7:22     ` Jan Beulich
2022-08-08 12:49   ` Michael Matz
2022-08-09  7:33     ` Jan Beulich [this message]
2022-08-11 16:40       ` H.J. Lu
2022-08-05 12:24 ` [PATCH 07/12] x86: template-ize packed/scalar vector floating point insns Jan Beulich
2022-08-05 23:07   ` H.J. Lu
2022-08-11  1:12     ` Jiang, Haochen
2022-08-11  6:03       ` Jan Beulich
2022-08-11 16:38         ` H.J. Lu
2022-08-05 12:25 ` [PATCH 08/12] x86: template-ize vector packed dword/qword integer insns Jan Beulich
2022-08-11 17:23   ` H.J. Lu
2022-08-16  7:37     ` Jan Beulich
2022-08-16 15:53       ` H.J. Lu
2022-08-16 16:20         ` Jan Beulich
2022-08-16 16:32           ` H.J. Lu
2022-08-05 12:26 ` [PATCH 09/12] x86: re-order AVX512 S/G templates Jan Beulich
2022-08-11 17:24   ` H.J. Lu
2022-08-05 12:27 ` [PATCH 10/12] x86: template-ize vector packed byte/word integer insns Jan Beulich
2022-08-11 17:38   ` H.J. Lu
2022-08-05 12:28 ` [PATCH 11/12] x86: template-ize certain vector conversion insns Jan Beulich
2022-08-11 17:48   ` H.J. Lu
2022-08-05 12:29 ` [PATCH 12/12] x86: shorten certain template names Jan Beulich
2022-08-11 17:49   ` H.J. Lu
2022-08-12 11:33 ` [PATCH v1.1 06/12] revert "x86: Also pass -P to $(CPP) when processing i386-opc.tbl" Jan Beulich
2022-08-15 18:11   ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b800fb3-57a7-ee86-c530-ccf1b42e8105@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=matz@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).