In all our years of compiler testing, there’s one thing we can say for certain – no compiler is perfect. It’s inevitable that whenever you really put a new or old compiler through its paces you’ll find an error. That’s why compiler qualification for safety-critical applications is so important. But it also raises the question: if an error is found during qualification, how do you mitigate it?
One of the concerns often expressed by our customers is: “If SuperTest finds an error during compiler qualification, it’s typically too late to change the compiler because the project is too far advanced.”
In that case, the obvious solution is to make sure that application developers avoid the error.
However, that often raises the question “How do we do that?” The answer depends on which of the following three situations you’re dealing with:
- The compiler fails to compile a properly formed (e.g. according to the C/C++ standard) program or test, and simply stops
- The compiler translates an incorrectly formed program without generating an error message
- The compiler translates a properly formed program incorrectly, leading to run-time errors
Each situation requires a different kind of mitigation.
The compiler fails to compile a properly formed program and stops
This is the least harmful type of error, because the compiler stops (or even crashes). As a result, the functional safety or integrity of an application component is not affected, because no executable is generated. Application developers won’t be thrilled, but no harm can be done.
The compiler translates an incorrectly formed program without generating an error message
This is potentially more dangerous, because an incorrectly formed program has no defined behavior according to language standard, yet the compiler has given it a behavior. This is not uncommon in GNU-C based compilers, which historically adopt a liberal interpretation of the standard. Warning application developers to avoid the problem can be achieved via a programming guideline. However, it’s generally preferable to find a static analysis tool (SAT) that does a more comprehensive job of enforcing the language standard than the compiler does.
The compiler translates a properly formed program incorrectly
This is the most dangerous situation, because it means that the compiler can introduce run-time errors into correctly written applications. In our experience, such errors are usually closely related to a particular language construct or library function, and can therefore be mitigated by avoiding the construct or function. However, no off-the-shelf SAT will detect their use, because they are properly formed program segments. In that case you have two options. If the construct or library function is easy to recognize, you can generate a custom script to avoid its use, or you can ask Solid Sands to create a custom SAT that will detect and avoid it – something we do for our customers.
In rare cases, the error cannot be linked to a specific construct or compiler option. In that case, the best option is to consider using a different compiler, which is why compiler qualification should be performed as early as possible in the project cycle.
Join us at the 8th International CTI Conference, ISO 26262 USA
If you want to know more about testing and qualifying compilers for safety-critical applications, visit the 8th International CTI Conference, ISO 26262 USA (May 13 – 15, 2019 in Novi, Michigan, US), the leading international exchange on functional safety in the automotive industry. Our Software Quality Engineer, Remi van Veen, will be speaking about the test and qualification of optimizing compilers for functional safety. His presentation is on Tuesday, May 14, 2019 at 3.30 PM. Make sure not to miss it.
Subscribe to our monthly blog!