> the compiler doesn't know what SIGKILL does, so it doesn't know the UB is unreachable in practice, so it may reorder etc It is the reverse. If the compiler d

> the compiler doesn't know what SIGKILL does, so it doesn't know the UB is unreachable in practice, so it may reorder etc It is the reverse. If the compiler doesn't know what raise(SIGKILL) (or really, any other function it cannot see through) does, it has to assume that it can potentially never terminate, abort or otherwise change the control flow, so it can't safely reorder across it. And even if it does return, it could still inspect memory and observer the violation of the as-if rule. That's why for example pthread_mutex_lock/unlock worked correctly for the most part even before C++ got a proper concurrent memory model.