>>72
Something I'd like is a C dialect with all undefined behavior defined as would be best for x86_64.
You don't understand what undefined behaviour is for.
It is not about multi-platform support, by and large. It is in fact exactly about compiler optimizations, for most parts, at least these days.
For example, when the standard says that integer overflows are undefined, it is not because your code is supposed to run on a non-two-complement machine, but because then the compiler is free to assume that when you write
x++ you know that x will not overflow (for some reasons that are outside of the compiler's reach), and then it knows that the new value is greater than the old, and can use this knowledge for various optimizations, like, now it knows that you are not going to access the previous array element and can delay the memory store.
The same goes for pointer aliasing rules (accessing an int via a pointer to double is undefined, so the compiler should not worry that a store to double might make it necessary to reload the integer loop variable from memory), stuff like pointer arithmetic being undefined outside the allocation unit, and so on.
This is an unscientific and ultimately destructive dead end obviously, but C has painted itself into this corner by overspecifying the low-level details of its Abstract Machine. Which seemed like a good idea at the time, but then the inertia has carried the whole thing much farther than is sane.