6

拡張アセンブラのgccドキュメントによると：

オペランド[...]の制約でレジスタが許可されている場合にのみ、読み取り/書き込みオペランドを使用する必要があります。

これはかなり明白なようです。出力に+mを使用 することはできません。

しかし、私はそれが何度も行われているのを見てきました。実際、LinusTorvaldsは次のように記録しています

gccドキュメントはセカンダリです。それらは更新されておらず、正しくなく、現実を反映しておらず、問題ではありません。使用する唯一の正しいものは、このようなものには「+m」です

コンパイラがコードを台無しにしてしまう場合は、+mを使用したくありません。そして、出力asmを調べてそれが機能しているかどうかを調べても、明日、一見無関係に見えるものを変更しても、それが機能することを意味するわけではありません。または、gccの次のアップデートを取得したときにも機能します。

ドキュメントが正しく、これが正しく機能することに頼ることができない場合は、他のオプションを追求できるようにそれを知りたいと思います（そのほとんどは不快な痛みを伴います）。ドキュメントが間違っている場合は、修正する方法を教えてください。

4

2 に答える 2

3

結局のところ、問題はドキュメントです（電子メールを参照）。リンクが停止した場合：

ドキュメントのその部分はしばらくの間間違っていました。ドキュメントは4.8に修正されましたが、以前のバージョンでも間違っていました。

バージョン4.7.2を報告するrubenvbのx64コンパイラを使用しているので、それが私が読んでいたドキュメントのバージョンです。ただし、実際のコードチェックインは2004年であったため、実行しているコードに変更が含まれていると確信しています。

于 2013-03-25T05:53:01.340 に答える
0

gcc / egcsの裂け目がちょうど回復し始めた（2000年頃に終わった）2001年（！）にLinusがgccについて言ったことを引用しないでください。はい、その時間枠でのasm制限の処理はひどい混乱でした（コンパイラが制限に本当に注意を払い始めたので、Alan Coxは混乱をクリーンアップする一種の頭でした、私はそれにいくつかのパッチを追加しました）。

現在のGCCは完全に異なる獣であり、内部で大規模なリエンジニアリングが行われています。

ドキュメントを信じて、悪い制約を書かないでください。それらは制約です。コンパイラーに嘘をついた場合、運が悪ければ、ほとんどの場合に機能する引数を選択する可能性があります。いつか 壊れます。

不正な制約の書き込みが受け入れられる（コンパイラーがチェックできる）ことを示す例がある場合は、それを報告してください。

コンパイラーが考慮しない制約の例がある場合は、それを報告してください。

オプションに応じて動作する（または動作しない）コードがある場合、コンパイラはypuの指示に従って合法的に実行できますが、動作する場合と動作しない場合があります。気づく。あなたのコンパイラに嘘をつかないでください、それは血まみれの復讐を正確にします。

于 2013-03-25T02:18:07.510 に答える