public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dmalcolm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug analyzer/100524] pragma GCC diagnostic ignored "-Wanalyzer-too-complex" ignored by cc1 Date: Tue, 30 Nov 2021 19:23:56 +0000 [thread overview] Message-ID: <bug-100524-4-7KAbs9GUh2@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-100524-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100524 David Malcolm <dmalcolm at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |WAITING Last reconfirmed| |2021-11-30 Ever confirmed|0 |1 --- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> --- Thanks for filing this bug. Firstly, what you wrote in comment #0 has the directive transposed as: #pragma diagnostic GCC [...action...] whereas the directive should be: #pragma GCC diagnostic [...action...] I've tested the latter with a simple reproducer and verified that I can disable -Wanalyzer-too-complex with it, whereas the transposed version of the directive is ignored by GCC and thus does nothing; I'm working on a regression test for this. Secondly, there's an issue with source locations in the diagnostic you quoted: the prefix: "cc1: error: " doesn't contain a source location. Internally this comes from diagnostic_build_prefix when the diagnostic's location has a NULL filename, which is most likely due to a statement with an UNKNOWN_LOCATION. So the issue is due to a statement in GCC's gimple-ssa IR having UNKNOWN_LOCATION for its location, which thus doesn't show up within the range of source locations expressed by the pragma, and thus the diagnostic isn't affected by the pragmas. The fix would be to fix the location of the statement in the gimple-ssa IR, but without a reproducer to identify where that statement's coming from (e.g. in one of the passes that runs before the analyzer), that's hard to do. Do you still have the code that reproduces this issue? (and the precise optimization flags)
next prev parent reply other threads:[~2021-11-30 19:23 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-11 14:46 [Bug analyzer/100524] New: " andrew at ishiboo dot com 2021-11-30 19:23 ` dmalcolm at gcc dot gnu.org [this message] 2021-11-30 22:50 ` [Bug analyzer/100524] " cvs-commit at gcc dot gnu.org 2021-11-30 23:04 ` dmalcolm at gcc dot gnu.org 2021-12-01 0:29 ` egallager 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-100524-4-7KAbs9GUh2@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).