https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387
--- Comment #3 from Dmitry Babokin <babokin at gmail dot com> --- Interesting that you've mentioned -fno-sanitize-recover, I haven't realized that it has effect on the number of basic blocks. But by default I run "-fsanitize=undefined -fno-sanitize-recover=undefined", so the numbers that I posted are for this combination (-fno-sanitize-recover=all is effectively the same). I've tried without -fno-sanitize-recover=undefined and it is: -O2 -fsanitize=undefined: 358s, 62Gb -O1 -fsanitize=undefined: 280s, 2.7Gb Also clang trunk: -O2 -fsanitize=undefined: 173s, 1.5Gb -O2 -fsanitize=undefined -fno-sanitize-recover=undefined: 224s, 1.8Gb I understand that the reasons for consuming more memory with UBSAN enabled are quite fundamental, but looking at such an extreme increase may uncover problems when algorithms consume more that they supposed to. Again, I'm not insisting on fixing it, I'm rather drawing attention to suspicious behaviour, which you may consider worth looking at.