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
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.
N.B. Bug 44054 is the PR for the fortran FE to support -Werror= etc.
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.
(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.
I am using this as a jumping-off point to get involved with contributing code to gcc. I have nothing to offer yet, but I wanted to note here that I am going to start looking into this. Will
(In reply to Will Hawkins from comment #5) > I am using this as a jumping-off point to get involved with contributing > code to gcc. I have nothing to offer yet, but I wanted to note here that I > am going to start looking into this. > > Will OK cool, do you want to be the assignee then?
additional example raised on gcc mailing list: https://gcc.gnu.org/pipermail/gcc/2023-July/241970.html
I have a patch ready for the noreturn warning at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654, is anyone willing to help review and push it?
For the sake of other potential readers: Patches should be submitted to gcc-patches@gcc.gnu.org and reviewers do not review patches in bugzilla. Nevertheless, it is a good idea to add the link to the mailing list archive here in bugzilla so the patch is not forgotten. For more details, please read: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps How to submit and ping patches: https://gcc.gnu.org/contribute.html#patches See other suggestions on how to interact with the GCC community here: https://gcc.gnu.org/wiki/Community
The master branch has been updated by Florian Weimer <fw@gcc.gnu.org>: https://gcc.gnu.org/g:857a6ee25ff5cbb97715de4dd97e1641285c6085 commit r14-4804-g857a6ee25ff5cbb97715de4dd97e1641285c6085 Author: Florian Weimer <fweimer@redhat.com> Date: Fri Oct 20 21:27:52 2023 +0200 c: -Wincompatible-pointer-types should cover mismatches in ?: gcc/c/ PR c/109826 PR other/44209 * c-typeck.cc (build_conditional_expr): Use OPT_Wincompatible_pointer_types for pointer mismatches. Emit location information for the operand. gcc/testsuite/ * gcc.dg/Wincompatible-pointer-types-2.c: New. * gcc.dg/Wincompatible-pointer-types-3.c: New. * gcc.dg/Wincompatible-pointer-types-4.c: New.
The master branch has been updated by Florian Weimer <fw@gcc.gnu.org>: https://gcc.gnu.org/g:7069ea909f5292a17d22e5e68218373186820d29 commit r14-4805-g7069ea909f5292a17d22e5e68218373186820d29 Author: Florian Weimer <fweimer@redhat.com> Date: Fri Oct 20 21:27:52 2023 +0200 c: -Wint-conversion should cover pointer/integer mismatches in ?: gcc/c/ PR c/109827 PR other/44209 * c-typeck.cc (build_conditional_expr): Use OPT_Wint_conversion for pointer/integer mismatch warnings. gcc/testsuite/ * gcc.dg/Wint-conversion-3.c: New.
The master branch has been updated by Florian Weimer <fw@gcc.gnu.org>: https://gcc.gnu.org/g:ff9efa3fc48baa1dee7ed376c25ecfcfbc28d35c commit r14-6038-gff9efa3fc48baa1dee7ed376c25ecfcfbc28d35c Author: Florian Weimer <fweimer@redhat.com> Date: Fri Dec 1 08:10:13 2023 +0100 c: Add new -Wdeclaration-missing-parameter-type permerror This used to be a warning, enabled by default, without its own option. A subsequent change could improve diagnostics and provide spelling hints for declarations like âvoid function (int32t);â. gcc/c-family/ * c.opt (Wdeclaration-missing-parameter-type): New. gcc/c/ChangeLog: PR other/44209 * c-decl.cc (grokparms): Issue permerror for OPT_Wdeclaration_missing_parameter_type instead of a pedwarn. gcc/ChangeLog: * doc/invoke.texi (Warning Options): Document -Wdeclaration-missing-parameter-type. gcc/testsuite/ChangeLog: * gcc.dg/permerror-default.c (missing_parameter_type): Expect error. * gcc.dg/permerror-fpermissive.c (missing_parameter_type): Expect -Wdeclaration-missing-parameter-type warning. * gcc.dg/permerror-gnu89-nopermissive.c (missing_parameter_type): Expect -Wdeclaration-missing-parameter-type error. * gcc.dg/permerror-gnu89-pedantic.c (missing_parameter_type): Likewise. * gcc.dg/permerror-gnu89.c (missing_parameter_type): Expect -Wdeclaration-missing-parameter-type warning. * gcc.dg/permerror-noerror.c: Add -Wno-error=declaration-missing-parameter-type to build flags. (missing_parameter_type): Expect -Wdeclaration-missing-parameter-type warning. * gcc.dg/permerror-nowarning.c: Build with -Wno-declaration-missing-parameter-type. Remove previously expected warning. * gcc.dg/permerror-fpermissive-nowarning.c: Likewise. * gcc.dg/permerror-pedantic.c (missing_parameter_type): Expect -Wdeclaration-missing-parameter-type error. * gcc.dg/permerror-system.c (missing_parameter_type): Likewise.