[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240319-tracing-fully-silence-wstring-compare-v1-0-81adb44403f5@kernel.org>
Date: Tue, 19 Mar 2024 09:07:51 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: rostedt@...dmis.org, mhiramat@...nel.org
Cc: mathieu.desnoyers@...icios.com, ndesaulniers@...gle.com,
morbo@...gle.com, justinstitt@...gle.com, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, llvm@...ts.linux.dev,
patches@...ts.linux.dev, Nathan Chancellor <nathan@...nel.org>,
Linux Kernel Functional Testing <lkft@...aro.org>
Subject: [PATCH 0/2] tracing: Fully silence instance of -Wstring-compare
Hi all,
This series fully resolves the new instance of -Wstring-compare from
within the __assign_str() macro. The first patch resolves a build
failure with GCC that would be seen with just the second patch applied.
The second patch actually hides the warning.
NOTE: This is based on trace/for-next, which does not contain the
minimum LLVM version bump that occurred later in the current merge
window, so this uses
__diag_ignore(clang, 11, ...
instead of
__diag_ignore(clang, 13, ...
which will be required when this is merged into Linus's tree. If you can
base this series on a tree that has the merge commit e5eb28f6d1af ("Merge
tag 'mm-nonmm-stable-2024-03-14-09-36' of
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm") in it, then that
change can be done at application time, rather than merge time (or I can
send a v2). It would be really nice for this to make the merge window so
that this warning does not proliferate into other trees that base on
-rc1.
---
Nathan Chancellor (2):
compiler_types: Ensure __diag_clang() is always available
tracing: Ignore -Wstring-compare with diagnostic macros
include/linux/compiler_types.h | 4 ++++
include/trace/stages/stage6_event_callback.h | 5 +++++
2 files changed, 9 insertions(+)
---
base-commit: 7604256cecef34a82333d9f78262d3180f4eb525
change-id: 20240319-tracing-fully-silence-wstring-compare-e71e2fd17b2a
Best regards,
--
Nathan Chancellor <nathan@...nel.org>
Powered by blists - more mailing lists