コンパイラーとインタープリターにバグはありますか？（ユーザーとして）バグに対処するにはどうすればよいですか？[閉まっている]

コンパイラの作業が本質的にソースコードをマシンレベルのコードに変換することである場合、コンパイラに不具合、つまり障害のある「翻訳」が存在する可能性があります

通訳についても同じことが言えます。必要なコンテンツを出力できない場合がありますか？

コンパイラ/インタープリターのバグを聞いたことはありませんが、存在しますか？

はい

比較的成熟している言語よりも、積極的に開発されている言語のほうがそれらを見つける傾向があります（したがって、頻繁に大きな変化は見られません）。これがおそらく、ほとんどの言語が安定性のさまざまな「段階」でリリースされる理由です。ナイトリービルドは、完全にリリースされてアクティブに使用されているバージョンよりもリリース候補よりも安定している可能性がはるかに低くなります。

幸いなことに、これらの言語のほとんど（特にオープンソース言語）には、レポートを送信できる公開バグ追跡システムがあります。

私自身の経験では、Windows上のScalaでかなりあいまいだが深刻なバグに遭遇しました。調査結果をバグトラッカーに提出したところ、問題はかなり迅速に修正されました。その場合、言語開発者は、エラーログ出力に役立つメモを含めるのに十分なほど賢く、実際にコンパイラエラーであったことを示唆し、レポートの送信先を述べました。

素人の言葉で：

すべてのプログラムにはバグがあります。

コンパイラはプログラムです。

エルゴ、コンパイラにはバグがあります。

ハードウェアにもバグがあります。有名な例はPentium FDIVバグです。間違いなく、コンパイラにバグが含まれている可能性があります。

コンパイラーとインタープリターもソフトウェアであるため、他のソフトウェアの問題から解放されるわけではありません。

これは最近のMSVC 11（2012）のコンパイラーの例であり、バックエンドのテスト方法に関する記事です。

もちろん、コンパイラはソフトウェアだからです。

2005年、大企業向けに作成した非常に重要なソフトウェアでコードの一部が失敗しました。会社の修正には文字通り数百万ドルの費用がかかったため、もちろん大規模な調査を開始しました。

ありがたいことに（私の観点から）、この問題はDelphiのコンパイラの問題であることが判明しました。try finallyブロックでは、関数の戻り値が破棄され、呼び出し元に返される結果が完全にランダムになりました。これは文書化され、ボーランドによって認められました。

.NETは、特に初期の実装において、文字通り何百もの異なるメモリリークが発生することがよく知られていました。

私は、バグのないソフトウェアのようなものはないと主張します。コンパイラも例外ではありません。ただし、これらはほとんどのビジネスソフトウェアよりも徹底的にテストされており、賢く、批判的で、議論の多い人々によって消費されているため、その実績は実際には全体としてかなり良好です。

バグだけでなく、故意のマルウェアもあります。

Brian Kernighanが元のUnix Cコンパイラに実装した「ログイン」トロイの木馬は、これらの中で最もよく知られています。http://cm.bell-labs.com/who/ken/trust.htmlの記事にはこれに関する背景があります。

もちろん、ソフトウェアコンパイラにはバグがあります。たとえば、gccのバグリストはこちらです。

はい。

また、コンパイラだけでなく、インタープリター/デバッガー、およびサードパーティのソフトウェアツールも使用します。

現在、サードパーティのソフトウェアを使用しており、いくつかの問題が発生しています。時々、バグを見つけて報告してくれてありがとう。:)

それらの一部には、メモリリークもあり、クラッシュにつながります。ここでの重要な質問は、サードパーティのツールまたはコンパイラに、アプリケーションが正しく動作するためのバグがあるかどうかをどのように判断するかです。

コンパイラーは、ある言語（ソース言語）で書かれたプログラムを読み取り、それを別の言語（ターゲット言語）の大部分が機械語である同等の別のプログラムに変換するプログラムです。

ソース言語コードが行ごとにスキャンされるコンパイラのさまざまなフェーズがあります。ソース言語コードでスキャンされるすべてのキーワードを追跡するシンボルテーブルがあります。

フェーズ1：字句解析プログラム-ソースプログラム内のすべての文字を読み取り、トークン（int、char、float、if-else、for、whileなど）の論理的な分離を形成します。

フェーズ2：構文アナライザー-トークンのストリームの構造を分析します。後置/前置などを含む式の階層的解析（a = b + c * d）

フェーズ3：セマンティックアナライザー-トークン（実数、浮動小数点など）および演算子の優先順位などの多くのタイプチェック。

フェーズ4：中間コードジェネレーター-a = b + c * de（temp1 = c * d、temp2 = temp1 + b、temp3 = temp2-e）

フェーズ5：コードの最適化-
排除するさまざまな分析（制御フロー、データフロー、変換）：冗長コード、定数伝播、部分デッドコード、共通部分式、ループ不変コード

フェーズ6：コード生成-レジスタに値を入れるターゲットコード（ほとんどのアセンブリ言語）の生成

これらのフェーズはすべて、よく書かれたプログラムにすぎず、その中にN個の欠陥がある可能性があります。

もちろん、コンパイラは単なるプログラムであり、その作者もバカです:)。言語仕様にさえバグがある可能性があります。例：c＃+ foreach + lambda。

またはPythonでは、インタープリターのバグ：evil astをコンパイルすると、インタープリターがクラッシュします。

コンパイラー/インターペッターのバグを確認したい場合は、phpをご覧ください。整数オーバーフローに関する有名なバグがあります。最初の修正はから始まりましたif (size > INT_MAX) return NULL;。物語の続き。