Re: [PATCH 06/12] revert "x86: Also pass -P to $(CPP) when processing i386-opc.tbl"

["H.J. Lu" <hjl.tools@gmail.com>]

On Tue, Aug 9, 2022 at 12:33 AM Jan Beulich via Binutils
<binutils@sourceware.org> 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.