Наскільки компілятори такі надійні?

Ми щодня використовуємо компілятори так, ніби їх правильність задана, але компілятори - це також програми, які потенційно можуть містити помилки. Мені завжди було цікаво про цю непогрішну стійкість. Ви коли-небудь стикалися з помилкою в самому компіляторі? Що це було і як ви зрозуміли, що проблема була в самому компіляторі?

... і як же вони роблять компілятори настільки надійні?

Вони з часом ретельно перевіряються завдяки використанню тисяч або навіть мільйонів розробників.

Також проблема, яку потрібно вирішити, чітко визначена (дуже детальною технічною специфікацією). І характер завдання легко піддається одиничним / системним тестам. Тобто це в основному переклад текстового введення у дуже специфічному форматі для виведення в інший чітко визначений формат (якийсь байт-код або машинний код). Тому легко створювати та перевіряти тестові справи.

Крім того, зазвичай помилки також легко відтворити: окрім точної інформації про версію платформи та компілятора, зазвичай все, що вам потрібно, - це фрагмент коду введення. Не кажучи вже про те, що користувачі компілятора (будучи самими розробниками), як правило, дають набагато точніші та детальніші звіти про помилки, ніж будь-який середній користувач комп’ютера :-)

Окрім усіх чудових відповідей поки що:

У вас є "упередженість спостерігача". Ви не спостерігаєте помилок, і тому ви припускаєте, що таких немає.

Я думав, як ти. Тоді я почав професійно писати компілятори, і дозвольте вам сказати, там багато помилок!

Ви не бачите помилок, оскільки ви пишете код, який приблизно як 99,999% від усіх решти коду, який люди пишуть. Ви, ймовірно, пишете абсолютно нормальний, простий, чітко правильний код, який викликає методи та виконує цикли і не робить нічого фантазійного чи дивного, адже ви звичайний розробник, який вирішує звичайні бізнес-проблеми.

Ви не бачите жодних помилок компілятора, оскільки помилки компілятора не в простому для аналізу простому звичайному сценарії коду; помилки в аналізі дивного коду, який ви не пишете.

Я, з іншого боку, маю протилежні упередження спостерігачів. Я щодня бачу божевільний код, і тому мені компілятори, здається, забиті клопами.

Якщо ви сіли з мовними специфікаціями будь-якої мови і взяли будь-яку реалізацію компілятора для цієї мови, і дійсно намагалися визначити, чи точно виконаний компілятор, чи сконцентрувався на незрозумілих кутових випадках, досить скоро ви знайдете помилки компілятора досить часто. Дозвольте навести приклад, ось помилка компілятора C #, яку я знайшов буквально п’ять хвилин тому.

static void N(ref int x){}
...
N(ref 123);

Компілятор дає три помилки.

• Аргумент ref або out повинен бути змінною, що може бути призначена.
• Найкраща відповідність для N (ref int x) має недійсні аргументи.
• У аргументі 1 відсутнє "ref".

Очевидно, що перше повідомлення про помилку правильне, а третє - помилка. Алгоритм генерації помилок намагається з'ясувати, чому перший аргумент був недійсним, він переглядає його, бачить, що він є константою, і не повертається до вихідного коду, щоб перевірити, чи позначено його як "ref"; швидше, він припускає, що ніхто не буде досить дурним, щоб позначити константу як реф, і вирішив, що цей номер повинен бути відсутнім.

Не ясно, що таке правильне третє повідомлення про помилку, але це не все. Насправді не ясно, чи правильне друге повідомлення про помилку. Якщо дозвіл на перевантаження не вдасться, чи слід «ref 123» трактуватись як аргумент ref відповідного типу? Зараз мені доведеться подумати над цим і поговорити з командою триаж, щоб ми могли визначити, яка правильна поведінка.

Ви ніколи не бачили цієї помилки, тому що ви, ймовірно, ніколи не зробите щось таке дурне, щоб спробувати передати 123 за посиланням. І якщо б ви це зробили, ви, мабуть, навіть не помітили, що третє повідомлення про помилку є безглуздим, оскільки перше є правильним і достатнім для діагностики проблеми. Але я намагаюся робити такі речі, тому що я намагаюся зламати компілятор. Якщо ви спробували, ви побачите і помилок.

Ти мене жартуєш? У компіляторів є помилки, завантаження дійсно.

GCC - це, мабуть, найвідоміший із компіляторів з відкритим кодом на планеті, і подивіться на його базу даних про помилки: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=-- -

Між GCC 3.2 та GCC 3.2.3 подивіться, скільки помилок виправлено: http://gcc.gnu.org/gcc-3.2/changes.html

