Casos de prueba del compilador o cómo probar un compilador

Question

Los compiladores como todo software, también serían propensos a errores, errores lógicos.

¿Cómo se valida la salida generada por el compilador? Normalmente, mi pregunta es (son)

• ¿Cómo validar que el código máquina generado es correcto?

• cómo asegurarse de que el código de máquina generado es de acuerdo a la especificación del lenguaje.

• ¿Tiene sentido elegir un proyecto de código abierto (en C si también está escribiendo un compilador en C) para compilarlo a través del "compilador". En ese caso también, cómo juzgar que el compilador se comporta como se esperaba.

• ¿Hay casos de prueba formales (literatura) proporcionados por el comité de estándares del lenguaje que un "lenguaje cumplir" compilador tiene que satisfacer?

• ¿Cuáles son el seguro "dé aways" que el problema en un programa compilado por un compiladores un error del compilador y no un error del programa.

  - Cualquier ejemplos en los compiladores de la corriente principal se confunden y compilar el código erróneo?

Los enlaces a cualquier literatura serán apreciados.

Answer 1

Existen varias suites de prueba de compilador. Hemos tenido un poco de suerte con el paquete de prueba Plum Hall para un compilador de C. Consiste en un gran conjunto de código C escrito específicamente para evaluar el estándar de idioma. Verifica que el compilador puede manejar la sintaxis y la semántica del lenguaje.

Answer 2

La práctica general es crear un gran conjunto de pequeños programas que demuestran cada uno de los aspectos del compilador. Estos incluirán tanto el programa que compila como los que no deberían. En general, el ASM que sale del back end no está marcado, sino que se ejecuta el programa y se comprueba su salida. En cuanto a cómo asegurarse de que no haya errores en los casos de prueba: hágalos pequeños, como en 5-10 líneas cada uno.

Estos conjuntos de pruebas pueden ser muy grandes, como cientos o miles de pruebas (por ejemplo: an out of date test suite for the D programming language) y generalmente incluyen uno o más casos de prueba por cada error que se haya informado.

Answer 3

Se ha producido un earlier question related to this for C, pero todo se reduce a un conjunto de pruebas compilador escrito cuidadosamente.

En cuanto a cuándo compiladores reciben un código incorrecto, he golpeado que con bastante frecuencia en mi carrera profesional, gracias. Pasó cada vez menos con el tiempo, pero I found a bug in MS C++ compilers targeting CLI esta semana.

Answer 4

El compilador de Eiffel es de código abierto y tiene una extensa biblioteca de casos de prueba y contratos de diseño interno.

http://dev.eiffel.com

Answer 5

suites buena prueba para las lenguas reales son caros para crear y mantener. Hay una razón por la cual the Plum Hall test suite, que es el estándar de la industria para ANSI   C, es tan caro.

George Necula's translation validation es una idea brillante pero también bastante costosa de implementar.

Lo único que es barato y fácil es esto: mantener un conjunto de pruebas de regresión, y cada vez que corrige un error en su compilador, ponga una prueba adecuada en sus suites de regresión. Con los compiladores, es increíble lo fácil que es seguir reintroduciendo el mismo error una y otra vez. Las adiciones disciplinadas a su suite de regresión evitarán eso, y no cuestan mucho.

Answer 6

Para la idea de compilar un gran proyecto de código abierto:

usted podría tomar un proyecto que sí tiene una serie de pruebas. Luego compila el proyecto y su conjunto de pruebas y ve si las pruebas pasan. Para validar estos resultados, compile el proyecto y el conjunto de pruebas con otro compilador y vuelva a ejecutar las pruebas.

Answer 7

GCC tiene un conjunto de pruebas bastante grande (https://gcc.gnu.org/onlinedocs/gccint/Testsuites.html#Testsuites). Está disponible en SCM: https://github.com/gcc-mirror/gcc/tree/master/gcc/testsuite