<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/195006>195006</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
[AArch64] Assembly failure with -save-temps when a function name matches a register name
</td>
</tr>
<tr>
<th>Labels</th>
<td>
new issue
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
witbring
</td>
</tr>
</table>
<pre>
I found an AArch64 assembly failure in Clang/LLVM when `-save-temps` is used
and a function name overlaps with an AArch64 register name.
This appears to be an ambiguity issue in the emitted assembly: the symbol name
is parsed as a register name by the assembler rather than as a function symbol.
Minimal reproducer:
```
#include <stdio.h>
void xzr(void) {
printf("Hello world\n");
}
int main(void) {
xzr();
return 0;
}
```
Command line:
$ clang-22 --target=aarch64-linux-gnu xzr.c --save-temps
Actual result:
```
xzr.s:44:5: error: expected label or encodable integer pc offset
bl xzr
^
```
The emitted assembly contains:
bl xzr
Here, `xzr` is the intended function name, but the assembler appears to parse
`xzr` as a register name rather than as a branch target symbol. I observed a
similar failure when the `b` instruction is emitted, for example:
b xzr
Expected result:
The program should compile successfully, and the emitted assembly should
unambiguously refer to the function symbol.
Possible fixes:
One possible fix would be to quote ambiguous symbol names in the emitted
assembly, for example:
bl "xzr"
In my testing, emitting double quotes around such symbols resolves the
ambiguity. I tested this quoting-based approach across Clang versions 14
through 22 and did not observe compatibility issues.
Alternatively, the assembler/tokenizer could treat the operand of `bl` and
`b` as a symbol/branch target rather than as a register token in this context.
Additional observations:
- I observed this issue across Clang versions 14 through 22.
- The exact number of affected identifiers differs by version, but I found
approximately 279 to 344 failing cases depending on the Clang version.
- The affected identifiers appear to correspond mostly or entirely to AArch64
register names.
- This issue appears to be an assembly ambiguity issue caused by unquoted
symbol names colliding with architecture-specific register names.
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJx8Vk-P4rgT_TTmUgKlnQDNgUOme9CMNKPf7zDau2NXktp17Kz_0DCffmUn0ND0bqulQLCrXr169WzhPXUGcc_WX9j6dSFi6K3bv1FoHJlu0Vh13n-H1kajQBioayf7TQXCexwafYZWkI4OgQy8aGE6xg8_fvzxE956NMA2xdKLIy4DDqNnmwLIQ_SoWFGLFBDaaGQga8CIAcEe0Wkxenij0N-mc9iRD-jyshUralbUv3ryIMYRhfMQLDSYdoihoS5SOAN5HzOu0CPgQCGguuJmZZ3f-_PQWJ3DsqImD6NwPq8DcZ8VmnPeMUdAB06EHh2EPqX1t8VMUWecP8nQIDQ4HJ1VUaJjZT39xDbF_F_UjJdkpI4KgZUvPiiyq56VX6eVR0sKTr8d48_pI-M7YNsvrKhhdGRCy_gz4_wbam3hzTqt2PrFMM4Z37EyrWPb1ykSmQCDIPMYCWDOcN2UXjkM0Rko7sLc4i7qFzsMqZ2aDL7XxiuQSRFLzmG5DMJ1GFj5KkRu6VKTiadlZ2JKupKwvFVKjlDLEDNvPurwKWdpp2dlXVWsrNepp-icdfnDaUSZOq5FgxqsAzTSKtHopImAHToYJdi29RjmUtNfo6dnYqKoga2_Ptb76xNBgbQmCDL-CvQxGivqb-iQ8Zc0GendNBFJVgmTUajuJyItbWL4ILwb0We5TgjneJ8o90GojRNG9jD15KJW-A628eiOqSpW1J4G0sJdJzxPdALCNkWTkRsfXJzAkr8wkiC3ie6TGEaN93S8E_H10p_b9iZiR2c7JwbwvY1agbTDSBrBRynR-zZqfU4pkt4-G-x5HyvqaCYvsNHrMzhsEwU2b_p8UP9vvaekj5ZOOPfxfwZhvHkPbxlVgynU39EGhGuWWzPxH4wnGd7Fev6LIA2M8zyFfHr73cBwhoA-UDLXlykgmQ6UjQlUBuFBuGzRPsp-xuETtVYfMQssAbhYY2p1ioiJQvI5BJlu2YhsfePorJA9COms95OtwxGdJ2s8PFWsqEPvbOx64Dw3QpECY8NFP7lpIlBD-mrEfia51gGdEYGOOFFxJ23GD8H-hYZ-owOZqQ4OxTQAdkSXstk2S1BntRs1qb-5an-qnvHDvcofhuA6Iznj1C_yeY7xFC5wlaKkFKHn4kT6NotjeTsyefN05vwbcfBO2ypvz0ZyEjKAiUODLpUm2nYaDFJoArWEzoOitk3P5nyJd3GG-WzO-smdO9EgAuoz8O0uibSsqjzCSTJSePSgcESj0nc7afQO6DuyT5FM3pMCS-sc-tEaBYP1QZ8nkw3kUvZgL4d3hnZnSP6S452xh2P8Ms4fz3Mp0v0hERFNlv5U-t3oSas15QKne4STPQWUITpc-hEltSQ_Ilqofal25U4scP-03W7XfFs-Py_6_a7lRdHyVilV4I5vebUrN4jYyGfRPu92C9rzgm-KqiyKdbnhzyusqif-9FSW1WbbttsNqwocBOmV1sdhZV23yKXsn3brotgs8gHl8wWMc4NvU6HJANavC7dPm5ZN7DyrCk0--PcwgYLON7cL0-tXqD9ezDIFN2fr5OMfb16DCLLHh6NjEZ3e9yGMWfH8wPiho9DHZiXtwPghQZkfy9HZP1EGxg_TwDN-mCs87vk_AQAA__-evXyN">