[hp@axis.com: Re: [PATCH v2 11/65] cris: use is_whitespace()]

[Jan Beulich]

(repeating my reply in public then, too)

On 28.01.2025 16:38, Hans-Peter Nilsson wrote:
> Sorry: I accidentally left out the mailing list when
> replying to Jan regarding the CRIS part, so here it is,
> forwarded.  (Actually a re-reply, and I was confused why TAB
> could suddenly be introduced in supposedly scrubbed code,
> where Jan clarified the context both in the cover letter and
> later discussion.)  Note the incompatibility comment though,
> that applies both ways: a gcc with #NO_APP and emitting TAB
> would require a later assembler, so it's configure.in check
> time.
> 
> ------- Start of forwarded message -------
> From: Hans-Peter Nilsson <hp@axis.com>
> To: Jan Beulich <jbeulich@suse.com>
> In-Reply-To: <9b6e367e-9052-4df7-b428-d2ffeb0a8830@suse.com> (message from Jan
> 	Beulich on Mon, 27 Jan 2025 17:52:27 +0100)
> Subject: Re: [PATCH v2 11/65] cris: use is_whitespace()
> Content-Type: text/plain; charset="iso-8859-1"
> Date: Mon, 27 Jan 2025 18:18:58 +0100
> 
>> Date: Mon, 27 Jan 2025 17:52:27 +0100
>> From: Jan Beulich <jbeulich@suse.com>
> 
>> On 27.01.2025 17:22, Hans-Peter Nilsson wrote:
>>>> Date: Mon, 27 Jan 2025 17:10:32 +0100
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>
>>>> Wherever blanks are permissible in input, tabs ought to be permissible,
>>>> too. This is particularly relevant when -f is passed to gas (alongside
>>>> appropriate input). Also switch ISSPACE() uses over.
>>>
>>> Hm... This code is supposed to handle formatted input
>>> (#NO_APP in effect; format being simplified,
>>> "canonicalized") so aren't the TABs supposed to be gone
>>> here, whitespaces changed into a single space character?
>>
>> With #NO_APP (or the -f command line option) in effect it's quite the
>> other way around: TABs would not be replaced.
> 
> Sorry, I regularly miss a negation trying to express #NO_APP
> effects...  What I mean is that when you reach that code,
> you should *not* be making the kind of changes you propose;
> that should have been done by the #APP/#NO_APP framework.
> 
>> I.e. checking for just
>> blanks would make things dependent on the compiler to not emit TABs.
>> I don't know about cris, but for most other targets gcc does emit
>> tabs.
> 
> Correct, because TAB is not a canonical format character for
> #NO_APP CRIS assembly code (if for no other reason than
> happenstance; has not been accepted).
> 
> To wit, with that kind of change, a subtle incompatibility
> is introduced, such that suddenly there's a binutils version
> that makes a difference, and if a TAB is introduced in code
> emitted by gcc, then you'd require a later binutils for that
> and no other reason.  So please don't; let that kind of
> change happen only for code in #APP mode (whitespace -> one
> space).

Well, I've dropped the two hunks, albeit I disagree. The fact that
for cris gcc doesn't emit TABs in particular as separators between
insn mnemonic and operands is imo a problem - it makes reading the
output needlessly hard. But so be it ...

I'd also like to make note of cris.md saying nothing about it being
forbidden to use TABs (or at least I couldn't find anything).

Jan