Що стосується інших, таких як Visual C ++, я навіть не хочу починати.

Як зробити компілятори надійними? Ну для початку вони мають навантаження та навантаження одиничних тестів. І вся планета використовує їх так, що не вистачає тестерів.

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

Я зіткнувся з двома-трьома за день. Єдиний реальний спосіб виявити це - подивитися код складання.

Хоча компілятори дуже надійні з тих причин, які вказали інші афіші, я вважаю, що надійність компілятора часто є самореалізаційною оцінкою. Програмісти, як правило, розглядають компілятор як стандарт. Коли щось піде не так, ви приймаєте на себе свою помилку (адже це 99,999% часу) і змінюєте код, щоб вирішити проблему компілятора, а не навпаки. Наприклад, збій коду під налаштуваннями високої оптимізації, безумовно, є помилкою компілятора, але більшість людей просто встановлюють його трохи нижче і рухаються далі, не повідомляючи про помилку.

Компілятори мають кілька властивостей, які призводять до їх правильності:

• Домен дуже відомий і досліджений. Проблема чітко визначена, і пропоновані рішення чітко визначені.
• Автоматизованого тестування достатньо для доведення правильності роботи компіляторів
• Компілятори мають дуже широкі, як правило, загальнодоступні, автоматизовані та одиничні тести, які накопичуються з часом, щоб покрити більше місця помилок, ніж для більшості інших програм
• У компіляторів дуже велика кількість очних яблук, які спостерігають за їх результатами

Ми використовуємо компілятори щодня

... і як вони роблять компілятори настільки надійними?

Вони ні. Так. Оскільки всі користуються ними постійно, помилки знаходять швидко.

Це гра з цифрами. Оскільки компілятори звикають настільки всенаситно, велика ймовірність, що хтось помилку буде спровокований кимось, але оскільки існує така велика кількість користувачів, дуже малоймовірно , що хтось буде саме вами.

Отже, це залежить від вашої точки зору: у всіх користувачів компілятори є помилковими. Але дуже ймовірно , що хтось - то буде складено такий фрагмент коду , перш ніж ви зробили, так що якщо їх було помилка, це б вразити їх, а не ви, так що з вашої індивідуальної точки зору, це виглядає як помилка була ніколи там.

Звичайно, крім цього, ви можете додати сюди всі інші відповіді: компілятори добре досліджені, добре зрозумілі. Існує цей міф, що їх важко написати, а це означає, що лише дуже розумні, дуже хороші програмісти намагаються їх написати, і вони дуже обережні, коли це роблять. Вони, як правило, прості для тестування та прості стресові або нечіткі тести. Користувачі компіляторів, як правило, самі є експертами-програмістами, що призводить до високоякісних звітів про помилки. І навпаки: письменники-компілятори, як правило, користувачі власного компілятора.

Окрім усіх уже відповідей, я хочу додати:

Я багато вірю , продавці їдять власну собачу їжу. Значить, вони пишуть укладачі самі.

Я часто стикаюся з помилками компілятора.

Ви можете їх знайти в темних куточках, де менше тестерів. Наприклад, щоб знайти помилки в GCC, ви повинні спробувати:

• Побудувати крос-компілятор. Ви знайдете буквально десятки помилок у налаштуваннях та побудові сценаріїв GCC. Одні призводять до збоїв в збірці під час компіляції GCC, а інших призводять до того, що крос-компілятор не зможе створити робочі версії файлів.
• Створіть Itanium версію GCC за допомогою завантажувального профілю. Останні кілька разів я спробував це на GCC 4.4 і 4.5, не вдалося створити робочий обробник винятків C ++. Неоптимізована збірка спрацювала чудово. Ніхто не зацікавився виправити помилку, про яку я повідомив, і я відмовився від її виправлення, намагаючись розібратися в тому, що було порушено в специфікаціях пам'яті GCC Asm.
• Спробуйте створити власний робочий GCJ з найновіших матеріалів, не дотримуючись сценарій збирання дистрибутива. Я смію тебе.

Кілька причин:

• Письменники-укладачі " їдять власну собачу їжу ".
• Компілятори базуються на добре зрозумілих принципах CS.
• Компілятори побудовані за дуже чіткими характеристиками .
• Компілятори проходять тестування .
• Компілятори не завжди дуже надійні .

