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)

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