4.6.9. Axivion Compiler Errata Checks User Guide

4.6.9.1. Introduction

This guide explains how the compiler errata checks are used in order to search for code pieces that might be affected by a known compiler errata.

There is a separate package for each compiler family for which errata checks exist. The compiler errata packages are not shipped with the Axivion Suite installer.

4.6.9.2. Prerequisites

In order to use the compiler errata checks, at least the following prerequisites must be met.

  1. Install and set up Axivion Suite properly. Carefully consider the Axivion Reference Guide in particular with regards to stylecheck configuration. Make sure to understand the size_t concepts of your environment and how to configure the code analysers accordingly.

  2. Configure Axivion Suite for the use with the target compiler and project settings. The compiler errata checks can only produce reliable results if the configuration to the respective compiler and project environment is free from errors. For example,

    • The environment variable BAUHAUS_CONFIG must be set to the directory layers where the project configuration(s) is/are located.

    • The compiler profile used must be set up properly (e.g. predefined macros, standard include paths and type sizes must be configured correctly).

    • There must be no error messages during code analysis. To detect that kind of messages, activate the stylecheck rules Generic-NoCompilerWarnings.

    • Avoid warning messages during code analysis. To detect that kind of messages, activate the stylecheck rules Generic-NoCompilerWarnings.

    • There must be no linker errors. To detect that kind of messages, activate the stylecheck rules Generic-NoLinkerWarnings.

  3. The version of the compiler errata checks must match the version of Axivion Suite . This is verified by the test driver when run on the tests included in the compiler errata package. The user is responsible for ensuring this for own tests.

  4. The test cases included in the compiler errata package need to be run with the actual project configuration.

4.6.9.3. Limitations

Notice that the problems addressed by several of the checks covered in the compiler errata checks are undecidable. In addition, the description provided by the compiler vendor can be imprecise, or the compiler errata only manifest when certain conditions outside the source code are met (for example, certain command-line options are used, or the compiler’s assembler output shows a specific pattern). This means that only approximations can be calculated by the checks, which can result in missing and incorrect notifications. While the supplied test cases demonstrate that the Axivion Suite is able to detect instances of these problems, no guarantee can be made that all such instances are detected. A manual check of the program under analysis is required for a definitive assessment.

4.6.9.4. Compiler Errata Package Contents

Compiler errata checks for the Axivion Suite are implemented as a set of stylecheck rules similar to the rules shipped with every Axivion Suite installation.

Each compiler errata check package also comes with a number of self-contained test-files all having a file suffix .c or .cpp. See Section Source Test File Format for a description of the file format.

In the following you can see the directory structure of a compiler errata check package:

rules/compiler-name

.py files to implement the compiler errata checks

test/compiler-name

.c/.cpp files for the implemented compiler errata checks cafeCC_config/ empty directory provided for quick integration tests cafeCC_config/README.txt description of this directory

As stated in Section Limitations you will still need to look at the individual test results in order to know for sure, whether a positive test is a result of a bug in the Axivion Suite or test-case assumptions not being met by your compiler configuration.

4.6.9.5. How to Setup a Compiler Errata Package

  1. Configure your project so that it can find the additional stylecheck rules included in the compiler errata package. To do this, use axivion_config to add the rules directory of the compiler errata package to your project configuration. And activate the respective rules under Stylecheck/Compiler Errata.

  2. Verify that the test cases provided with the compiler errata package can be executed in the context of your intended project configuration. The test cases are located in the test subdirectory of the errata package and they reference the implementation of the checks in the rules subdirectory by default. This default can be changed by editing the supplied rules/<compiler-name>/<compiler-name>_errata.json file.

    1. The test/<compiler-name> directory contains an empty subdirectory cafeCC_config. To quickly verify that the tests can be run with a certain compiler configuration successfully, the configuration for the cafeCC compiler can be placed into this subdirectory.

    2. To verify that the test cases pass as expected with the intended project configuration, please put a layer file axivion_config.json into the cafeCC_config subdirectory and remove all other files (except optionally for the README.txt). axivion_config.json should be edited to reference the indened project configuration layers in the correct order.

    3. Note that, in addition to the configuration files, additional switches can be passed to your compiler (and to cafeCC) by your build system (e.g., makefiles). These switches can also influence the tools’ behavior. For example, choosing a certain language standard for C or C++ must be considered (via -std=c++14). Make sure the tests provided are aligned with your compiler switches. For this purpose, the environment variable CAFECC_OPTIONS can be used to pass additional options to the cafeCC frontend during test execution.

    4. Each time a relevant part of the tool chain changes, tests must be re-run to ensure that the configuration is still valid.

For details on the tool perform_tests and its test file formats, see The Test Driver perform_tests.