[PATCH] arm: drop stray newlines

[Jan Beulich]

On 30.04.2025 15:46, Richard Earnshaw (lists) wrote:
> On 30/04/2025 14:33, Jan Beulich wrote:
>> Both as_bad() and as_warn() already emit a newline; having extra ones
>> leads to somewhat distorted diagnostics.
>> ---
>> The context I noticed this in was an attempt to use ".arch all". Is
>> there a reason -march= accepts "all", but .arch doesn't? 
> 
> This is... complicated.
> 
> Once upon a time the arm architecture was a simple chain of extensions to a previous architecture.  Then the architecture introduced thumb-only processors which didn't have A32 instructions at all, then 'profiles' were added; and then it introduced a feature-based approach so that there is no-longer a linear architecture chain.  Now there are extensions that only exist on specific profiles so there really is no concept of a linear chain at all.

Are there conflicting extensions, though? If not, the concept of "all" would
still make sense.

> -march=all, which is, essentially, the default if you don't specify anything else on the command line means try to work it out by analysing the contents of the file you're reading.  It's very hit-and-miss these days though and it may not guess correctly in some cases.

Good to know that one better wouldn't use this then.

> I don't think it makes much sense to support this in .arch.  If it's written in the file, then the file really should know which ISA variant it is targetting.

Even if it's, say, part of a generic (source) library?

>> Then again
>> "all" isn't even documented as valid for -march= ... Yet the same is
>> true for -mcpu= vs .cpu.
> 
> I don't think it would be a good idea to document it either, for the reasons given above.  Whilst it might work much of the time there's no guarantee, given the evolution of the architecture, that it will continue to do so even for code that assembles OK today.

Well, what should I say ...

> The patch is OK.

Thanks.

Jan