| Message ID | 20240503095027.747838-1-visitorckw@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | maple_tree: Fix build failure with W=1 and LLVM=1 | expand |
On Fri, May 03, 2024 at 05:50:27PM +0800, Kuan-Wei Chiu wrote: > When compiling library code using "make W=1 LLVM=1 lib/", clang > generated the following compilation errors: > > lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function] > static inline void *mte_set_full(const struct maple_enode *node) Uh, clang is wrong to flag these as an error. They're just not used yet.
On Fri, May 03, 2024 at 01:20:32PM +0100, Matthew Wilcox wrote: > On Fri, May 03, 2024 at 05:50:27PM +0800, Kuan-Wei Chiu wrote: > > When compiling library code using "make W=1 LLVM=1 lib/", clang > > generated the following compilation errors: > > > > lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function] > > static inline void *mte_set_full(const struct maple_enode *node) > > Uh, clang is wrong to flag these as an error. They're just not used > yet. I think it's because the kernel defaults to treating all compilation warnings as errors. If you turn off the option to treat compilation warnings as errors, they will be treated as warnings instead. Should I update my commit message to change compilation errors to compilation warnings? Regards, Kuan-Wei
On Fri, May 03, 2024 at 09:01:06PM +0800, Kuan-Wei Chiu wrote: > On Fri, May 03, 2024 at 01:20:32PM +0100, Matthew Wilcox wrote: > > On Fri, May 03, 2024 at 05:50:27PM +0800, Kuan-Wei Chiu wrote: > > > When compiling library code using "make W=1 LLVM=1 lib/", clang > > > generated the following compilation errors: > > > > > > lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function] > > > static inline void *mte_set_full(const struct maple_enode *node) > > > > Uh, clang is wrong to flag these as an error. They're just not used > > yet. > > I think it's because the kernel defaults to treating all compilation > warnings as errors. If you turn off the option to treat compilation > warnings as errors, they will be treated as warnings instead. Should I > update my commit message to change compilation errors to compilation > warnings? just don't use W=1 and clang.
On Fri, May 03, 2024 at 02:29:12PM +0100, Matthew Wilcox wrote: > On Fri, May 03, 2024 at 09:01:06PM +0800, Kuan-Wei Chiu wrote: > > On Fri, May 03, 2024 at 01:20:32PM +0100, Matthew Wilcox wrote: > > > On Fri, May 03, 2024 at 05:50:27PM +0800, Kuan-Wei Chiu wrote: > > > > When compiling library code using "make W=1 LLVM=1 lib/", clang > > > > generated the following compilation errors: > > > > > > > > lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function] > > > > static inline void *mte_set_full(const struct maple_enode *node) > > > > > > Uh, clang is wrong to flag these as an error. They're just not used > > > yet. > > > > I think it's because the kernel defaults to treating all compilation > > warnings as errors. If you turn off the option to treat compilation > > warnings as errors, they will be treated as warnings instead. Should I > > update my commit message to change compilation errors to compilation > > warnings? > > just don't use W=1 and clang. This patch has effectively been sent four times now: https://lore.kernel.org/all/20220914101829.82000-1-jiapeng.chong@linux.alibaba.com/ https://lore.kernel.org/all/20230217084647.50471-1-jiapeng.chong@linux.alibaba.com/ https://lore.kernel.org/all/20230319132903.1702426-1-trix@redhat.com/ https://lore.kernel.org/all/20240503095027.747838-1-visitorckw@gmail.com/ (this change obviously) Your first comment from the 2022 patch: They're not used now, but they will be in a release or two. I think a few releases have passed since then :) I don't personally care if there is a solution here or not, as I don't test with W=1 (there's enough to do at W=0 :P), but maybe it is time for either __maybe_unused (as that strikes at the heart of the issue) or at the very least a comment saying "hey, these functions are currently unused but there are plans for them to be used, so don't remove them", rather than just saying the status quo? Cheers, Nathan
On Fri, 3 May 2024 09:08:21 -0700 Nathan Chancellor <nathan@kernel.org> wrote: > This patch has effectively been sent four times now: > > https://lore.kernel.org/all/20220914101829.82000-1-jiapeng.chong@linux.alibaba.com/ > https://lore.kernel.org/all/20230217084647.50471-1-jiapeng.chong@linux.alibaba.com/ > https://lore.kernel.org/all/20230319132903.1702426-1-trix@redhat.com/ > https://lore.kernel.org/all/20240503095027.747838-1-visitorckw@gmail.com/ (this change obviously) > > Your first comment from the 2022 patch: > > They're not used now, but they will be in a release or two. > > I think a few releases have passed since then :) I don't personally care > if there is a solution here or not, as I don't test with W=1 (there's > enough to do at W=0 :P), but maybe it is time for either __maybe_unused > (as that strikes at the heart of the issue) or at the very least a > comment saying "hey, these functions are currently unused but there are > plans for them to be used, so don't remove them", rather than just > saying the status quo? We could just slap a #if 0 around them. But I don't think it'll kill us to have to type them in again one day ;)
* Andrew Morton <akpm@linux-foundation.org> [240504 19:03]: > On Fri, 3 May 2024 09:08:21 -0700 Nathan Chancellor <nathan@kernel.org> wrote: > > > This patch has effectively been sent four times now: > > > > https://lore.kernel.org/all/20220914101829.82000-1-jiapeng.chong@linux.alibaba.com/ > > https://lore.kernel.org/all/20230217084647.50471-1-jiapeng.chong@linux.alibaba.com/ > > https://lore.kernel.org/all/20230319132903.1702426-1-trix@redhat.com/ > > https://lore.kernel.org/all/20240503095027.747838-1-visitorckw@gmail.com/ (this change obviously) > > > > Your first comment from the 2022 patch: > > > > They're not used now, but they will be in a release or two. > > > > I think a few releases have passed since then :) I don't personally care > > if there is a solution here or not, as I don't test with W=1 (there's > > enough to do at W=0 :P), but maybe it is time for either __maybe_unused > > (as that strikes at the heart of the issue) or at the very least a > > comment saying "hey, these functions are currently unused but there are > > plans for them to be used, so don't remove them", rather than just > > saying the status quo? > > We could just slap a #if 0 around them. But I don't think it'll kill us to > have to type them in again one day ;) I've had people try to use this bit for other reasons, even with these functions. If we're dropping this code, then we should put something in to avoid it disappearing on us. I am working on the use of these functions in a branch, but I don't have a timeline of when that feature will land. Thanks, Liam
diff --git a/lib/maple_tree.c b/lib/maple_tree.c index 55e1b35bf877..cd3f5399f9f3 100644 --- a/lib/maple_tree.c +++ b/lib/maple_tree.c @@ -348,21 +348,6 @@ static inline void *mte_safe_root(const struct maple_enode *node) return (void *)((unsigned long)node & ~MAPLE_ROOT_NODE); } -static inline void *mte_set_full(const struct maple_enode *node) -{ - return (void *)((unsigned long)node & ~MAPLE_ENODE_NULL); -} - -static inline void *mte_clear_full(const struct maple_enode *node) -{ - return (void *)((unsigned long)node | MAPLE_ENODE_NULL); -} - -static inline bool mte_has_null(const struct maple_enode *node) -{ - return (unsigned long)node & MAPLE_ENODE_NULL; -} - static __always_inline bool ma_is_root(struct maple_node *node) { return ((unsigned long)node->parent & MA_ROOT_PARENT);
When compiling library code using "make W=1 LLVM=1 lib/", clang generated the following compilation errors: lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function] static inline void *mte_set_full(const struct maple_enode *node) ^ lib/maple_tree.c:356:21: error: unused function 'mte_clear_full' [-Werror,-Wunused-function] static inline void *mte_clear_full(const struct maple_enode *node) ^ lib/maple_tree.c:361:20: error: unused function 'mte_has_null' [-Werror,-Wunused-function] static inline bool mte_has_null(const struct maple_enode *node) ^ 3 errors generated. Remove unused static inline functions to resolve compilation errors with clang. Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> --- lib/maple_tree.c | 15 --------------- 1 file changed, 15 deletions(-)