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

Question

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

Как выполнить проверку результата, сгенерированного компилятором. Как правило, мой вопрос:

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

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

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

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

• Что такое «дать аудит», что проблема в программе, скомпилированной компилятором является ошибкой компилятора, а не ошибкой программы.

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

Ссылки на любую литературу будут оценены.

Answer 1

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

Answer 2

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

Эти тестовые комплекты могут быть очень большими, как в сотнях до тысяч тестов (например: an out of date test suite for the D programming language), и обычно включают один или несколько тестовых примеров для каждой ошибки, о которой сообщалось.

Answer 3

Был earlier question related to this for C, но он сводится к тщательно написанному набору тестов компилятора.

Что касается того, когда компиляторы получают код не так, я попал так часто в своей профессиональной карьере, спасибо. Это случается все меньше и меньше со временем, но на этой неделе I found a bug in MS C++ compilers targeting CLI.

Answer 4

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

http://dev.eiffel.com

Answer 5

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

George Necula's translation validation - блестящая идея, но также довольно дорогостоящая реализация.

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

Answer 6

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

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

Answer 7

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