>Data races don't imply memory unsafety (in the sense of having OOB accesses etc.).
Data races are undefined behavior on all major programming languages (C, C++, Rust, Java, Go, Swift, ...) and all major compilers compile code under the assumption that they do not happen.
If your program has a data-race, neither the language specification nor the compiler make any guarantees about the behavior of such programs.
Needles to say, this is neither safe, nor desirable, nor doing so produces perfectly safe programs.
The idea that data-races are safe because the load and store memory instructions that the CPU has are atomic is completely flawed, because it ignores the fact that the CPU does not execute the program you wrote, but the machine code that the compiler generates, and the compiler can and will reorganize non-atomic loads and stores under the assumption that they don't need to be atomic.
If your program has a data-race, the compiler provides no guarantees. It does not guarantee that the binary will reach the location where the data race happens. It does not even guarantee that the binary produced will be an executable binary, or that it will produce a binary at all (e.g. it does not guarantee that compilation terminates successfully).