I added a section to the boost warnings guidelines page about suppressing warnings with GCC. I think it's pretty good bringing together information I got on the gcc-help list, from reading the source and from browsing through the documentation for various releases of GCC. If anyone wants to check it for correctness and/or style I would be very appreciative. I would in particular like to thank Jonathan Wakely for his willingness to help and for the great help he gave me on the gcc-help list. https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines If you scroll to the bottom directly you'll see the end of the section on suppressing GCC warnings. I moved it after the sections on turning on warnings and on how to deal with some common warnings to reflect the viewpoint of the document that suppressing should be the last resort. I have some improvements to make to the section on strict aliasing to reflect the better work I did in my white paper on the subject, and I know the common warnings section needs information on more common warnings. The way I picked the ones that are in there originally was by turning on warnings for an earlier version of boost, saving the output of building the whole tree, then checking to see what the most common warnings were that indicated real bugs. That was without running tests or any program that used boost. Just building boost. It's been a long time and much good work has been done in the tree to get rid of those, so I should take a look at that again by turning on the -Wsystem-headers -Wall -Wextra and maybe -Wpedantic and seeing what warnings pop up in boost code that indicate real problems again. Wouldn't it be great if there were none? The most painful one is -Wsystem-headers which tells GCC to report warnings even in files considered system files, but since many of the boost files include the #pragma GCC system_file it will be necessary to see the warnings. Unfortunately, that means that I'll see warnings from real system files as well. In boost there are 21 headers that include the pragma, 15 of them in boost/exception. It's possible that they all really have spurious warnings you can't code around. Those certainly exist. I hope they're documented as to why they use the pragma to save me time looking at them. Perhaps I'll find real bugs in them. Probably not though. Thank you, Patrick