I've been hoping for a C/C++ compiler with no/limited undefined behavior for years. Sadly, the people writing compilers have lost touch with the people using them, so this is very unlikely to happen.
But I have to say, if one is going to do this, then C isn't a good target. Especially for crypto, C lacks extremely useful semantics such as rotate-left, rotate-right, add-with-carry, subtract-with-borrow, etc. Things that would greatly accelerate libraries that work with 512-bit multiplies like DJB's Curve25519. And then there's useful math operators like power-of that could be added.
You could also put requirements in there like "warn/error on variable-length divide" to catch surprise gotchas like x86 CPUs taking an indeterminate length of time to divide. In fact, constant-time execution could be a compile-time check.
The key would be to keep it "as much C" as possible. Rust and co are going to face barriers by being so incredibly different from C.
The biggest problem Rust has with crypto is that the canonical compiler is built on LLVM, so no matter what a human writes, it'll get ground up by the optimizer and may turn into something quite different. Rust has an advantage in that it doesn't have the undefined-behaviour gotchas of modern C/C++, so LLVM won't optimize away all your sanity checks, but that's not a strong enough guarantee for crypto work—as you point out, you need strong control over assembly instructions to maintain constant-time execution.
That problem is true of practically any language, even C and C++, and the solution is the same (and well accepted) for all of them: write a small set of controlled primitives in raw assembly, and let the "high level" language compose them. Obviously using assembly forgoes safety for those pieces of code, but being primitives they've typically fairly small, and have straight-forward memory access patterns/behaviour.
But I have to say, if one is going to do this, then C isn't a good target. Especially for crypto, C lacks extremely useful semantics such as rotate-left, rotate-right, add-with-carry, subtract-with-borrow, etc. Things that would greatly accelerate libraries that work with 512-bit multiplies like DJB's Curve25519. And then there's useful math operators like power-of that could be added.
You could also put requirements in there like "warn/error on variable-length divide" to catch surprise gotchas like x86 CPUs taking an indeterminate length of time to divide. In fact, constant-time execution could be a compile-time check.
The key would be to keep it "as much C" as possible. Rust and co are going to face barriers by being so incredibly different from C.