bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kerne


From: matz at suse dot de
Subject: [Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
Date: Tue, 13 Aug 2024 12:59:39 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=32073

--- Comment #20 from Michael Matz <matz at suse dot de> ---
(In reply to Jan Beulich from comment #19)
> (In reply to Michael Matz from comment #14)
> > The scrubber removes whitespace between tokens of different classes, but
> > retains
> > whitespace between token of same class, which sometimes makes it so that
> > whitespace in macro invocation does or does not separate arguments, the
> > difference visible in e.g.:
> > 
> >   invoke 1 2
> >   invoke 1 + 2 3
> 
> But that's the whole issue: This isn't how the scrubber works.

I was talking "in principle" and hence imprecisely.

> It's not uniformly "different classes" (there's not really a proper concept
> of tokens either).

Tokens _are_ classes of character-sequences.  'identifier', 'number',
'punctuator', and so on.  (Sometimes the class has just one member: e.g. ')').
But you're right that it's not the difference of classes between RHS and LHS
that enables white-space removal, but rather if pasting the two strings results
in one new token or not.

> Boundaries between what may be numbers or identifiers are
> different from boundaries between operators and alike. The original
> report that I started this effort from was (iirc) something like
> 
>     invoke (1) (2)
> 
> where the (pretty obviously) two arguments become just one.

Yes, when the removed whitespace doesn't change the parse (i.e.
the character sequences now side-by-side don't form a new token), then it
can be removed.  Except of course, it cannot, because whitespace has semantic
meaning as separator later on :-/

I don't have a good solution, I see only hacks (e.g. above: fix _this_ very
instance of '(1) (2)' being pasted, to not be anymore, or alternatively to
continue pasting them, but handle outermost ')' as additional macro argument
separator).  :-(

Or: accept the fact that '(1) (2)' is a single macro argument, even if
surprising.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]