public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/104148] [11/12 Regression] -Wformat warning no longer warns about () wrapped args since r11-2457 Date: Fri, 21 Jan 2022 21:45:43 +0000 [thread overview] Message-ID: <bug-104148-4-oy6weWT5nP@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-104148-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104148 --- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:f36efe71bef8ddf72306aca313d28759434cf97a commit r12-6810-gf36efe71bef8ddf72306aca313d28759434cf97a Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Jan 21 22:44:53 2022 +0100 c-family: Fix up a -Wformat regression [PR104148] As can be seen on the testcase, GCC 11 no longer warns if the format string is wrapped inside of ()s. This regressed with r11-2457-gdf5cf47a978, which added if (TREE_NO_WARNING (param)) return; to check_function_arguments_recurse. That function is used with a callback for two cases, for -Wformat and for -Wnonnull. For the latter it is desirable to not warn in parameters or their subexpressions where that warning is suppressed, but for -Wformat the function is used solely to discover the string literals if any so that the c-format.cc code can diagnose them. I believe no warning suppression should stand in the way of that, -Wformat* warnings should be decided from warning suppression on the CALL_EXPR only. In the PR Martin argued that now that we have specialized warning_suppressed_p we should use it, so instead of adding a bool arg to check_function_arguments_recurse I've added opt_code to the function, but will defer the warning_suppressed_p change to him. For OPT_Wformat_ we don't want to call it anyway at all (as I said, I think there should be no suppression for it during the string discovery, there isn't just one -Wformat= option, there are many and warning_suppression_p even with no_warnings actually tests the TREE_NO_WARNING bit). Initially, I thought I'd restrict also call to fn with format_arg attribute handling in check_function_arguments_recurse to OPT_Wformat_ only, but after looking around, it perhaps is intentional that way, most functions with format_arg attribute don't have nonnull attribute for that arg too, various gettext implementations handle NULL argument by passing it through, but when result of gettext (NULL) etc. is passed to non-NULL argument, it makes sense to warn. 2022-01-21 Jakub Jelinek <jakub@redhat.com> PR c++/104148 * c-common.h (check_function_arguments_recurse): Add for_format arg. * c-common.cc (check_function_nonnull): Pass false to check_function_arguments_recurse's last argument. (check_function_arguments_recurse): Add for_format argument, if true, don't stop on warning_suppressed_p. * c-format.cc (check_format_info): Pass true to check_function_arguments_recurse's last argument. * c-c++-common/Wformat-pr104148.c: New test.
next prev parent reply other threads:[~2022-01-21 21:45 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-20 18:14 [Bug c++/104148] New: " jakub at gcc dot gnu.org 2022-01-20 18:15 ` [Bug c++/104148] " jakub at gcc dot gnu.org 2022-01-20 18:18 ` jakub at gcc dot gnu.org 2022-01-20 18:50 ` jakub at gcc dot gnu.org 2022-01-20 19:01 ` jakub at gcc dot gnu.org 2022-01-20 19:11 ` msebor at gcc dot gnu.org 2022-01-20 19:49 ` jakub at gcc dot gnu.org 2022-01-21 21:45 ` cvs-commit at gcc dot gnu.org [this message] 2022-01-21 21:47 ` [Bug c++/104148] [11 " jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-104148-4-oy6weWT5nP@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).