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

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

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

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

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

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

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

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

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

ссылки на любую литературу буду признателен.

37
compiler-construction compiler-design

7 ответов

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

9

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

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

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

10

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

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

6

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

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

4

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

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

2

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

http://dev.eiffel.com

2

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

0