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

            Bug ID: 124159
           Summary: Add -Wbogus warning class
           Product: gcc
           Version: 16.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: diagnostics
          Assignee: dmalcolm at redhat dot com
          Reporter: boris at kolpackov dot net
  Target Milestone: ---

For the past couple of releases (14, 15, and now 16) I've had the frustrating
experience of testing a GCC pre-release and trying to work around new false
positive warnings in order to keep out codebase warning-free with -Wall. This
usually requires uglyfying our source code and often I give up and disable the
offending warning for the entire project, never to be enabled again.

To give a specific example, consider SQLite:

GCC 15 introduced a bogus -Wstringop-overread, filed as bug #115274 (while it
is claimed to be fixed in 16, I don't believe it is, and the warning is still
there when tested on the latest sqlite3.c source code; see my latest comment
there for details).

In GCC 16 we additionally have two more bogus warnings: -Wdangling-pointer
(#124141) and -Wstringop-overflow (#124109).

So we have the classic problem of a warning that (falsely) cried wolf one too
many times and gets silenced, most likely forever. (Who has the time to go
through their disabled warnings list to see if any of them can be enabled back?
Not me!)

Which brings me to my proposal: add the -Wbogus warning class that, for each
release of GCC, contains warnings that have known false positive issues (as
indicated by bugs of this nature filed against them). This way, folks who do
not wish to take chances with such warnings, can build their projects with
-Wall -Wno-bogus. The key advantage of this approach (compared to same folks
disabling individual warnings) is that a warning that no longer has any known
bogosity issues can be removed from this class for the next release of GCC and
automatically re-enabled in various codebases. In fact, a sufficiently
undercooked warning may end up in a situation where it gets habitually disabled
and thus never gets sufficient exposure to shake out the bugs.

If this is of interest, I would be willing to work on a patch.

Reply via email to