I never do -Wall and -Wextra. Why? Because too many of clang's warning switches have names that have little to do with what they actually warn about. One in particular has to do with it finding duplicate selectors in different classes. I can never remember what it's called, but it's very annoying when you need to find it to disable it. Even worse, when you disable that particular flag, it disables a whole bunch of other actually useful warnings as well!
You also DON'T want to do -Wall and -Wextra along with -Werror. Why? Because when a later version of the compiler gets smarter and puts in more warnings, suddenly your (working) code won't compile anymore! That would go over very poorly in a CI system or an open source library! Your "future proofing" has just ensured that sometime down the road (and likely at an inconvenient time), your project is guaranteed to break!
Firstly, when clang warns you of an error, it tells you the switch it uses to highlight that error, the disabling flag is then "-Wno-$switch" (or simply use a clang pragma to disable the warning: http://stackoverflow.com/questions/7017281/performselector-m...)
Secondly, the errors reported by -Wall and -Wextra are likely to be program bugs / bugs further down the line.
Thirdly: I upgraded my compiler on my CI system, I'd damn well want to know about new errors!
"I can never remember what it's called, but it's very annoying when you need to find it to disable it."
These days, clang will tell you what a warning is called any time it gives you one. If you ever need to disable a warning, make it happen (which you probably already did, otherwise why would you need to disable it?) and then just read the error message to see what flag to use to disable it.
What is wrong with breaking the build when the underlying assumptions change? I consider this a good thing. My initial assertion that many warnings are latent errors (bugs) implies that the most inconvenient time is when the product is in the hands of users.
I have another guideline that I frequently apply: Don't update your tools if you're close to cutting a new release. This mitigates the risk of unexpected build issues a the worst possible time.
You also DON'T want to do -Wall and -Wextra along with -Werror. Why? Because when a later version of the compiler gets smarter and puts in more warnings, suddenly your (working) code won't compile anymore! That would go over very poorly in a CI system or an open source library! Your "future proofing" has just ensured that sometime down the road (and likely at an inconvenient time), your project is guaranteed to break!