clang_nowarn_gdb_generic_failures

Clang: Suppress warnings if built with Clang (gdb)

• Status: Merged for Binutils 2.40 and GDB 13
  (GDB part has slightly changed by Simon Marchi)
• Branch: clang-nowarn-gdb-generic-failures
• Tracking PR: #54 (view Pull Request and Diff)
• Mailing List:
  • PATCH v1 (2022-09-15) - gdb-patches | binutils
  • PATCH v2 (2022-09-22) - gdb-patches | binutils
  • PATCH v3 (2022-10-18)

Based On

• Clang: Suppress warnings if built with Clang (sim and gdb, big batch 1)
  This patch was a subset of clang-nowarn-1 (in development).

Issue Solved

This patchset deals with two kinds of warnings but with similar methods.

gdb/unittests: PR28413, suppress custom warnings by Gnulib (v2: PATCH 1/2, v3: PATCH)

Gnulib generates a warning (-Wuser-defined-warnings on Clang) if the system version of certain functions are used (to redirect the developer to use Gnulib version). However, this behavior is found harmful to gdb/unittests/string_view-selftests.c, making the build failure.

This issue occurs if:

• Compiled with Clang
• -Werror is specified (by default)
• C++ standard used by Clang is before C++17 (by default as of 15.0.0) when this unit test is activated.

This error is identified as PR28413.

Warnings about "free" may be resolved by modifying libiberty part but one of the warnings generated by Gnulib points at the C++ standard library.

So, directly fixing the location which generates the warning is partially impossible.

In the past, there were a proposal to fix this issue from the Gnulib side but rejected because it ruins the intent of Gnulib warnings. So, a fix from the Binutils / GDB side is desired.

This patch is changed to surround all #include block because PATCH v2 caused an error on Clang + macOS.

Withdrawn: gdb: Suppress "unused" variable warning on Clang in Bison-generated code (v2: PATCH 2/2)

Clang generates a warning on "written but not read thereafter" varibles (-Wset-but-unused-variable), making the build failure.

The unique problem here is, the cause is the variable yynerrs in $(builddir)/gdb/cp-name-parser.c, generated by $(srcdir)/gdb/cp-name-parser.y. So, directly fixing the location which causes the warning is nonfeasible.

This is superseded by Simon Marchi's better fine-grained patch.

Resolving the Issues

In either cases, we can resolve the problem if we use include/diagnostics.h. This header file defines a set of macros to suppress certain warnings only when necessary.

In this patchset (PATCH v2), it added two ignore warning macros (this part is merged already).