https://sourceware.org/bugzilla/show_bug.cgi?id=32391
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at sourceware dot org |nickc at redhat dot com
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Last reconfirmed| |2024-12-02
--- Comment #5 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Regis Duchesne from comment #2)
Hi Régis,
I have started to investigate the problem of nested macro arguments not
working properly. But in the meantime I think that I have uncovered *part* of
the reason why the \@ counter is behaving strangely: The \@ counter is
incremented at the *end* of the macro invocation, not the start. So:
> .macro outer
> _m\@_:
> nop
> .endm
> .macro inner
> _m\@_:
> nop
> .endm
> outer
> inner
>
> correctly produces this output:
>
> _m0_:
> nop
> _m1_:
> nop
The reason that the first symbol is _m0_ is that \@ is still at a value of 0 -
ie no macros have finished executing. Once "outer" finished, \@ is incremented
to 1, so that when "inner" runs it produces a symbol called _m1_.
But, when the macros are nested:
> .macro outer
> _m\@_:
> nop
> .macro inner
> _m\@_:
> nop
> .endm
> inner
> .endm
> outer
>
> produces the error
>
> Error: symbol `_m0_' is already defined
The "inner" macro is invoked before the "outer" macro has completed. So \@ is
still zero. Hence the same symbol is generated, and hence the error message.
However, this does not mitigate the behaviour you originally reported, where
repeated invocations of the inner macro result in duplicate symbols because \@
is not being incremented after each use.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