Зазвичай вони дуже хороші при -O0. Насправді, якщо ми підозрюємо помилку компілятора, ми порівнюємо -O0 проти того, на якому рівні ми намагаємось використовувати. Більш високі рівні оптимізації мають більший ризик. Деякі навіть навмисно так і позначені як такі в документації. Я зіштовхнувся з великою кількістю (принаймні, сотні за час), але останнім часом вони стають набагато рідшими. Тим не менш, в пошуках хороших показників (або інших орієнтирів, важливих для маркетингу), спокуса просунути межі велика. Через декілька років у нас виникли проблеми, коли постачальник (залишився без імені) вирішив порушити дужки за замовчуванням - інший, ніж якийсь спеціальний чітко позначений варіант компіляції.

Діагностувати помилку компілятора може бути важко порівняно, наприклад, зниклою посиланням на пам’ять, рекомпіляція з різними параметрами може просто скремтувати відносне розташування об’єктів даних у пам'яті, тому ви не знаєте, чи це Heisenbug вашого вихідного коду чи помилка компілятор. Крім того, багато оптимізацій вносять законні зміни в порядок операцій або навіть алгебраїчні спрощення вашої алгебри, і вони матимуть різні властивості щодо округлення плаваючої точки та під / переповнення. Важко відрізати ці ефекти від реальних помилок. Обчислення жорстких ядер з плаваючою точкою важко з цієї причини, тому що помилки та числову чутливість часто нелегко відірвати.

Помилки компілятора - не все так рідко. Найбільш поширений випадок - компілятор повідомляє про помилку в коді, який слід прийняти, або компілятору прийняти код, який повинен був бути відхилений.

Так, я вчора зіткнувся з помилкою в компіляторі ASP.NET:

Якщо ви використовуєте сильно набрані моделі у видах, існує обмеження у кількості шаблонів параметрів. Очевидно, що він не може приймати більше 4 параметрів шаблону, так що обидва приклади нижче роблять це занадто багато для обробки компілятора:

ViewUserControl<System.Tuple<type1, type2, type3, type4, type5>>

Не збирається як є, але буде, якщо type5буде видалено.

ViewUserControl<System.Tuple<MyModel, System.Func<type1, type2, type3, type4>>>

Буде компільовано, якщо type4буде видалено.

Зауважте, що System.Tupleбагато перевантажень і може приймати до 16 параметрів (це я божевільно знаю).

Ви коли-небудь стикалися з помилкою в самому компіляторі? Що це було і як ви зрозуміли, що проблема була в самому компіляторі?

Так!

Два найпомітніші були першими двома, які я коли-небудь наткнувся. Вони обидва були у компіляторі Lightspeed C для 680x0 Macs ще близько 1985-7 років.

Перший був тоді, коли, за деяких обставин, цілочисельний оператор постінкранізації нічого не робив - інакше кажучи, у певному фрагменті коду "i ++" просто нічого не робив для "i". Я витягував волосся, поки не подивився на розбирання. Тоді я просто зробив приріст по-іншому, і подав звіт про помилку.

Другий був дещо складнішим і був справді непродуманою «особливістю», яка пішла не так. У ранніх Macs була складна система для операцій на дисках низького рівня. Я чомусь ніколи не розумів - мабуть, це стосується створення менших виконуваних файлів - а не компілятора, який просто генерує інструкції з експлуатації диска на місці об'єктного коду, компілятор Lightspeed викликав би внутрішню функцію, яка під час виконання генерувала операцію на диску вказівки на стеку і стрибнули туди.

Це чудово працювало на 68000 процесорів, але коли ви використовували той самий код на процесорі 68020, це часто робило би дивні речі. З'ясувалося, що новою особливістю 68020 був примітивний кеш-інструкція 256-байт. Оскільки це були перші дні з кешами процесора, він не мав уявлення про те, що кеш "брудний" та потребує поповнення; Я думаю, що дизайнери процесорів у Motorola не думали про самовиправляючий код. Отже, якщо ви виконали дві операції з диском досить близько один до одного у своїй послідовності виконання, а час виконання Lightspeed побудував фактичні вказівки в тому самому місці на стеці, CPU помилково подумає, що він кеширував кеш інструкцій та запустив першу операцію на диску два рази.

Знову ж таки, з'ясувавши, що це викопало кілька розкопок з розбиральником, і багато одноразових кроків у налагоджувачі низького рівня. Моє вирішення полягало в тому, щоб перефіксувати кожну операцію з диском за допомогою виклику функції, яка виконувала 256 "NOP" інструкцій, які заполонили (і таким чином очистили) кеш інструкцій.

За 25 років з того часу я помічав все менше і менше помилок компілятора з часом. Я думаю, що для цього є кілька причин:

