Does undefined behavior apply to asm code?

Question

Let\'s say you know your software will only run on two\'s complement machines where signed overflow behavior is nicely defined. Signed overflow is still undefined behavior in C

Answer 1

"Undefined behaviour" means the C resp. C++ standards don't define the behaviour of your program. If your program contains inline assembly, it should be pretty clear that its behaviour won't normally be described by either the C or the C++ standard. Some other standard might even define the behaviour, but that still doesn't mean "defined behaviour" in the context of the C or C++ standard.

That said, the C standard does require documentation of supported extensions. If the behaviour of your program can be inferred from your implementation's documentation, and your implementation makes your program behave differently, that is a failure of your implementation to conform to the standard:

4. Conformance

8 An implementation shall be accompanied by a document that defines all implementation-defined and locale-specific characteristics and all extensions.

For C++, this requirement has been weakened:

1.4 Implementation compliance [intro.compliance]

9 Each implementation shall include documentation that identifies all conditionally-supported constructs that it does not support and defines all locale-specific characteristics.

and

1.9 Program execution [intro.execution]

2 Certain aspects and operations of the abstract machine are described in this International Standard as implementation-defined [...] Each implementation shall include documentation describing its characteristics and behavior in these respects. [...]

I'm unable to find a requirement for extensions to be documented, and if documented, to be documented correctly. This would suggest that in C++, even if your implementation defines the behaviour of your program as an extension, if it turns out the documentation is wrong, that's just too bad.

For the C++ semi-standard asm statement (as mentioned in the comments, "The asm declaration is conditionally-supported; its meaning is implementation-defined."), if your implementation supports it it needs to be documented, but of course it's common practice for implementations to support inline assembly in a different manner than hinted by the C++ standard, so this doesn't give you much extra.

Answer 2

As soon as you say that you have signed overflow in inline asm, it means that you are speaking of a particuliar compiler (or a set of compiler) because in C as in C++ the support for asm declaration and its meaning are compiler defined.

If the compiler defines the asm keyword by allowing direct inclusion of assembly code in its output and if the machine allows signed overflow, then a signed overflow in the inline asm is perfectly defined for that compiler and that machine: it is what the processor will give as result. You should still control whether it can result in a trap representation for a signed integer but anyway it is defined. The only case that would end in UB would be when the compiler says that some representation in signed integer will cause undefined behaviour. But I know none that do and you are already in the context of a defined and finite set of compilers and machines.

Separate compilation of an assembly module and C and/or C++ code would be the same for that set of compilers and machines: result is implementation defined which is not the same as UB.

Another example of something that is explicitely implementation defined in the standards (both C and C++) is whether char type is signed or not: if you do not know what compiler you use, you cannot rely on it, but as soon as you choose a compiler implementation, that implementation is required to say whether it is signed or unsigned, and it is not undefined behaviour, meaning that the compiler cannot replace the full code with a ret for example.