[Bug gas/32391] \@ incorrectly handled in nested macros

[jbeulich at suse dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32391

Jan Beulich <jbeulich at suse dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |jbeulich at suse dot com
         Resolution|FIXED                       |---

--- Comment #12 from Jan Beulich <jbeulich at suse dot com> ---
(In reply to Nick Clifton from comment #9)
> I have gone ahead and applied my patch.

While I haven't fully followed the code changes yet, the two scope related
sentences that are being added to the doc (and that are being supported by the
new testcase) worry me significantly. Nested macros suddenly having scope only
within the defining macro would be a regression. I've been using nested macros
to override insn mnemonics, and there it is important that the scope of the
inner macro be global, as it used to be until now. Outline (for an assumed insn
named "jmp"):

        .macro jmp opnd:vararg
        .purgem jmp
        ...
        jmp \opnd
        .macro jmp opnd:vararg
        ...
        .endm
        .endm

This is the only way I'm aware of how to override an insn mnemonic while still
being able to use that very insn mnemonic inside the overriding macro. And this
has been working fine for all the years. (Actual uses of such constructs are a
little more complicated, involving helper macros, but I think the above is
sufficient to get across what I mean.)

I also can't help the impression that the report here is missing an important
detail: References to macro arguments and the special "operators" like \@ in an
inner macro (or macro-like construct, e.g. .irp) should be done using extra
escaping, and hence should not require any scope restriction or alike. On that
basis I'm afraid I think the patch needs reverting, and the report here needs
rejecting, for the original example being a wrong use of the assembler.

Overall may I ask that patches like this one be posted to the list before being
applied? Who is or is not Cc-ed on a bugzilla entry is highly unpredictable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.