Wow. When I worked as a developer, one thing I would always insist on (or push for when I was not senior enough to insist on things) was -Wall and -Werror. If your code has a warning, there is a reason for it and you should address it. Sometimes the warning is benign, so you address it with a thoughtful comment to the effect of "silence X warning - it's not a factor because Y". But at least address them! Reasons to be so anal on warnings:

1. Broken windows theory. A code base full of warnings signals that nobody cares about anything. People will get better about finding and caring about the big things when they are forced to also care about the little things.

2. When your project has a "wall of warnings" there are real bugs hiding in there. I guarantee it and would bet money on it. Here's your opportunity to fix them and you don't even need QA to point them out. Your compiler is literally telling you.

3. When things compile on one box but not another, that's a big red flag that you have something platform-specific or library version-specific that WILL bite you some time later. unsigned-signed and sizeof(int) mismatches are good examples of this.

The whole "it compiles and works therefore it's done" mentality is some serious "second-year programming class" level shit, but it's everywhere. Good projects, where people care and have disciplined attitudes, discourage it.