[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems the latest change resulted in various inline asms with "=m" constraint to
fall through into return false rather than decompose_address.
The problem to me seems to be that constraint is "=m" (and generally, it is the
whole constraint string, rather than some particular constraint in it),
and lookup_constraint looks up only a particular constraint (say "m") etc.
So it only returns something other than CONSTRAINT__UNKNOWN if it is an input
operand rather than output (because that necessarily starts with = or +) and
doesn't have any other modifiers etc. in it and it has a single variant or the
first variant is the one that is considered.
There are other spots that do the same though, e.g. simplify_operand_subreg:
          || ((get_constraint_type (lookup_constraint
                                    (curr_static_id->operand[nop].constraint))
               != CT_SPECIAL_MEMORY)
While e.g. process_alt_operands walks the whole constraint string and handles
everything in there.

I'm afraid I must be missing something important.