Bug 44209 - [meta-bug] Some warnings are not linked to diagnostics options
Summary: [meta-bug] Some warnings are not linked to diagnostics options
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.4.4
: P3 major
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic, easyhack, meta-bug
Depends on: 7651 45977 61414 80529 83773 67353
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-20 11:18 UTC by Eric Estievenart
Modified: 2018-01-10 19:00 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-05-23 17:06:49


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Estievenart 2010-05-20 11:18:04 UTC
Sorry, I report this bug with a Major severity, because it applies to all front-ends and backends.

Consider the following code:
----
static void f() __attribute__((warning("should not be linked")));
void f() {}
int main() { f(); }
---
You just can't compile it without removing -Werror,
because there is no diagnostic option associated:
==================================================
$ gcc -Werror -fdiagnostics-show-option -c test.c
..
test.c:3: error: call to ‘f’ declared with attribute warning: should not be linked

============== Context ==========
I think that serious developpers compile their code with options like
-Wall -Werror....
and on some files or builds disable either a warning:
-Wno-unused-parameter
or let the warning be shown but don't make it an error:
-Wno-error=unused-parameter  (e.g. in debug builds)

The conditions depend on the files, type of build, organization preferences, etc;
combining -Wall.. and -Werror is for me a prerequisite for high-quality code,
so removing -Werror is barely unacceptable; it'll go in the makefiles, be dumped
into the source-control, and time will be lost looking for a bug which would
have been detected and blocked by the compiler instead of on the field.

I would just recommend that within gcc, it would be impossible to emit a warning
without having it associated to a diagnostic.

I'm not providing a patch yet, but if you think that the idea is valuable, I'll
consider digging into the code. The amount of work fixing all backends is probably huge,
so it should be incremental.

Sincerely
Comment 1 Jonathan Wakely 2010-05-20 11:40:15 UTC
IMHO this is an enhancement request, not severity=Major

-Werror is not on by default, if you choose to enable it then you deal with the consequences.

Obviously the ideal is for every warning to be controllable by an option, but until that happens gcc behaves as documented and if -Werror is not suitable for your program then don't use it.
Comment 2 Jonathan Wakely 2010-05-20 11:45:16 UTC
N.B. Bug 44054 is the PR for the fortran FE to support -Werror= etc.
Comment 3 Manuel López-Ibáñez 2010-05-23 17:06:48 UTC
There are two cases:

* Warnings that are controlled by an option (e.g., Wall) but do not show up in -fdiagnostics-show-option. These are obvious bugs and normally trivial to fix: there is already an -Wsomething option controlling them but the warning call is done with warning (0, "warning") instead of warning (OPT_Wsomething, "warning"). If you provide me a list of those that you can find, I will fix them.

* Warnings that are not controlled by any option and are enabled by default. These cases are not clear-cut because we do not want millions of options, so we would prefer to group related warnings under the same option. Also, proposing a good -Wname for the option is always controversial. I don't think there are many of these, but a list of the worst offenders would also help.
Comment 4 Eric Gallager 2017-07-26 15:33:02 UTC
(In reply to Manuel López-Ibáñez from comment #3)
> There are two cases:
> 
> * Warnings that are controlled by an option (e.g., Wall) but do not show up
> in -fdiagnostics-show-option. These are obvious bugs and normally trivial to
> fix: there is already an -Wsomething option controlling them but the warning
> call is done with warning (0, "warning") instead of warning (OPT_Wsomething,
> "warning"). If you provide me a list of those that you can find, I will fix
> them.
> 
> * Warnings that are not controlled by any option and are enabled by default.
> These cases are not clear-cut because we do not want millions of options, so
> we would prefer to group related warnings under the same option. Also,
> proposing a good -Wname for the option is always controversial. I don't
> think there are many of these, but a list of the worst offenders would also
> help.

Making this a meta-bug; will add relevant bugs as dependencies to this one as I find them. That can count as a list.