Compiler des cas de test ou comment tester un compilateur

Question

Les compilateurs, comme tous les logiciels, seraient également sujets aux bogues et erreurs logiques.

Comment valider la sortie générée par le compilateur. En général, ma question est :

• Comment valider que le code machine généré est correct ?

• Comment s'assurer que le code machine généré est conforme à la spécification du langage.

• A-t-il du sens de choisir simplement un projet open source (en C si on écrit également un compilateur en C) pour simplement le compiler à travers le "compilateur". Dans ce cas également, comment juger si le compilateur se comporte comme prévu.

• Y a-t-il des cas de tests formels (documentation) fournis par le comité des normes du langage qu'un compilateur conforme au langage doit satisfaire ?

• Quels sont les signes certains indiquant que le problème dans un programme compilé par un compilateur est un bogue du compilateur et non un bogue du programme.

  - Y a-t-il des exemples où les compilateurs populaires sont confus et compilent mal le code ?

Des liens vers toute documentation seraient appréciés.

Answer 1

Les bons ensembles de tests pour les langages réels sont coûteux à créer et à maintenir. Il y a une raison pour laquelle le jeu de tests Plum Hall, qui est la norme de l'industrie pour le langage ANSI C, est si coûteux.

La validation de traduction de George Necula est une idée brillante mais aussi assez coûteuse à implémenter. Validation de traduction.

La seule chose qui soit bon marché et facile à faire est la suivante : maintenez un ensemble de tests de régression, et chaque fois que vous corrigez un bug dans votre compilateur, ajoutez un test approprié à vos suites de régression. Avec les compilateurs, il est incroyablement facile de réintroduire le même bug encore et encore. Les ajouts disciplinés à votre suite de régression empêcheront cela, et cela ne coûte pas cher.

Answer 2

Il existe plusieurs ensembles de tests de compilateurs disponibles. Nous avons eu un certain succès en utilisant l'ensemble de tests de Plum Hall pour un compilateur C. Il se compose d'un grand ensemble de code C spécifiquement écrit pour tester la conformité à la norme du langage. Il vérifie que le compilateur peut gérer la syntaxe et la sémantique du langage.

Answer 3

La pratique générale consiste à créer un grand ensemble de petits programmes, chacun démontrant un aspect du compilateur. Cela inclura à la fois des programmes qui se compilent et ceux qui ne devraient pas. En général, l'ASM sortant n'est pas vérifié, mais plutôt le programme est exécuté et sa sortie est vérifiée. Quant à la manière de s'assurer qu'il n'y a pas de bugs dans les cas de test : les rendre petits, comme 5 à 10 lignes chacun.

Ces suites de tests peuvent être très vastes, allant de centaines à des milliers de tests (par exemple : une suite de tests obsolète pour le langage de programmation D) et comprennent généralement un ou plusieurs cas de test pour chaque bug jamais signalé.

Answer 4

Pour l'idée de compiler un grand projet open source :

Vous pourriez prendre un projet qui a lui-même une suite de tests. Ensuite, vous compilez le projet et sa suite de tests et voyez si les tests passent. Pour valider ces résultats, vous compilez le projet et la suite de tests avec un autre compilateur, et exécutez à nouveau les tests.

Answer 5

Il y avait une question précédente liée à cela pour le langage C, mais cela se résume à une suite de tests compilés soigneusement écrite.

Quant aux erreurs de compilateurs, j'ai assez souvent rencontré cela dans ma carrière professionnelle, merci. Cela arrive de moins en moins au fil du temps, mais j'ai découvert un bug dans les compilateurs MS C++ ciblant CLI cette semaine.