How does optimization trip valgrind false positives?

To quote a Valgrind tutorial:

Optimized code can cause valgrind to wrongly report uninitialized value errors. The authors know how to fix this, but it would make valgrind much slower (and it is already quite slow). The suggested fix for this is to not optimize when trying to debug code with valgrind. Not optimizing when debugging is a good rule of thumb anyway.

(Source: https://people.gnome.org/~newren/tutorials/developing-with-gnome/html/ch03s03.html)

What type of optimizations would cause this, and how are they not real problems?

What type of optimizations would cause this, and how are they not real problems?

One specific instance: glibc has strlen() that

• establishes that a pointer is 4-byte aligned and
• reads 4 bytes at a time, then uses bit-twiddling tricks to determine whether any of these 4 bytes was a 0.

This is "safe" in that it can never cause a crash (reading 4 bytes from a 4-byte aligned pointer can never cross a page boundary), but it may "over-read" past the end of an allocated block (e.g. if the string came from strdup("hello") -- here only 6 bytes were allocated, yet strlen will read 8).

Now, this particular instance is not a problem for Valgrind because it redirects strlen to its own copy.

But similar loop unrolling could happen in your own code under optimization, and then Valgrind will report a false positive.