• Існує постійно зростаючий набір перевірок валідації для компіляторів.
• Сучасні компілятори, як правило, поділяються на дві або більше частин, одна з яких генерує незалежний від платформи код (наприклад, націлювання LLVM на те, що ви можете вважати уявним процесором), а інша, що переводить це в інструкції для вашого фактичного цільового обладнання. У багатоплатформних компіляторах перша частина використовується скрізь, тому вона отримує багато тестів у реальному світі.

Виявив очевидну помилку в Turbo Pascal 5,5 років тому. Помилка присутня ні в попередній (5.0), ні в наступній (6.0) версії компілятора. І те, що повинно було легко перевірити, оскільки це зовсім не був кутовий шафа (просто дзвінок, який не так часто використовується).

Загалом, безумовно, що розробники комерційних компіляторів (а не хобі-проекти) матимуть дуже широкі процедури забезпечення якості та тестування. Вони знають, що їх компілятори є їхніми флагманськими проектами, і що недоліки виглядатимуть на них дуже погано, гірше, ніж на інших компаніях, що виробляють більшість інших продуктів. Розробники програмного забезпечення - це невблаганна купа, наші постачальники інструментів дозволяють нам знести, ми швидше шукаємо альтернативи, а не чекаємо виправлення у постачальника, і ми, швидше за все, повідомимо цей факт нашим колегам, які цілком можуть слідувати нашим приклад. У багатьох інших галузях це не так, тому потенційна втрата для виробника компілятора внаслідок серйозної помилки набагато більша, ніж для виробників програмного забезпечення для редагування відео.

Якщо поведінка вашого програмного забезпечення відрізняється при компіляції з -O0 та з -O2, ви знайшли помилку компілятора.

Якщо поведінка вашого програмного забезпечення просто відрізняється від очікуваної, тоді ймовірність того, що помилка у вашому коді.

Помилки компілятора трапляються, але ви, як правило, знаходите їх у непарних куточках ...

У 90-х роках у компіляторі Digital Equipment Corporation VAX VMS C виникла дивна помилка

(На поясі я носив цибулю, як це було в той час)

Зовнішня крапка з комою, що передує циклу for, буде складена як тіло циклу for.

f(){...}
;
g(){...}

void test(){
  int i;
  for ( i=0; i < 10; i++){
     puts("hello");
  }
}

У відповідному компіляторі цикл виконується лише один раз.

це бачить

f(){...}
g(){...}

void test(){
  int i;
  for ( i=0; i < 10; i++) ;  /* empty statement for fun */

  {
     puts("hello");
  }
}

Це коштувало мені багато часу.

Старіша версія компілятора PIC C, яку ми (раніше) наносили студентам з досвіду роботи, не могла генерувати код, який правильно використав переривання високого пріоритету. Вам довелося чекати 2-3 роки та модернізувати.

Компілятор MSVC 6 мав чудову помилку в лінкері, вона б виникла сегментацією і час від часу вмирала без будь-яких причин. Чиста конструкція, як правило, виправлена ​​(але зітхає не завжди).

У деяких областях, таких як програмне забезпечення авіоніки, є надзвичайно високі вимоги до сертифікації, як щодо коду, так і апаратного забезпечення, а також щодо компілятора. Про цю останню частину існує проект, який спрямований на створення формально перевіреного компілятора С, який називається Compcert . Теоретично цей вид компілятора настільки ж надійний, наскільки вони приходять.

Я бачив кілька помилок компілятора, повідомив про себе декілька (конкретно, у F #).

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

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

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

Я знайшов помилку в C # компілятор не так давно, ви можете побачити , як Ерік Ліпперт (який знаходиться на C # проектної групи) з'ясували , що помилка була тут .

Окрім вже наданих відповідей, я хотів би додати ще кілька речей. Дизайнери-компілятори часто є надзвичайно хорошими програмістами. Компілятори дуже важливі: більшість програмувань проводиться за допомогою компіляторів, тому обов'язково компілятор має високу якість. Тому в інтересах компаній, що виробляють компілятори, розміщувати своїх найкращих людей (або, принаймні, дуже хороших: найкращим може не подобатися дизайн компілятора). Microsoft дуже хотів би, щоб їх компілятори C і C ++ працювали належним чином, інакше решта компанії не можуть виконувати свою роботу.

Крім того, якщо ви будуєте дійсно складний компілятор, ви не можете просто зламати його разом. Логіка, що стоїть за компіляторами, є дуже складною і простою для формалізації. Отже, ці програми часто будуватимуться дуже "надійним" та загальним способом, що призводить до менших помилок.