I apologize for stating that you had reported the issue. I copy/pasted from your comment rather than the original report. The issue was reported by Teodor Petrov
Kevin ---- "Manuel López-Ibáñez" <lopeziba...@gmail.com> wrote: > > On 03/28/2016 01:56 PM, Florian Weimer wrote: > >>> In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though > >>> he provides the "-Werror=return-type" option, the compiler doesn't > >>> flag the warning/error about a control reaching the end of a non-void > >>> function, due to the presence of the "-w" option. He points out that > >>> clang++ wtill flags the promoted warning even though warnings are > >>> inhibited. > > I did not report the bug and did not mention anything of the above. I only > commented on why GCC works like it works and how one can change the behaviour > if so desired. I don't care one way or the other and I can see benefits for > either behaviour. > > >> I think -w is ordered with respect to the other warning obtions, and > >> -w inhibits previously requested warnings, and future -W flags may > >> enable other warnings. With this in mind, I agree that the current > >> GCC behavior is consistent and probably not a bug. > > The command-line order does not affect '-w' and there is no way to undo '-w'. > It is a global boolean switch independent of anything else (including > pragmas) > that disables warnings just before they are re-classified (by pragmas or > -Werror=) into something else. This means that if -Wfoobar is given in the > command-line (or enabled by a pragma) and it requires an expensive analysis, > this analysis is done even in the presence of -w, only the warning message is > not emitted. > > One question to answer if the behaviour does change is what would be the > effect > of using '-w' on warning options enabled by #pragmas. Some people may still > want a switch that simply disables all warnings no matter how they are > enabled. > > Cheers, > > Manuel.
