Тестовые примеры компилятора или как проверить компилятор

Question

Компиляторы, как и все программное обеспечение, также будут подвержены ошибкам, логическим ошибкам.

Как проверить вывод, сгенерированный компилятором. Как правило, мой вопрос (есть)

• Как проверить правильность сгенерированного машинного кода?

• Как убедиться, что сгенерированный машинный код соответствует спецификации языка.

• Имеет ли смысл просто выбирать проект с открытым исходным кодом (в C, если вы также пишете компилятор в C), чтобы просто скомпилировать его через «компилятор». В этом случае также, как судить, что компилятор ведет себя так, как ожидалось.

• Существуют ли какие-либо формальные тестовые примеры (литература), предоставленные комитетом по языковым стандартам, которые должен удовлетворять компилятор "соответствия языку"?

• Каковы же уверенности в том, что проблема в программе, скомпилированной компилятором , является ошибкой компилятора, а не ошибкой программы.

  - Есть ли примеры, когда основные компиляторы запутываются и неправильно компилируют код?

Ссылки на любую литературу приветствуются.

Answer 1

Хорошие тестовые наборы для реальных языков дорогостоящие в создании и обслуживании. Есть причина, по которой набор тестов Plum Hall , который является отраслевым стандартом для ANSI C, так чертовски дорог.

Подтверждение перевода Джорджа Некулы - блестящая идея, но ее реализация довольно дорогая.

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

Answer 2

Существует несколько наборов тестов для компилятора. Нам повезло, используя набор тестов Plum Hall для компилятора Си. Он состоит из большого набора кода C, специально написанного для проверки на соответствие стандарту языка. Он проверяет, что компилятор может обрабатывать синтаксис и семантику языка.

Answer 3

Общая практика заключается в создании большого набора небольших программ, каждая из которых демонстрирует один аспект компилятора. Они будут включать в себя как программы, которые компилируются, так и те, которые не должны. Обычно ASM, выходящий из серверной части, не проверяется, а программа запускается, и вывод проверяется. Что касается того, как убедиться, что в тестовых случаях нет ошибок: сделайте их маленькими, например, по 5-10 строк в каждой.

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

Answer 4

За идею собрать большой проект с открытым исходным кодом:

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

Answer 5

Компилятор Eiffel имеет открытый исходный код и содержит обширную библиотеку тестовых примеров и внутренних контрактов на проектирование.

http://dev.eiffel.com

Answer 6

Был более ранний вопрос, связанный с этим для C , но он сводится к тщательно написанному набору тестов компилятора.

Что касается того, когда компиляторы ошибаются в коде, я достаточно часто сталкиваюсь с этим в своей профессиональной карьере, спасибо. Это происходило все реже и реже, но На этой неделе я обнаружил ошибку в компиляторах MS C ++, нацеленную на CLI .

Answer 7

GCC имеет довольно большой набор тестов (https://gcc.gnu.org/onlinedocs/gccint/Testsuites.html#Testsuites).. Он доступен на SCM: https://github.com/gcc-mirror/gcc/tree/master/gcc/testsuite