Using .macro argument in .error message?

[Jan Beulich]

On 11.06.2026 15:42, Georg-Johann Lay wrote:
> Am 11.06.26 um 15:22 schrieb Jan Beulich:
>> On 10.06.2026 11:54, Georg-Johann Lay wrote:
>>> Am 10.06.26 um 11:27 schrieb Jan Beulich:
>>>> On 07.06.2026 21:16, Georg-Johann Lay via Binutils wrote:
>>>>> Test case err.sx:
>>>>>
>>>>> .macro Test data
>>>>>        .if \data < 0
>>>>>            .error "value \data is negative"
>>>>>        .endif
>>>>> .endm
>>>>>
>>>>>        Test -1
>>>>>
>>>>> $ avr-as err.sx -v
>>>>> GNU assembler version 2.45.50 (avr) using BFD version (GNU Binutils)
>>>>> 2.45.50.20250718
>>>>> err.sx: Assembler messages:
>>>>> err.sx: Warning: unknown escape '\d' in string; ignored
>>>>> err.sx:3: Error: value -1 is negative
>>>>> err.sx:7:  Info: macro invoked from here
>>>>>
>>>>> While the printed error message is as expected, there is a spurious
>>>>> warning about using \d in the string.
>>>>>
>>>>> What am I missing?
>>>>>
>>>>> As far as I understand, the .error message /must/ be "-quoted.
>>>>
>>>> Indeed. But AVR is one of the few targets which enable this extra
>>>> warning. Why that is or whether it could be changed requires AVR
>>>> knowledge, which I don#t have. There's also a surprising set of
>>>> characters for which the warning would never appear. I don't know
>>>> the history of that set, but it feels pretty arbitrary.
>>>
>>> Okay, I didn't even notice that it's target specific... The only
>>> related place I could find is in gas/config/tc-avr.h:
>>>
>>> /* If you define this macro, GAS will warn about the use of
>>>     nonstandard escape sequences in a string.  */
>>> #define ONLY_STANDARD_ESCAPES
>>
>> This is it, yes.
>>
>>> Though whatever the behavior wrt. fishy escapes is, resolution
>>> of macro arguments shoud run prior to that, no?
>>
>> No. Macros are processed after the scrubber (aka "pre-processor") has
>> done its work.
> 
> Whatever the technical limitations are; such a warning makes just no sense.

The person who had added it likely was of a different opinion. I'm pretty sure
things can be improved, and feel free to send a patch, but justifying such a
change will likely require some archeology, not just saying "makes no sense".
In particular the architecture's native assembler's behavior also needs taking
into account.

Jan