GCCとClangは完全にC++規格を遵守していない - それがあなたのコードに与える影響

ある研究によると、主要な2つのC++コンパイラがいずれもISO C++規格を完全に実装していないことが明らかになりました。これは大惨事ではありませんが、コードの移植性と堅牢性に具体的な実用的な影響を及ぼします。

具体的なケース：片方のコンパイラではコンパイルできても、もう片方ではできない場合

おそらく誰もが経験したことのある状況から始めましょう。同僚がコンパイルエラーのバグを報告してきます。彼のコードはGCCでは完璧にコンパイルされるのに、Clangでは理解不能なエラーで拒否されます。あるいはその逆です。1時間かけてデバッグしても、結局のところ、C++標準の隅っこの解釈の違いが原因だったりします。

これは同僚のせいではありません。これはGCCもClangもISO C++標準を完全に実装していないという事実の直接的な結果です。

研究で明らかになったこと

研究者たちはGCCとClangを体系的にC++標準に照らし合わせ、非準拠の領域、つまりコンパイラの挙動が標準で規定されたものから逸脱しているケースを特定しました。両方のコンパイラに関連する問題が、異なるポイントで見つかりました。

これは驚くべきと同時に予想された発見でもあります。C++標準（C++11、C++17、C++20、C++23）は数百ページに及ぶ文書で、オブジェクトの寿命、オーバーロード解決、可変テンプレート、式の挙動、構造化束縛などについて微妙なルールが定められています。これを完璧に完全に実装することは、膨大で継続的な作業です。ISO WG21委員会（標準を維持する組織で、GCCとLLVM/Clangのチームも参加）は、実装者からのフィードバックを取り入れており、これが時には異なる解釈を生む曖昧な領域を生み出すこともあります。

なぜ重要なのか - そしてなぜ大惨事ではないのか

重要な理由：

• 「ポータブル」なC++コードであっても、コンパイラやターゲットプラットフォームによって動作が異なる可能性がある。
• aggressiveな最適化（-O2、-O3）が、未定義動作（Undefined Behavior）を引き起こし、GCCとClangで静かに挙動が分かれることがある。
• Linux（GCC）、macOS（Clang/Apple LLVM）、Windows（MSVC）などのマルチプラットフォームプロジェクトは特に影響を受けやすい。

大惨事ではない理由：

• 文書化された非準拠の多くは、一般的なコードや慣用的なコードではなく、標準の極端なケースに関わるものである。
• GCCとLLVM/Clang（LLVM Foundationが維持する主要なオープンソースプロジェクト）は、どちらも膨大なテストスイートと数百人のアクティブな貢献者を擁している。
• これらの相違点のほとんどは既知であり、追跡され、リリースごとに修正されている。GCCはBugzilla上で準拠性バグの履歴を公開しており、Clangも同様にbugs.llvm.orgで公開している。

これがあなたのコードに与える具体的な影響

この現実から生まれる防御的なプラクティスは以下の通りです：

1. CIで両方のコンパイラを使ってコンパイルする。 これが最も簡単に曖昧さを検出する方法です。GCCとClangの両方で通るコードは、1つのコンパイラでテストされたコードよりも統計的に堅牢です。

2. 冗長な警告を有効にする。-Wall -Wextra -Wpedanticフラグは、デフォルトでは許容されるグレーゾーン（技術的には非準拠）を報告します。

3. 開発時にUBSanとASanを使用する。-fsanitize=undefined（UBSan）は実行時に未定義動作をキャッチします。攻撃的な最適化によってそれが本番環境のバグに変わる前に。

4. 完全なテストなしで-O3を盲目的に使用しない。-O3は、標準で「未定義動作」とされている領域で正当化される最適化です。これはコンパイラ側では正しいのですが、知らずにその動作に依存していたコードにとっては致命的です。

まとめ

• GCCもClangもC++標準に100%準拠しておらず、おそらくこれまでに完全に準拠したことはない。
• 堅牢でポータブルなコードを書くためには、CIで両方のコンパイラを使ってコンパイルすることが最も簡単なセーフティネットとなる。
• 相違点の多くは標準の暗部に関わるもので、日常的なコードには影響しない。しかし、そのことを知らずに「ありえない」動作のデバッグに追われる前に知っておく方がよい。