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
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.