根据扩展汇编程序的gcc docs：
当操作数的约束允许寄存器时，你应该只使用读写操作数。
这似乎非常明确：你不能使用+ m作为输出。
但是，我已经看过很多次了。事实上，Linus Torvalds正在说on record
gcc文档是次要的。他们没有更新，他们不正确，他们没有反映现实，他们并不重要。对于像这样的事情，唯一正确的用法是“+ m”
如果编译器最终搞砸了我的代码，我不想使用+ m。甚至检查输出asm以确定它是否正常工作并不意味着明天当我改变一些看似无关的东西时它仍然会起作用。或者当我获得gcc的下一次更新时它仍然可以工作。
如果文档是正确的，我不能依赖于这种正常工作，我想知道，所以我可以寻求其他选择（其中大多数是令人不快的痛苦）。如果文档有误，请告诉我如何纠正它们。
答案 0 :(得分：2)
事实证明，问题是文档（请参阅email）。如果链接死亡：
这部分文档暂时出错了。该文档已更正为4.8，但对于早期版本也是错误的。
由于我使用rubenvb的x64编译器报告版本4.7.2，这是我正在阅读的文档的版本。但是，实际的代码检查是在2004年，所以我非常有信心我正在运行的代码中包含了更改。
答案 1 :(得分：0)
请不要引用Linus在2001年gcc / egcs裂缝刚刚开始愈合（2000年结束）时对gcc的评价。是的，在那段时间内处理asm限制是一个可怕的混乱（Alan Cox有点清理这个混乱，因为编译器开始真正注意这些限制，我添加了一些补丁）。
目前的海湾合作委员会是一个完全不同的野兽，它在内部经历了广泛的再造。
相信文档，不要写坏的约束。它们是约束，如果你撒谎到编译器，它可能只是运气不好选择大多数时间都有效的参数。 将打破某一天。
如果你有一个例子表明接受了编写非法约束（编译器可以检查！），请报告。
如果您有一个编译器不考虑的约束示例，请报告。
如果你的代码根据选项可以（或不是）工作，那么编译器可以根据ypu告诉它的方式合法地使用，并且有时可以工作，有时它不会，好的，将它归结为你的自己的错，明智的。 不要骗你的编译器，它会报复血腥。