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 and C++ and the compiler is free to replace your entire program with "ret", start a nuclear war, format your drive, or make demons fly out of your nose.
Suppose you have signed overflow in inline asm, does your program still invoke UB?
If yes, What about separately compiled and linked assembler?
"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:
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.
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.