https://sourceware.org/bugzilla/show_bug.cgi?id=32391
--- Comment #4 from Regis Duchesne <regis.duchesne at broadcom dot com> ---
Hi Nick,
> I assume that you also feel the same about \+, correct ?
I feel the same about all arguments (explicit or implicit) which have the same
name in an outer and an inner macro. That includes any explicit argument, and
implicit @ and +.
> But my other objection is that if we do change the behaviour of \@ we may
> break already existing assembler code out there in user land that relies upon
> how things currently work. Which would be bad. So we either need to
> implement a new, nesting safe macro counter (eg \!) or else add a command
> line option to control the behaviour of \@.
Implement a new, nesting safe macro counter (eg \!) does not help solve the
problem for an explicit argument with the same name in the outer and inner
macro (see bullet 4 of my previous message). So I think the problem is more
generic than just @, and the solution should therefore not be centered around
making a new version of @ that behaves differently. It should be centered
around making arguments with the smallest (i.e. most local) scope silently take
precedence.
To preserve backward compatibility, we could require that developer explicitly
opt-in for the new behavior. One way is a command line option. But note that
there is already an existing mechanism which locally alter macro behavior: the
.altmacro / .noaltmacro directives. So we could similarly introduce new
.altmacro2 / .noaltmacro2 directives to locally enable the new behavior.
On a tangential note: I was hopeful I could solve my problem with .altmacro, so
I tried this
.altmacro
.macro outer
LOCAL label
_m\label:
nop
.macro inner
LOCAL label
_m\label:
nop
.endm
inner
.endm
outer
unfortunately if fails to assemble:
Error: `label' was already used as parameter (or another local) name
Error: symbol `_m.LL0001' is already defined
So LOCAL-declared arguments exhibit the same symptoms: they are not really
local! They may fail if another argument with the same name and a broader scope
exists. At least they don't fail silently (remember in bullet 4 of my previous
message that the "explicit argument" case failed silently).
> Can you not include the name of the macro in the label ?
That does not help. To see why, just modify your example to execute the inner
macro twice back to back instead of once. And then the assembler will complain
that the label named _inner_\@_ is redefined.
Cheers,
--
Régis
--
You are receiving this mail because:
You are on the CC list for the bug.
