[PATCH v2 00/65] gas: whitespace handling

[Jan Beulich]

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