Вы когда-либо разрушали компилятор?

VC ++ отказал на мне при компиляции C++, если шаблонное использование испорчено (например, пропустив закрытие">").

Да, особенно когда это - старый или undermaintained компилятор (GCC 2.95, Tendra в режиме C++). Я не имею в наличии части кода, все же.

Actionscript 3.0:

switch(on_some_variable)
{
}

Пустой переключатель = Kaboom!

Ну, это на самом деле не разрушало компилятор - Это была просто ошибка, был VC ++, не примет совершенно хороший код. ( подробная информация, предоставленная здесь ).

нечетное это об этом было то, что это было только инициировано, когда три довольно неясных условия все соблюдали. Перемещение одной строки кода было всем, что было необходимо для эффективного обходного решения. И одно из необходимых предварительных условий "использовало станд. пространства имен"; которому широко препятствуют в производственном коде.

, Тем не менее, сообщения, спрашивающие, как решить проблему, были главным продуктом на Microsoft VC ++ группы новостей. Я не мог выяснить, как столько людей споткнулось на неясную ошибку. Так, в конечном счете я спросил кого-то.....

точный код должен был инициировать ошибку, был пример в Stroustrup" программирование на C++ Langauge ". (*)

(*) Примечание, я не говорю, что он сделал это нарочно. Я уверенный он протестировал его под вариантом UNIX C++ и полностью не знал, это - влияние на VC ++.

VC ловит его корректно теперь, но в середине 90-х, это было бы разрушенный и Microsoft C ++ и компиляторы Borland C++:

struct MyClass
{
    MyClass operator->() { return *this; }
};


int main(int argc, char* argv[])
{
    MyClass A;
    A->x;
}

перегруженный оператор-> является внутренне рекурсивным. Функция, как ожидают, возвратит указатель, к какому oper-> снова относятся. Этот фрагмент сделал генерацию кода бесконечно рекурсивной.

Это разрушило ОСНОВНОЕ C64:

PRINT 0 + "" +- 0

Я видел несколько ошибок компилятора в компиляторе C# (все пограничные случаи, все сообщили соответственно), и подтвердил некоторые катастрофические отказы, вызванные другими людьми.

самый страшный компилятор (в некотором роде) ошибка, с которой я встретился, была ошибкой JIT в одной версии Java. Это было довольно восстанавливаемо, но заставило VM понижаться. Не добавляя справедливо никакой-op оператор (я не могу помнить точно, что бесцеремонно - возможно просто объявление дополнительной локальной переменной с начальным значением) отодвинул его от любого углового случая, которым это, оказалось, было - и это было зафиксировано в более поздней версии.

Visual C++ 9,0 SP1

это всего произошло со мной

------ Build started: Project: pdfp, Configuration: Debug Win32 ------
Compiling...
reader.cpp
xref.cpp
c:\projects\pdfp\xref.cpp(52) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\toil.c', line 8569)
 To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++ 
 Help menu, or open the Technical Support help file for more information
Generating Code...
Build log was saved at "file://c:\Projects\pdfp\Debug\BuildLog.htm"
pdfp - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Когда Вы получаете сообщение "Катастрофический отказ", Вы знаете, что пробуете....

Michael

Я еще не сделал GHC (компилятор Haskell) катастрофическим отказом, но я получил его к ошибке с

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

, довольно легко работать вокруг, и Вы не поражаете это, если у Вас нет некоторых хитрых (и обычно неправильно) дизайн, но он, вероятно, побеждает как лучшее сообщение ошибки компилятора когда-либо.

Visual C++ 5. 'Nuff заявил.

В проекте я работал в, некоторые определенные использования Лямбда Повышения , выражения могли заставить компилятор Visual C++ отказать. (Мы использовали Visual Studio 2003)
, компилятор только откажет во время сборки конечных версий, отладочная сборка хорошо работала бы.

была религиозная война, бушующая через команду о соответствующем использовании библиотек лямбды, я был почти благодарен, что компилятор уладил его для нас. :-)

Благодаря @Nick, это разрушает VS2005.

 template<typename Res, typename T>
 Res operator_cast(const T& t)
 {
     return t.operator Res();
 }

 int main()
 {
    return operator_cast<int>(0);
 }

В моем предыдущем задании у нас было средство моделирования, которое было известно за способность разрушить (ICE) компиляторы или заставить их генерировать неправильный код. И когда код на самом деле был сгенерирован правильно, ofter компилятор занял 15 минут для единственного исходного файла. Visual Studio никогда не была (как долго, когда я работал там) способный скомпилировать ядро средства моделирования.

