One of the beautiful aspects of functional safety standards is that they do not care about the origin of a component or tool that is used in a safety critical application. Focusing on compilers in particular, it does not matter if it is bought from a reputable supplier or downloaded from GitHub. What does matter is that the process for qualification as described in the functional safety standard is followed. The C and C++ compilers are tools. The ISO 26262 standard, and similar standards such as IEC 61508, have different requirements for tools than for the software that is developed for the application itself. ISO 26262 offers four different paths to tool qualification.

One path that may appear attractive is to show “Increased confidence from use.” It appears attractive because open source compilers are used in millions of projects, many of which are mission critical. Any important issues would have been noticed by now. But that argument does not hold for several reasons. The first is, compilers are very complex and their use-cases (including configurations, option and even source code) are too different for this argument to hold. Secondly, open source software is often updated, and every new version needs to be scrutinized by itself. One cannot say that if Version 12.4 is safe to use, Version 15.0 is also safe. Thirdly, important issues are noticed. Every week, Gcc’s issue tracker reports new unresolved issues. Many reported issues are fixed, but on average, the number of unresolved issues grows by the week. For software with the complexity of Gcc, more issues are found than can be handled.

Out of the other three, the path of qualification by “Validation of the compiler” is the most practical and common. Validation shows compliance of the compiler to its specification. This is performed by a test suite that is based on the C and C++ language definition. Luckily, the C and C++ languages have well defined ISO specifications. This is not true for most other programming languages, including popular new languages. An important advantage of validation with a test suite is that it is easily repeatable. Once validation is set up for the required use case, it is easy to repeat it with a slightly different use case or a new version of the compiler. Only results that differ from previous results need to be analyzed.

A common misconception is that the compiler (or any other software) must be perfect before it can be qualified. Functional safety standards recognize that such a requirement would make it virtually impossible to ship any application. Instead, they require that any non-compliant behavior of the compiler must be documented in a safety manual. This manual will also document the specific restrictions of the validated use case.

In this presentation, we will dive into these issues and show how open source compilers can be qualified for use in safety critical projects.

Short Bio:

Dr. Marcel Beemster is the CTO of Solid Sands, the world leader in C and C++ compiler validation. He got his PhD from the University of Amsterdam for his work on compilers to exploit parallelism in functional languages. He worked at ACE to develop and promote the CoSy compiler development system. In recent years his focus has shifted to testing and functional safety qualification for compilation tools and standard libraries.

Friday, September 26, 10.00 AM