I believe GP is talking about -fbounds-safety [0, 1]. From my understanding this will cause the compiler to emit an error if it can't figure out how to bounds check a pointer access at either compile time or run time. You then need to either add appropriate annotations to provide the missing information or otherwise restructure the code to satisfy the compiler.

[0]: https://clang.llvm.org/docs/BoundsSafety.html

[1]: https://clang.llvm.org/docs/BoundsSafetyAdoptionGuide.html

As implemented in the most popular compilers "-fsanitize=address" is indeed slow.

However, for the majority of the code of a program, enabling this and all the other sanitize options will have a negligible effect on the useful performance.

Like I have said, sanitize options should be disabled in performance-critical sections, which have been identified as such by profiling, not by guessing, but only after examining those sections thoroughly, to be certain that the undefined behavior cannot be triggered.

Currently, the sanitize options are significantly slower than they should be in an optimized implementation, because there is a vicious circle. The application developers do not enable such options for production because they believe that they are slow and the compiler developers do not make the effort to improve their speed, because they believe that the application developers will not enable them in production code anyway.

However, these problems are not inherent to the language or compiler, they are caused by a bad historical tradition of neglecting the correctness of a program whenever cheating can improve the performance in the best case (which will be the only one demonstrated to potential customers), even if that makes the worst case catastrophic.

Even Rust is not immune to bad traditions, e.g. by disabling overflow checking in release builds, as opposed to debug builds.