ядро было автоматически сгенерировано от DSL, и сгенерированный код часто продвигал компилятор к своим пределам.

Обновление до новой версии GCC часто вызывало широко распространенный nervosity: новая версия будет работать?

Я разрушил компилятор прежде путем выполнения его из памяти.

Дают компилятору DOS приблизительно 0.5 МБ исходного кода. Уплотнение.

Ой, забыл 'e' в определении типа и разрушил компилятор.

typdef struct kGUIColor GameColor;

c:\source\kgui\samples\space\space.cpp(35) : fatal error C1001: INTERNAL COMPILER ERROR
        (compiler file 'msc1.cpp', line 2708) 
         Please choose the Technical Support command on the Visual C++ 
         Help menu, or open the Technical Support help file for more information

В версии 1.2.x Моно компилятора C# отказал бы вполне немного со сложным кодом (если я помню правильно, вложил анонимных делегатов). К счастью, с 2.x выпуск, я не видел катастрофических отказов.

легкий.

// -*- C++ -*-

template <int n>
class Foo : public Foo<n+1>
{

};

int main(int, char*[])
{
    Foo<0> x;
    return 0;
};


ejgottl@luna:~/tmp$ g++ -ftemplate-depth-1000000 -Wall foo.cpp -o foo
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See `<URL:http://gcc.gnu.org/bugs.html>` for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
`<URL:file:///usr/share/doc/gcc-4.2/README.Bugs>`.

Одно время, когда я использовал пример генераторов из документов Python, он повредил версию Python, который мы использовали. Та же неделя, одному из моих коллег удалось неправильно использовать FFI, таким образом, что любое вычисление, включающее номер 3, разрушит Python.

Компилятор Microsoft Xbox 360 может отказать легко. Мне дали исходный код с японскими комментариями и при преобразовании в обычный текст один из последних знаков на строке был '\', таким образом, это продолжало комментарий на следующую строку. Если следующая строка была командой переключателя, то компилятор отказывает.

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

Я, много раз разрушал Delphi 7 прося, чтобы это скомпилировало код DOS прежней версии.

главный преступник, кажется, любая квалификация чего-то как являющегося в системной единице. Это будет не всегда аварийно завершать его, но когда это аварийно завершится на таком материале, я просматриваю и переписываю что-либо, что требует такого переопределения, и проблема уходит.

взрывы составляют 100% reproduceable, но мне никогда не удавалось сделать простой тестовый сценарий. Это на самом деле не разрушает компилятор большую часть времени, Вы обычно получаете ошибку, которая не имеет никакого отношения к проблеме и может быть сотнями строк от нее. Среда дестабилизирована, сохраните и выйдите, в порядке, но не думайте о выполнении ничего больше.

Назад в каменном веке с Borland Pascal 7 (последняя версия DOS) я много раз повреждал его. Никакой катастрофический отказ, просто неправильная и непоследовательная эмиссия кода. Я наконец учился сохранять.EXE (не считающий информацию об отладке) ниже 3 МБ. Чем дальше кроме того я пошел, тем более нестабильным это стало.

Я управлял к segfault интерпретатором Python. Конечно, я работал над расширением C в то время и получал его нет.

Я не знаю, назвал ли я это, катастрофический отказ, но sdcc ( компилятор C Небольшого устройства ) перестал работать при компиляции кода, сформированного конкретным способом:

