Using .macro argument in .error message?

[Jan Beulich]

On 11.06.2026 18:14, Georg-Johann Lay via Binutils wrote:
> Am 11.06.26 um 17:17 schrieb Jan Beulich:
>> On 11.06.2026 16:54, Georg-Johann Lay wrote:
>>> Am 11.06.26 um 16:18 schrieb 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 should 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".
>>>
>>> What I am trying to say is that warning for an unrecognized escape
>>> sequence isn't very helpful when the sequence is NOT an escape sequence
>>> to begin with.  In the example, \data is treated as a .macro parameter,
>>> so there is no unknown escape sequence `\d' anywhere.
>>
>> The scrubber can't know this is a macro parameter reference.
> 
> I understand that the artifact is due to some gas internals finesse.
> 
> But that doesn't help the user's experience in any way.

Well, yes, but see below - we need a concrete proposal for how to change
that.

> And it's still fine to warn for unrecognized escapes when there /are/
> unrecognized escapes, so the tc-avr.h choice makes sense IMHO.

And how do you suggest the scrubber distinguish

	.error "value \data is negative"

used in a macro from this used outside (or even inside, but with "data"
not being a macro parameter)?

Just to mention, there more anomalies here - at least:
- For perhaps a small set of targets: While the "quotechar" static variable
  allows for string quotation by other than '"', the case labels
  circumventing the warning only (and potentially wrongly) cover '"'.
- Only octal digits (and lower case 'f' and 'b') are excluded.
To me the only viable solution looks to be to drop that warning altogether;
this would then limit reporting to next_char_of_string(). Yet then there
must have been a reason that it was added. And more targets than just AVR
would be affected. (I'll see about doing the necessary archeology. Which
may lead to nothing. In the meantime, could you add a respective entry to
our bugzilla?)

Jan