El 25/07/2013 1:55, Jeffrey Yasskin escribiķ:
> [I guess ->SG12]

Yes. I'll subscribe to the mailing list ASAP.

> How does safety certification work for C++ compilers (or compilers in
> general)? Do they specify the compiler's behavior in the face of
> constructs that the standard leaves undefined? (If so, how? That could
> be useful for the UB group.)

They don't specify the behavior, that would be impossible for some UB
cases. I don't know the details about how the compiler was certified,
but since the compiler can directly introduce errors in the software the
whole lifecycle of the product must be as strict as the lifecycle of the
safety-critical software. It must be perfectly defined, reviewed and
tested according to the highest safety level, applying safety analysis
and mitigating the risks. The only certified compiler I know is Green
Hills Multi:

http://www.ghs.com/products/MULTI_IDE.html#safety

it's using the EDG fron-end (this information is public in the EDG
website, http://www.edg.com/index.php?location=customers_oc). A very
high-level view of tool qualification is given here:

http://www.exida.com/index.php/blog/indepth/tool_qualification_and_safety_standards

http://www.embedded.com/design/prototyping-and-development/4007228/3/How-to-verify-your-compiler-for-use-in-IEC-61508-safety-critical-applications

I don't know if the safety assessor required and reviewed design and
test documents for all compiler parts (including the EDG front-end) or a
very deep testing requirements were added (and tested against other
compilers to test the same outputs were achieved).

What the compiler does regarding UB is to add several compile-time
runtime checks that should be used during development and testing phases
(unit-testing, integration tests...). Those checks are disabled for
production code. This can at least reduce the presence of UB. Runtime
checks also include checks for some coding standards like MISRA C
(trapping on legal but usually dangerous operations like unsigned
integer overflows or the absence of enough case labels in switch
statements). typical checks include division by zero, null pointer
dereference, signed integer overflow, stack overflow, freeing memory
twice, etc. The runtime checks have quite a big size and performance
impact (executable code might be increased by 150%).

> Assuming that the certified compiler doesn't specify its behavior for
> situations the standard leaves undefined, this sounds crazy. Because
> you didn't have the resources to inspect the implementation of memcpy,
> you wrote an implementation that knowingly violates the rules under
> which your certified compiler produces expected output? And the
> independent safety assessor was happy with this?

The assessor was not happy, but we needed to inspect the assembler
produced by the compiler where our memcpy was used in our application.
That was a big job but convinced the assessor that this implementation,
for our compiler and our optimization levels, was correct. That is, we
needed to demonstrate that what the UB was for our compiler.

> Note also that with clang and gcc, you can call __builtin_memcpy to
> get defined and optimized behavior even without #including <string.h>.
> It may be replaced with a library call if the compiler doesn't
> optimize it, and your certified compiler may not provide the same
> feature.

Thanks for the explanation. A built-in memcpy is one of the language
features that I miss, as it seems to be the only way to do bit-casts
that are essential in some embedded domains (inspecting network packets,
data serialization...). A conforming freestanding implementation could
also include memcpy. That would not fix the problem for safety-critical
Sw but would be a good low-level tool for embedded developers that don't
want to write their own memcpy function in assembler.

Best,

Ion