根据扩展汇编程序的gcc 文档：
当操作数的约束[...]允许寄存器时，您应该只使用读写操作数。
这似乎很明确：您不能使用 +m 作为输出。
然而，我已经看到它被做了很多次。事实上，Linus Torvalds在记录中说
gcc 文档是次要的。它们没有更新，它们不正确，它们不反映现实，它们无关紧要。对于这样的事情，唯一正确使用的是“+m”
如果编译器最终会搞砸我的代码，我不想使用 +m 。甚至检查输出 asm 以查看它是否工作并不意味着明天当我更改一些看似无关的东西时它仍然可以工作。或者当我获得 gcc 的下一次更新时它仍然可以工作。
如果文档是正确的并且我不能依赖它正常工作，我想知道这一点，以便我可以寻求其他选择（其中大部分都是令人不快的痛苦）。如果文档有误，请告诉我如何更正它们。
事实证明，问题在于文档（请参阅电子邮件）。如果链接失效：
文档的那部分已经有一段时间是错误的了。该文档已针对 4.8 进行了更正，但对于早期版本也是错误的。
由于我使用的是报告版本 4.7.2 的 rubenvb 的 x64 编译器，这就是我正在阅读的文档的版本。然而，实际的代码签入是在 2004 年，所以我非常有信心在我正在运行的代码中包含更改。
请不要引用 Linus 在 2001 年对 gcc 所说的话（！），当时 gcc/egcs 裂痕刚刚开始愈合（大约在 2000 年结束）。是的，在那个时间范围内，对 asm 限制的处理是一个可怕的混乱（Alan Cox 是清理混乱的负责人，因为编译器开始真正注意这些限制，我为此添加了一些补丁）。
当前的 GCC 是一个完全不同的野兽，它在内部进行了广泛的重新设计。
相信文档，不要写不好的约束。它们是约束，如果你对编译器撒谎，它可能只是运气不好，选择了大部分时间都有效的参数。总有一天会 断的。
如果您有一个示例表明可以接受编写非法约束（编译器可以检查！），请报告。
如果您有编译器未考虑的约束示例，请报告。
如果您的代码执行可能（或不）工作的东西取决于编译器可以根据 ypu 告诉它的选项合法地采用，并且有时有效，有时无效，好吧，把它归结为你自己的错和明智的。不要对你的编译器撒谎，它会进行血腥的报复。