Query regarding usage of optimizations on Sanitizers in Clang


I have been using Sanitizers/Archer for testing purposes on C,C++ and Fortran test suites. I notice some change in sanitizer behaviour when I add any kind of optimization to it ( O1, O2, Ofast etc). For example, in the following test case:

#include <alloca.h>

void foo(int index, int len) {

volatile char str = (volatile char)alloca(len);

str[index] = ‘1’; // Boom!


int main(int argc, char **argv) {

foo(-1, 10);


Compiling it with : clang -g -fsanitize=address Test_case.c

Gives me ASan report :

==80838==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffdd959ac3f at pc 0x00000050ea21 bp 0x7ffdd959ac10 sp 0x7ffdd959ac08

WRITE of size 1 at 0x7ffdd959ac3f thread T0


Address 0x7ffdd959ac3f is located in stack of thread T0

SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow (/ptmp1/bhararit/new_petest/petest/cc_address_sanitizer.ar/diffs/a.out+0x50ea20)

But when I compile it with optimization: clang -g -fsanitize=address -O1 Test_case.c

I do not see any Sanitizer report.

Is this an expected behaviour? If yes, should we be disabling optimizations before using sanitizers although the clang document states that O2 or higher level of optimizations can be used to enhance the performance. Lastly, what is the default optimization in clang ( is it -O0?)?

It would be very helpful if you could give me more insights on this. Hope to hear from you. Thanks in advance.

Best Regards,


This looks like ASan FAQ item #2:

Q: Why didn’t ASan report an obviously invalid memory access in my code?
A1: If your errors is too obvious, compiler might have already optimized it out by the time Asan runs.

I would have liked to find clear documentation on the tradeoffs of using optimizations in the main documentation here, but I only see a recommendation to use -O1:

To answer your question, the behavior is expected. Also, Clang’s default optimization level is -O0.

I think the consensus among most ASan users is that optimizing before instrumentation is the right tradeoff between accuracy and performance. You are welcome to test with -O0 to find these kinds of trivial issues, but many users find that running tests under -O0+ASan is too slow to be feasible.

Another way of looking at it is that the compiler has optimized away the OOB store here, and if you ship an optimized build, ASan is correctly telling you that there is no OOB write in the shipping build. Godbolt shows your example optimizes main to just return 0, so the program doesn’t do an OOB write at runtime:

Hope that helps.