• Цель: 8051
• Код должен был выполниться в 512-байтовом кэше, загруженном от внешнего тестера
• , Тестер сознает ситуацию и хранит код - кэш не может выбрать следующую страницу
• Никакие позволенные вызовы функции - ПК (счетчик команд) пропустил бы к месту не резидентный объект в кэше; макросы препроцессора использовались для выполнения модульной практики кодирования
• , Переходы (переходящие), позволили, если это не пропускает из кэша
• Никакие значения константы - в разделе данных кода программы, который заставляет код в кэше выбирать что-то не в кэше - препроцессор, постоянный (#define) хорошо здесь

, макросы препроцессора развернуты, приведя к плоскому, но большому коду - все в основном (); выполнение пропускает код запуска (настраивающий стек, и т.д.) и запускается в начале основного ()

Соответствующая часть этого ответа:

Иногда, sdcc отказался бы компилировать синтаксически правильный код с сообщением об исчерпывании памяти. Это даже произошло, компилируя на 64-разрядных полях с 8 ГБ RAM.

решение в этих случаях состояло в том, чтобы разделить встроенное микропрограммное обеспечение на отдельные части и скомпилировать их отдельно и выполнить их отдельно. Части, возможно, смогли быть соединенными назад, но в той точке это не имело значения.

я не попробовал его, но , компилятор Keil 8051, вероятно, возможно, обработал проблематичный код.

Этого не происходит так, как это привыкло для, но иногда предварительный компилятор ASP.net имеет проблемы - я не видел его лично, но я решил проблему на другом проекте однажды, где у них были столкновения имени, потому что они не использовали пространства имен правильно (вызванные катастрофические отказы компилятора) во время предварительной компиляции.

В добрые старые времена (неуправляемый MSVC ++) у нас обычно был нечетный катастрофический отказ компилятора из-за соединения во внешних статических win32 классах (.lib), и несколько нечетных битов кода иногда вызывали проблемы, но они были все взяты очень быстро.

Я разрушил VC ++ неоднократно, обычно с кодом шаблона. Но это не самый интересный катастрофический отказ...

я отказал, Системный компилятор Команды VS2005 с / анализируют опцию, компилирующую мою общую библиотеку кода, которая скомпилировала без ошибки без переключателя, и на VS2008 с и без переключателя. Конечно, MS не очень было интересно, потому что это была ошибка в старой версии компилятора, но я думал, что это было довольно интересно.

Я сделал. Некоторые версии Delphi (позволяет, говорят что № 4), разрушенный очень часто с загадочными сообщениями об ошибках.

более новые версии (2006 и больше) стабильны, но не качают тело. (7 было большим в этом случае).

катастрофические отказы Компилятора часто происходят при больших редактированиях и сеансах отладки сложных проектов (много dll's). Большую часть времени перезапуск язя достаточно. Но иногда необходимо перезапустить ПК.

O и я когда-то разрушили OS2 наряду с компилятором, потому что своп-файл стал слишком большим.

Я использую как pcc, так и gcc для компиляции моего старого проекта ОС.

Я обнаружил ошибку в том, как pcc и gcc обрабатывают нетривиальный фрагмент кода, и это привело к сбою pcc. (символы подписаны на моей платформе)

struct{
  char myvalue:1;
}mystruct;

pcc разбился, потому что все значения битовых полей должны быть int, так что там действительно больше ошибок, но gcc обрабатывает это неправильно. Понимаете, если подумать, он подписан, но в нем есть место только на один бит. Таким образом, он может хранить только 0 и -1. Что ж, gcc обрабатывает это неправильно, сохраняя 0 или 1.

Сегодня VS2003SP1 выдал мне сообщение C1001 (внутренняя ошибка компилятора) с жалобой на файл компилятора 'msc1.cpp', строка 2708) из-за этого:

struct PATTERN {
  …
};

Оказывается, проблема заключалась в том, что структура имя, которое я пытался определить (ШАБЛОН), уже было определением типа в GDI для типа кисти. Однако вместо того, чтобы сказать мне, что символ уже определен (как и для большинства других вещей), он не только не указывал на структуру как на проблему - я сузил проблему до нее, выборочно комментируя блоки до тех пор, пока ошибка не исчезнет. - но это также дало мне вышеупомянутую загадочную ошибку, которая не имеет ничего общего с указанным файлом - которую я даже не могу найти, чтобы исследовать рассматриваемую строку. : |


Мне удалось воспроизвести это с помощью следующего кода:

    typedef int SOMETHINGOROTHER;
    struct SOMETHINGOROTHER {};

> фатальная ошибка C1001: ВНУТРЕННЯЯ ОШИБКА КОМПИЛЯТОРА
> (файл компилятора 'msc1.cpp', строка 2708)…


В то время как следующий код дает ожидаемое сообщение об ошибке:

    struct SOMETHINGOROTHER {};
    typedef int SOMETHINGOROTHER;

> 'ЧТО-ТО ДРУГОЕ': переопределение; различные базовые типы


Очевидно, проблема в процедуре обработки структуры компилятора.

Интересно, лучше ли VS2005 +…

У моей команды часто были случайные внутренние ошибки компилятора с компилятором до-диеза на наших машинах сборки. Мы разрешили проблему путем очистки всех bin/obj папок между сборкой каждой цели.