For the following code: asm goto ("# %0 %1 %2" : "+r" (i) ::: jmp); Two registers are printed before the label name, because the in-out operand is split internally. This is somewhat surprising from a user perspective. But then: asm goto ("# %l[jmp]" : "+r" (i) ::: jmp); Produces an error: '%l' operand isn't a label. So label operands are numbered after the in-out operand is split, but %l is evaluated without this split taken into account. Docs suggest it should be possible to use asm goto with both in-outs and %l operands simultaneously.
This only matters now because output for assembly goto was only added for GCC 11. Which was introduced with: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558870.html
The master branch has been updated by Vladimir Makarov <vmakarov@gcc.gnu.org>: https://gcc.gnu.org/g:72d78655a91bb2f89ac4432cfd6374380d6f9987 commit r11-7256-g72d78655a91bb2f89ac4432cfd6374380d6f9987 Author: Vladimir N. Makarov <vmakarov@redhat.com> Date: Tue Feb 16 10:27:56 2021 -0500 [PR98096] inline-asm: Take inout operands into account for access to labels by names. GCC splits inout operands into output and new matched input operands during gimplfication. Addressing operands by name or number is not problem as the new input operands are added at the end of existing input operands. However it became a problem for labels in asm goto with output reloads. Addressing labels should take into account the new input operands. The patch solves the problem. gcc/ChangeLog: PR inline-asm/98096 * stmt.c (resolve_operand_name_1): Take inout operands into account for access to labels by names. * doc/extend.texi: Describe counting operands for accessing labels. gcc/testsuite/ChangeLog: PR inline-asm/98096 * gcc.c-torture/compile/pr98096.c: New.
Fixed.
*** Bug 103640 has been marked as a duplicate of this bug. ***
While the changes to gcc/stmt.c and the second asm goto statement in gcc/testsuite/gcc.c-torture/compile/pr98096.c in https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=72d78655a91bb2f89ac4432cfd6374380d6f9987 LGTM (they fix an actual bug with symbolic references), the changes to gcc/doc/extend.texi and the first asm goto statement in gcc/testsuite/gcc.c-torture/compile/pr98096.c seemed to have conflated the label bug with documenting curious behavior. Was it ever consider that the behavior should be changed, rather than documented?
(In reply to Nick Desaulniers from comment #5) > Was it ever consider that the behavior should be changed, rather than > documented? Seems like changing an already documented and released feature seems wrong. Gcc 11 was released back in April. Clang never documented this feature as far as I can tell. Plus it would be very inconsistent with the way the inout feature was handled without asm goto. That is all input constraints are grouped together, having the asm goto label in between the inputs seems wrong.
Previously, you never needed to care about the numbering of the extra hidden input constraints generated for an in-out constraints, because they were _last_. Their existence previously only mattered in that you needed to count them as part of the "max 30" constraint limit. That's why it is sensible to _keep_ these internal constraints last -- after ALL user-specified constraints, including asm-goto labels. Putting in the middle, and forcing users to count them just adds extra unnecessary complexity to the user-facing API. It appears to me that the GCC decision here was accidental, and that when pointed out, the bug was simply documented rather than fixed. That's unfortunate.
That isn't easibly possible, the labels are really significantly different from the implementation POV, so having them intermixed with inputs is hard. If you don't want to count on those extra inputs, name the labels...