This question is not specific to C++, just uses C++ stuff as examples.
A widespread opinion is that "treat all warnings as errors" (like /WX Visual C++ option) is good because a warning is a bug waiting to happen (btw the linked thread is full of "I target for zero warnings" statements).
The only counterargument I've seen so far is that some third-party code will not compile without warnings.
Okay, let's for the duration of this question pretend the compiler has means of temporarily disabling warnings in some code (like this thing in Visual C++):
#pragma warning(push)
#pragma warning(disable:X)
#include <ThirdParty.h>
#pragma warning(pop)
and then the third party code is not a problem anymore.
Assuming we fully control all the code (no third party or we can disable warnings in third party code only) what are reasons for not treating warnings as errors?
Because sometimes you know better than the compiler.
It's not necessarily often with modern compilers, but there are times when you need to do something slightly outside of the spec or be a little tricky with types, and it is safe in this particular case, but not correct. That'll cause a warning, because technically it's usually mostly wrong some of the time and the compiler is paid to tell you when you might be wrong.
It seems to come down to the compiler usually knowing best but not always seeing the whole picture or knowing quite what you mean. There are just times when a warning is not an error, and shouldn't be treated as one.
As you stray further from standard use, say hooking functions and rewriting code in memory, the inaccurate warnings become more common. Editing import tables or module structure is likely to involve some pointer arithmetic that might look a little funny, and so you get a warning.
Another likely case is when you're using a nonstandard feature that the compiler gives a warning about. For example, in MSVC10, this:
enum TypedEnum : int32_t
{
...
};
will give a non-standard extension warning. Completely valid code when you're coding to your compiler, but still triggers a warning (under level 4, I believe). A lot of features now in C++11 that were previously implemented as compiler-specific features will follow this (totally safe, totally valid, still a warning).
Another safe case that gives a warning is forcing a value to bool, like:
bool FlagSet(FlagType flags) { return (flags & desired); }
This gives a performance warning. If you know you want that, and it doesn't cause a performance hit, the warning is useless but still exists.
Now, this one is sketchy as you can easily code around it, but that brings up another point: there may be times when there are two different methods of doing something that have the same results, speed and reliability, but one is less readable and the other is less correct. You may choose the cleaner code over the correct code and cause a warning.
There are other cases where there is a potential problem that may occur, which the warning addresses. For example, MSVC C4683's description literally says "exercise caution when..." This is a warning in the classic sense of the word, something bad could happen. If you know what you're doing, it doesn't apply.
Most of these have some kind of alternate code style or compiler hint to disable the warning, but the ones that don't may need it turned off.
Personally, I've found that turning up the warnings and then fixing them helps get rid of most little bugs (typos, off-by-one, that sort of thing). However, there are spots where the compiler doesn't like something that must be done one particular way, and that's where the warning is wrong.