A C++ or C compiler that generates code to check signed-integer overflow by default, and do anything at all (call a handler, throw an exception, dump core, close your network connection, erase your disk) is completely standard-conforming. Gcc and Clang could have such a feature in no time, if any of you-all cared to code it. Firefox and Chrome could use it immediately after. Probably the speed would not be noticeably affected.
But of course then the ground would shift to plug-ins and libraries. Most of those could be compiled using the same compiler option, for the same benefit, just as we-all already use our compilers' built-in stack-smashing protection (don't we?).
Likewise, any C or C++ compiler may do anything it likes with out-of-bound accesses to native array types. Code it, and anyone using Gcc or Clang can use it for free. Again, the resulting programs would still be miles faster than your favorite wanklage.
Do you run valgrind on code you are responsible for? Why not? Even in production use, C or C++ code running under valgrind is still faster than in most "advanced", "high-level" languages. Valgrind can also respond to violations it detects in programmed ways, independent of compiler or library.
The fault, dear brute, is not in our languages, but in ourselves, that we code insecurely.