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

Question

Каждый (по крайней мере, каждый, кто использует скомпилированный язык) сталкивался с ошибками компиляции, но сколько раз вы действительно врезались в компилятор?

Моя справедливая доля "внутренних ошибок компилятора" , но большинство ушло просто путем повторной компиляции. У вас есть (минимальный) кусок кода, который приводит к сбою компилятора?

Answer 1

Я пишу компилятор, который мы используем, поэтому он иногда падает.

Answer 2

легкий.

// -*- 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>`.

Answer 3

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

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

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

Answer 4

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

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


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

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

Answer 5

Actionscript 3.0:

switch(on_some_variable)
{
}

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

Answer 6

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 ==========

Answer 7

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

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

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

Точный код, необходимый для вызова ошибки, был примером из "Страуструпа" " Язык программирования C ++ ". (*)

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

Answer 8

Это разбило C64 BASIC:

PRINT 0 + "" +- 0

Answer 9

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

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

Answer 10

Visual C ++ 5. 'Нуфф сказал.