language-agnostic - 你有沒有墜毀的編譯器?




15 Answers

我編寫我們使用的編譯器,所以有時會崩潰。

每個人(至少每個使用編譯語言的人)都面臨編譯錯誤,但是實際上碰到編譯器有多少次?

我有我的公平份額的“內部編譯器錯誤”,但大多數只是通過重新編譯而消失。 你有一個(最小)的代碼崩潰的編譯器?




我還沒有使GHC(一個Haskell編譯器)崩潰,但我已經得到了一個錯誤

My brain just exploded.
I can't handle pattern bindings for existentially-quantified constructors.

解決這個問題非常容易,除非你有一些棘手的(通常是錯誤的)設計,否則你不會碰到這個問題,但是它可能會贏得最好的編譯器錯誤信息。




Actionscript 3.0:

switch(on_some_variable)
{
}

空開關= Kaboom!




那麼,這實際上並沒有使編譯器崩潰 - 這只是一個錯誤,VC ++不會接受完美的代碼。 ( 細節在這裡提供 )。

奇怪的是,這只是在三個相當模糊的條件都滿足的情況下才引發的。 只需移動一行代碼即可獲得有效的解決方法。 而其中一個必要的先決條件是“使用命名空間標準”。 這在生產代碼中被廣泛地勸阻。

然而,問題如何解決這個問題是微軟VC ++新聞組的主要內容。 我無法弄清楚有那麼多人偶然發現了一個晦澀的蟲子。 所以最終我問了一個人.....

在Stroustrup的“ C ++編程語言 ”中,觸發錯誤所需的確切代碼就是一個例子。 (*)

(*)請注意,我不是故意的。 我確定他在C ++的UNIX變體下測試了它,並且完全沒有意識到它對VC ++的影響。




這崩潰了C64 BASIC:

PRINT 0 + "" +- 0



Visual C ++ 5.“Nuff說。




今天VS2003SP1給了我一個C1001(內部編譯器錯誤)抱怨編譯器文件'msc1.cpp',行2708),因為這個:

struct PATTERN {
  …
};

事實證明,問題是我試圖定義的結構體名稱(PATTERN)已經是GDI中的一個類型定義了。 然而,不是告訴我這個符號已經被定義了(就像它對於大多數其他事物一樣),它不僅沒有指出結構是問題,而是通過有選擇地註釋掉區塊直到錯誤消失,從而縮小了問題的範圍但是它也給了我上面提到的與指定的文件無關的隱晦的錯誤,我甚至無法找到這個問題。 :|


我能夠用下面的代碼重現它:

    typedef int SOMETHINGOROTHER;
    struct SOMETHINGOROTHER {};

> fatal error C1001: INTERNAL COMPILER ERROR
> (compiler file 'msc1.cpp', line 2708) …


而下面的代碼給出了預期的錯誤信息:

    struct SOMETHINGOROTHER {};
    typedef int SOMETHINGOROTHER;

> 'SOMETHINGOROTHER' : redefinition; different basic types


顯然問題在於編譯器的結構處理例程。

我不知道如果VS2005 +做的更好...




在我工作的一個項目中, Boost Lambda表達式的某些特定用法可能會導致Visual C ++編譯器崩潰。 (我們使用Visual Studio 2003)
編譯器只會在發布版本中崩潰,調試版本可以正常工作。

在這個團隊中發生了一場關於適當使用lambda庫的宗教戰爭,我幾乎感激編譯器為我們解決了這個問題。 :-)




在我以前的工作中,我們有一個模擬器,因為能夠崩潰(ICE)編譯器或導致它們產生不正確的代碼而臭名昭著。 當代碼實際上正確生成時,編譯器花費了15分鐘來處理單個源文件。 Visual Studio從來沒有(只要我在那里工作)能夠編譯模擬器的核心。

核心是從DSL自動生成的,生成的代碼通常會將編譯器推到極限。

升級到GCC的新版本通常會引起廣泛的不安:新版本會工作嗎?




我之前通過運行內存而崩潰了一個編譯器。

給一個DOS編譯器大約0.5mb的源代碼。 緊縮。




我使用pcc和gcc來編譯我的舊OS項目。

我發現一個錯誤,pcc和gcc如何處理一個不平凡的代碼,它崩潰了pcc。 (字符在我的平台上簽名)

struct{
  char myvalue:1;
}mystruct;

pcc崩潰了,因為所有的位字段值都必須是int,所以它真的有更多的錯誤,但是gcc錯誤地處理了它。 看,如果你仔細想想,它是簽名的,但只有一點點空間。 因此,它只能存儲0和-1。 那麼,海灣合作委員會處理它錯誤的存儲0或1。




我做了。 一些德爾福版本(讓我們說#4)經常與神秘的錯誤信息墜毀。

新版本(2006年和更多)是穩定的,但不穩固。 (在這種情況下7是很棒的)。

編譯器崩潰通常發生在大量編輯,並調試複雜的項目(大量的DLL)的會話。 大多數情況下,重新啟動ide就足夠了。 但有時你需要重新啟動電腦。

O和我一起崩潰OS2和編譯器,因為交換文件變得太大了。




Microsoft Xbox 360編譯器可以很容易地崩潰。 我給出了帶有日語註釋的源代碼,當轉換為普通文本時,該行最後一個字符之一是'\',所以它將註釋繼續到下一行。 如果下一行是開關命令,則編譯器崩潰。

//wierd japanese characters here %^$$\
switch(n)
{
case 0:
    .....
break;
case 1:
    .....
break;
}



我已經崩潰了很多次VC ++,通常使用模板代碼。 但是這不是最有趣的崩潰

我崩潰了VS2005團隊系統編譯器與/分析選項編譯我的共享代碼庫編譯沒有錯誤,沒有交換機,並在VS2008有和沒有開關。 當然,MS並不是很感興趣,因為這是舊版本編譯器中的一個bug,但是我覺得這很有趣。




它不會像以前那樣發生,但偶爾ASP.net預編譯器也有問題 - 我個人沒有看到它,但是我已經修復了另一個項目的問題,因為它們不是名稱衝突在預編譯期間正確使用名稱空間(導致編譯器崩潰)。

在過去的好時代(非託管MSVC ++),我們遇到了奇怪的編譯器崩潰,通常是由於在外部靜態win32類(.lib)中連接了一些奇怪的代碼偶爾導致了問題,但是這些都是很快拾起來的。




Related

language-agnostic compiler-construction crash