public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow
Date: Tue, 22 Jun 2021 15:27:33 +0000	[thread overview]
Message-ID: <bug-101134-4-Rmlc7JnNzh@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-101134-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
It wouldn't be right to change the wording of just one warning because the
problem applies to all flow based diagnostics.  They all depend on various
optimizations that propagate constants, add or remove tests, and change the
control flow graph.  A statement that in the source code is conditional on the
values of various parameters might in the intermediate representation appear
unconditional with constants as a result, even be unconditionally invalid but
unreachable.  This is true at function scope as well as across function call
boundaries thanks to inlining.  Changing the wording for all of them to try to
somehow reflect this wouldn't help because then all instances of them all would
have to use the new form.

-Wuninitialized and -Wmaybe-uninitialized aren't substantially different in
this.  The latter is unique only in that it diagnoses arguments of PHI nodes,
which are the results of conditional expressions.  This property is described
by the following sentence in the manual:

"...if there exists a path from the function entry to a use of the object that
is initialized, but there exist some other paths for which the object is not
initialized, the compiler emits a warning if it cannot prove the uninitialized
paths are not executed at run time."

This is only roughly what happens but there are many instances of
-Wuninitialized that could be described using the same sentence, even though it
doesn't consider PHI nodes.  If we do introduce a similar distinction in other
warnings like -Wstringop-overflow it will be on top of the instances already
issued by them, not a subset of them.

This is a general property of all flow based warnings in GCC except those
emitted by the static analyzer which doesn't depend on the same optimizations
(only a very small subset of them).  All warnings (flow based or otherwise,
including those issued by the analyzer) should always be viewed as documented,
i.e., as "messages that report constructions that are not inherently erroneous
but that are risky or suggest there may have been an error."

  parent reply	other threads:[~2021-06-22 15:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-19  9:52 [Bug middle-end/101134] New: " dangelog at gmail dot com
2021-06-21 16:10 ` [Bug middle-end/101134] " msebor at gcc dot gnu.org
2021-06-21 16:44 ` dangelog at gmail dot com
2021-06-21 20:40 ` msebor at gcc dot gnu.org
2021-06-22  8:57 ` dangelog at gmail dot com
2021-06-22 15:27 ` msebor at gcc dot gnu.org [this message]
2021-06-22 16:34 ` dangelog at gmail dot com
2021-06-23 19:56 ` msebor at gcc dot gnu.org
2021-06-24 14:07 ` dangelog at gmail dot com
2021-06-24 17:05 ` segher at gcc dot gnu.org
2021-06-24 17:57 ` rsandifo at gcc dot gnu.org
2021-06-24 19:36 ` dmalcolm at gcc dot gnu.org
2021-06-24 21:18 ` msebor at gcc dot gnu.org
2021-06-24 22:18 ` dangelog at gmail dot com
2022-03-17 10:18 ` redi 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-101134-4-Rmlc7JnNzh@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).