https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99418
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Asan can't by design detect neither #c0 nor #c1, only ubsan can. The reason why ubsan has that off by one stuff is that in C/C++, &mas[n - 1][m] is not undefined behavior, only mas[n - 1][m] is. And with classes, it actually means calling some method with &mas[n - 1][m] argument. For #c1, the big question is what exactly is UB in C++, whether already binding a reference to the object after the end of the array or only actually accessing that reference. If the former, ubsan could treat REFERENCE_TYPE differently, if the latter, then I'm afraid it can't do that, and ubsan by design has to be done early before all the optimizations change the IL so much that it is completely lost what were the user errors in it. For the method calls, there really isn't a reference in the IL either, this argument is a pointer, but .UBSAN_BOUNDS calls are added in the FE and so perhaps it could know it is a method call and treat it as a reference. So, something can be done but we need answers on where the UB in C++ exactly happens.
