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.

  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: link
Be 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).