[PATCH v2 00/65] gas: whitespace handling

[Richard Earnshaw (lists)]

On 28/01/2025 07:40, Jan Beulich wrote:
> On 28.01.2025 03:50, Hans-Peter Nilsson wrote:
>> Sorry for being a downer, but:
>>
>>> Date: Mon, 27 Jan 2025 16:23:42 +0100
>>> From: Jan Beulich <jbeulich@suse.com>
>>
>>> As per observations in target specific code there appears to be disagreement
>>> across the assembler whether to check for specific characters (blank and tab
>>> normally) or whether to use ISSPACE().
>>>
>>> As agreed upon during the Cauldron in Prague, switch to a single base
>>> construct for all code to use: is_whitespace().
>>
>> Such decisions should be made online, with the whole
>> community, not with the people attending a specific session
>> at a specific event.  (While I had the chance, I had no idea
>> executive decisions were about to take place.)
> 
> Well, here we are online. The series hasn't been committed yet, so
> objections will be listened to. Albeit in objecting to certain aspects
> please keep in mind what the overall goal is: To make #NO_APP and the
> -f command line option work for more targets. And to have as uniform
> behavior as possible in gas across targets.
> 
> As per your comment on the cris-specific patch I can't help the
> impression that gcc avoiding to emit TABs for this target isn't
> "happenstance" as you called it, but simply attributed to gas'es past
> behavior.
> 
>>> It clearly is an alternative option to have is_whitespace() expand to
>>> ISSPACE() or ISBLANK() (ISSPACE() also yields "true" for characters we don't
>>> really consider whitespace), then (obviously) leaving out the last patch. See
>>> also the CR_EOL uses in read.c and app.c. I think it is advisable though that
>>> is_whitespace() and is_end_of_{line,stmt}() be non-overlapping; question then
>>> is what (further) characters to tag as LEX_WHITE (see remarks in patch 01).
>>>
>>> Along with recently (as of the v1 submission) committed work for x86 this
>>> appears to be sufficient to actually use -f (or #NO_APP at start of file)
>>> for gcc-generated code.
>>
>> Does that work also clean up gcc-generated code, like
>> dropping space after comma or multiple spaces or whatever is
>> judged the #NO_APP behavior of "x86 assembly"?  I don't see
>> such patches but maybe they're not posted yet.  It doesn't
>> just happen to be specified as what gcc generates on the
>> master branch of today?
> 
> Well, what gcc presently emits needs to be accepted anyway. A goal is
> specifically to get -f / #NO_APP working without needing to touch target
> specific code in gcc, whenever possible. As said ...
> 
>>> I didn't properly check other architectures yet, but
>>> I seem to recall that at least Arm32 and PPC would apparently require
>>> compiler side adjustments, too.
> 
> ... here, I'm aware that some targets will require some changes, but
> x86 (according to my limited testing) is not among them. And those
> changes are expected to be of limited nature, i.e. they're for example
> not expected to touch *.md files al over the place. From what I was
> able to see, the problems there are with how #APP / #NO_APP are emitted.
> 
> And btw - why would you apply different criteria to cris and x86? For
> cris you said what gcc emits is unwritten but de-fact standard. Yet then
> you question that same pre-condition to be applied to x86?
> 
>> I can't help but thinking this is going ever so slightly in
>> the wrong direction with regards to #NO_APP: this change-set
>> is making that mode more lenient towards formatting;
>> allowing more types of space characters.  With the few
>> targets that have #NO_APP active in gcc-generated code, you
>> have the chance of making that mode more strict.
> 
> Have you ever wondered why it is only so few targets? Permitting TABs
> in compiler generated output is, as indicated in the reply to the
> cris-specific patch, a readability aid. That's certainly a personal
> view, but one I happen to know is shared by many other people. That
> said, I'm also aware that for various targets gcc presently avoids to
> make use of TABs. Of the architectures I'm half-way familiar with it's
> actually a minority, though (PPC and ia64 vs aarch64, Arm, RISC-V, and
> x86).
> 
> Jan

Out of interest, did you consider making the scrubber translate all horizontal white space characters into a single space character (as opposed to just collapsing multiple spaces into one)?  This would eliminate the need for each backend to handle multiple type of space character.

R.