Navigating Compiler Challenges in Functional Safety Applications

Across industries, functional safety imposes stringent requirements on developers: code must be defensively engineered to guard against unexpected events such as memory corruption or cosmic ray interference. High‑level languages like C and C++ contain features whose behavior is not fully defined by the language specification. These undefined behaviors can produce surprising, potentially catastrophic outcomes in safety‑critical systems. Consequently, standards mandate defensive coding, rigorous testability, comprehensive code‑coverage, and traceability from requirements to application code to ensure complete and unique implementation of safety functions.

Safety‑critical sectors, especially automotive, often require sophisticated external diagnostic, calibration, and development tools. Defensive coding and external data access are not concepts that compilers inherently understand. Neither C nor C++ accommodate memory corruption, so if defensive measures are not explicitly reachable in the code, a compiler may optimise them away. Defenses must therefore remain syntactically and semantically reachable to survive optimisation passes.

Undefined behavior is notoriously difficult to spot. Even when identified, there is no guarantee that the compiled binary will behave as intended. "Back‑door" data access used by debugging tools is another example of language constructs that compilers do not consider, leading to unforeseen side effects.

Compiler optimisation can eliminate seemingly sound defensive code if it lies on infeasible paths—those that cannot be exercised by any input. Even code that passes unit‑test coverage may be removed during final build. Thus, high source‑level coverage does not assure that the executable contains the intended safety checks.

Object‑code verification (OCV) is therefore best practice for systems where failure has dire consequences. OCV confirms that the compiled object matches the developer’s intent, a critical requirement when compilers may transform code in ways that violate safety assumptions.

Before and after compilation

Functional safety, security, and coding standards (IEC 61508, ISO 26262, IEC 62304, MISRA C/C++) emphasize the need to demonstrate how much of the source code is exercised during requirements‑based testing. While high coverage reduces field failure probability, it relies on the assumption that the compiler faithfully reproduces source‑level behaviour—an assumption that cannot be justified for the most critical applications.

The control and data flow of the generated object code rarely mirrors the source code exactly. A 1:1 mapping between object code and assembly reveals discrepancies. For example, Figure 1 shows assembly produced from a source snippet with optimisation disabled using a TI compiler. When optimisation is enabled, the flow graph changes dramatically because the compiler applies mathematical transforms that assume the absence of undefined behaviour.

Figure 1: Source vs. assembly comparison illustrating how optimisation can alter control flow.

Compilers may optimise away defensive calls if they determine the associated branch is unreachable. Figure 2 demonstrates a CLANG compilation where a call to an error handler is removed because the compiler infers the state variable can only hold two values. This optimisation, while efficient, violates the safety intent of defensive coding.

Figure 2: CLANG removes defensive error call due to unreachable branch.

Altering the surrounding context can change the compiler’s optimisation decisions. Figure 3 adds a new function that accesses the state variable; the compiler now retains the defensive call because the additional context makes the branch potentially feasible. Further changes, such as returning a pointer to the state, force the compiler to preserve explicit values in the assembly (Figure 4).

Figure 3: Context change preserves defensive branch.

Figure 4: Pointer aliasing prevents optimisation of defensive code.

In unit‑test harnesses, manipulating state via pointers can keep defensive code from being optimised away, but this behaviour does not persist in the production build. Hence, unit‑test coverage alone may mask missing safety checks.

Object‑code verification

OCV provides a safety net by comparing source and assembly. Figure 6 shows a simple function that, when executed with a single test call, achieves 100% source‑level coverage. However, the assembled flow graph (Figure 8) reveals unexercised paths that the unit test missed. By forcing tests to cover all assembler paths, OCV uncovers gaps that source‑level tests overlook.

Figure 6: Source code achieving 100% coverage in unit tests.

Figure 7: Basic‑block flow graph of the source.

Figure 8: Assembled flow graph revealing untested paths.

While OCV cannot prevent a compiler from applying its optimisation rules, it brings any mismatch between developer intent and executable behaviour to light, enabling corrective action before product deployment.

Best practice across all domains

For many systems, source‑level unit‑test coverage is sufficient to satisfy certification bodies. Yet, in the most critical safety‑critical applications—across aerospace, automotive, medical, and industrial sectors—supplementing source coverage with OCV is essential. OCV aligns the compiled product with the stringent safety requirements that standards demand, providing the highest confidence that the executable behaves as intended.