[Bug middle-end/111817] ICE in expand_asm_stmt with invalid characters in inline-asm output operands

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111817

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:0bab1b5fdca4ef5ac08b2a63a888ad21bfabe4fd

commit r13-10186-g0bab1b5fdca4ef5ac08b2a63a888ad21bfabe4fd
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Jan 8 23:05:58 2026 +0100

    stmt: Fix up parse_input_constraint [PR111817]

    The following invalid testcase ICEs, because we:
    1) for some strange reason ignore invalid punctuations in
       parse_output_constraint, which has just
            default:
              if (!ISALPHA (*p))
                break;
       compared to parse_input_constraint
          default:
            if (! ISALPHA (constraint[j]))
              {
                error ("invalid punctuation %qc in constraint", constraint[j]);
                return false;
              }
       Haven't touched this because I fear it could break real-world code
    2) the checking whether = or + is first in the output constraint is
       a warning only:
          if (p != constraint)
            warning (0, "output constraint %qc for operand %d "
                     "is not at the beginning",
                     *p, operand_num);
    3) parse_input_constraint parses also the corresponding output constraint
       if the input constraint has a number as the only variant, but
       even the comment removed in the following patch explains that it
       doesn't work correctly and skips the first character; now, usually
       that is not a big deal because if the first character of the output
       constraint is = or + as it should, then the checking doesn't do
anything;
       but as 2) is just a warning, we accept it and then we fail to check it
    4) far later on we parse the whole output constraint when input constraint
       refers to it and assert it succeeds, which it doesn't due to 1), 2) and
3)

    The following patch fixes the 3) spot, when switching to the output
    constraint, instead of setting j = 0; and break; (== continue;) so that it
    first does j += CONSTRAINT_LEN (constraint[0], constraint+0) and thus
    usually starts at second, sometimes third character of the output
constraint
    it uses goto before the loop which sets j = 0; and doesn't do the j += ...

    2026-01-08  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/111817
            * stmt.cc (parse_input_constraint): For matching construct, goto
            before the loop without changing j instead of break.  Remove
comment
            about that problem.

            * c-c++-common/pr111817.c: New test.

    (cherry picked from commit 35476a0da65fb13651238e38ae98398c78f12b2e)