https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #21 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #19) > (In reply to Rich Felker from comment #16) > > > Using "ws" in inline asm never made sense. It was always the same as > > > "wa", for all cases where either could be used in inline asm at all. > > > > It made sense insomuch as it was documented and was the most > > clearly-documented as matching the intended usage case, and still makes > > sense in that the other widely-used compiler did not properly (according to > > your interpretation) implement "wa", so that "ws" was the only constraint > > that worked with both. > > I am saying it is a mistake that GCC ever documented this for public > use. Every use of "ws" in inline asm should be "wa". But it was a mistake made by the GCC developers. Once something is documented publicly, we shouldn't just remove it without warning unless there's no realistic alternative. And it sounds from what Jakub says like it's simple to keep this working. I also disagree that this is as common a problem as you're saying. Like Jakub says, there's long been a distinction between internal and public constraints. And for the most part, the public constraints for MIPS and AArch64 were chosen to be ones that we thought were useful and that we could continue to support. There are many more internal ones. (I ended up having to say "for the most part" because it was probably a mistake to include "Ush" for AArch64. Oh well...) There's also precedent for defining compatibility constraints. The MIPS "v" constraint is only provided for asm compatibility, even though no internal patterns use it any more.
