[RFC PATCH] gas: Do not eliminate '\()' if there is still .irp is not fully translated

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, September 6, 2024 3:32 PM
> 
> On 06.09.2024 08:50, Haochen Jiang wrote:
> > Recently I found that if I am using nested .irp with \(), it would be wrongly
> > translated. It is caused by \() being eliminated too early. I tried with the
> > following patch to add an extra bool passing in sub_actual to record if there
> > is any .irp in mnemonic not handled before \() is handled.
> >
> > The patch works for current x86 testcases. I may also try with aarch64
> machines
> > if I could find one since macros are widely used in aarch testcases.
> >
> > I suppose there might be a better option to do that so I called this an RFC
> > patch. The current method is quite straight-forward but seems too
> > straight-forward. Discussion is welcomed.
> 
> I don't think this should be done. If such a construct is to survive the
> first round of expansion, it simply needs further escaping. With what you
> do, if I'm not mistaken you'd break possible existing uses. (Aiui you
> don't really look for just \(), but any \(...). Which of course is correct
> as far as not special casing the one form goes. But what's inside \(...)
> may be intended to be processed in the first round, for the 2nd expansion
> round to use the result with \( and ) already dropped.

I c. I suppose maybe I should only keep \(). The current change impacts too
much, which impacts \(...). This is not what I expected to do.

Thx,
Haochen

> 
> Jan