Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
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'm thinking that not reporting the promoted error is the correct and desired behavior, based on two factors: 1) Warnings are inhibited, so there is no warning to promote. 2) The comment in diagnostic.c which reads: /* Give preference to being able to inhibit warnings, before they get reclassified to something else. */ I was looking at this issue as one I could use to get my feet wet in GCC maintenance , and would be glad to take on if it is decided that it is desired, which I would argue that it is not, but I thought I'd open up discussion on the topic. I have worked on the MIcrochip PIC18 C compiler, and worked for DDC-I, supporting their compiler suites,(Ada, C/C++) as well as some work on the ASIS standard, and thought it might be fun to work on GCC. Looking forward to reading discussion on the topic! Kevin Tucker
Re: Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
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" 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.
