From: Yury Norov <yury.norov@gmail.com>
To: Ian Rogers <irogers@google.com>
Cc: "Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
"Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Namhyung Kim" <namhyung@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Jiri Olsa" <jolsa@kernel.org>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Kan Liang" <kan.liang@linux.intel.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Darren Hart" <dvhart@infradead.org>,
"Davidlohr Bueso" <dave@stgolabs.net>,
"André Almeida" <andrealmeid@igalia.com>,
"John Garry" <john.g.garry@oracle.com>,
"Will Deacon" <will@kernel.org>,
"James Clark" <james.clark@linaro.org>,
"Mike Leach" <mike.leach@linaro.org>,
"Leo Yan" <leo.yan@linux.dev>,
"Yicong Yang" <yangyicong@hisilicon.com>,
"Jonathan Cameron" <jonathan.cameron@huawei.com>,
"Nathan Chancellor" <nathan@kernel.org>,
"Bill Wendling" <morbo@google.com>,
"Justin Stitt" <justinstitt@google.com>,
"Josh Poimboeuf" <jpoimboe@kernel.org>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Kyle Meyer" <kyle.meyer@hpe.com>,
"Ben Gainey" <ben.gainey@arm.com>,
"Athira Rajeev" <atrajeev@linux.vnet.ibm.com>,
"Kajol Jain" <kjain@linux.ibm.com>,
"Aditya Gupta" <adityag@linux.ibm.com>,
"Eder Zulian" <ezulian@redhat.com>,
"Dapeng Mi" <dapeng1.mi@linux.intel.com>,
"Kuan-Wei Chiu" <visitorckw@gmail.com>,
"He Zhe" <zhe.he@windriver.com>,
"Dirk Gouders" <dirk@gouders.net>,
"Brian Geffon" <bgeffon@google.com>,
"Ravi Bangoria" <ravi.bangoria@amd.com>,
"Howard Chu" <howardchu95@gmail.com>,
"Charlie Jenkins" <charlie@rivosinc.com>,
"Colin Ian King" <colin.i.king@gmail.com>,
"Dominique Martinet" <asmadeus@codewreck.org>,
"Jann Horn" <jannh@google.com>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Yang Jihong" <yangjihong@bytedance.com>,
"Dmitry Vyukov" <dvyukov@google.com>,
"Andi Kleen" <ak@linux.intel.com>,
"Graham Woodward" <graham.woodward@arm.com>,
"Ilkka Koskinen" <ilkka@os.amperecomputing.com>,
"Anshuman Khandual" <anshuman.khandual@arm.com>,
"Zhongqiu Han" <quic_zhonhan@quicinc.com>,
"Hao Ge" <gehao@kylinos.cn>,
"Tengda Wu" <wutengda@huaweicloud.com>,
"Gabriele Monaco" <gmonaco@redhat.com>,
"Chun-Tse Shao" <ctshao@google.com>,
"Casey Chen" <cachen@purestorage.com>,
"Dr. David Alan Gilbert" <linux@treblig.org>,
"Li Huafei" <lihuafei1@huawei.com>,
"Steinar H. Gunderson" <sesse@google.com>,
"Levi Yun" <yeoreum.yun@arm.com>,
"Weilin Wang" <weilin.wang@intel.com>,
"Thomas Falcon" <thomas.falcon@intel.com>,
"Thomas Richter" <tmricht@linux.ibm.com>,
"Andrew Kreimer" <algonell@gmail.com>,
"Krzysztof Łopatowski" <krzysztof.m.lopatowski@gmail.com>,
"Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Jean-Philippe Romain" <jean-philippe.romain@foss.st.com>,
"Junhao He" <hejunhao3@huawei.com>,
"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
"Xu Yang" <xu.yang_2@nxp.com>,
"Steve Clevenger" <scclevenger@os.amperecomputing.com>,
"Zixian Cai" <fzczx123@gmail.com>,
"Stephen Brennan" <stephen.s.brennan@oracle.com>,
"Yujie Liu" <yujie.liu@intel.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev
Subject: Re: [PATCH v1 02/48] tools headers: Silence -Wshorten-64-to-32 warnings
Date: Thu, 3 Apr 2025 10:08:35 -0400 [thread overview]
Message-ID: <Z-6WY4a6RV1bEbNU@thinkpad> (raw)
In-Reply-To: <20250401182347.3422199-3-irogers@google.com>
On Tue, Apr 01, 2025 at 11:23:00AM -0700, Ian Rogers wrote:
> The clang warning -Wshorten-64-to-32 can be useful to catch
> inadvertent truncation. In some instances this truncation can lead to
> changing the sign of a result, for example, truncation to return an
> int to fit a sort routine. Silence the warning by making the implicit
> truncation explicit.
>
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/include/asm-generic/bitops/fls64.h | 2 +-
> tools/include/linux/bitfield.h | 2 +-
> tools/include/linux/bitmap.h | 2 +-
> tools/include/linux/err.h | 2 +-
> tools/include/linux/hash.h | 2 +-
> tools/include/linux/math64.h | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tools/include/asm-generic/bitops/fls64.h b/tools/include/asm-generic/bitops/fls64.h
> index 866f2b2304ff..9ad3ff12f454 100644
> --- a/tools/include/asm-generic/bitops/fls64.h
> +++ b/tools/include/asm-generic/bitops/fls64.h
> @@ -21,7 +21,7 @@ static __always_inline int fls64(__u64 x)
> __u32 h = x >> 32;
> if (h)
> return fls(h) + 32;
> - return fls(x);
> + return fls((__u32)x);
Can you keep kernel and tools sources synchronized?
> }
> #elif BITS_PER_LONG == 64
> static __always_inline int fls64(__u64 x)
> diff --git a/tools/include/linux/bitfield.h b/tools/include/linux/bitfield.h
> index 6093fa6db260..aa0b8e52214f 100644
> --- a/tools/include/linux/bitfield.h
> +++ b/tools/include/linux/bitfield.h
> @@ -146,7 +146,7 @@ static __always_inline __##type type##_encode_bits(base v, base field) \
> { \
> if (__builtin_constant_p(v) && (v & ~field_mask(field))) \
> __field_overflow(); \
> - return to((v & field_mask(field)) * field_multiplier(field)); \
> + return to((__##type)((v & field_mask(field)) * field_multiplier(field))); \
> } \
> static __always_inline __##type type##_replace_bits(__##type old, \
> base val, base field) \
> diff --git a/tools/include/linux/bitmap.h b/tools/include/linux/bitmap.h
> index 2a7f260ef9dc..b7a7c752e4f2 100644
> --- a/tools/include/linux/bitmap.h
> +++ b/tools/include/linux/bitmap.h
> @@ -63,7 +63,7 @@ static inline bool bitmap_full(const unsigned long *src, unsigned int nbits)
> return find_first_zero_bit(src, nbits) == nbits;
> }
>
> -static inline unsigned int bitmap_weight(const unsigned long *src, unsigned int nbits)
> +static inline unsigned long bitmap_weight(const unsigned long *src, unsigned int nbits)
> {
> if (small_const_nbits(nbits))
> return hweight_long(*src & BITMAP_LAST_WORD_MASK(nbits));
Oh no... bitmap_weight() is used in printk(), and you'll get tons of
warnings because, say %x should be replaced with %lx.
> diff --git a/tools/include/linux/err.h b/tools/include/linux/err.h
> index 332b983ead1e..9c1746e3696d 100644
> --- a/tools/include/linux/err.h
> +++ b/tools/include/linux/err.h
I don't maintain the this and the following subsystems. Can you make
it a separate patch?
> @@ -55,7 +55,7 @@ static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
> static inline int __must_check PTR_ERR_OR_ZERO(__force const void *ptr)
> {
> if (IS_ERR(ptr))
> - return PTR_ERR(ptr);
> + return (int)PTR_ERR(ptr);
> else
> return 0;
> }
> diff --git a/tools/include/linux/hash.h b/tools/include/linux/hash.h
> index 38edaa08f862..ecc8296cb397 100644
> --- a/tools/include/linux/hash.h
> +++ b/tools/include/linux/hash.h
> @@ -75,7 +75,7 @@ static __always_inline u32 hash_64_generic(u64 val, unsigned int bits)
> {
> #if BITS_PER_LONG == 64
> /* 64x64-bit multiply is efficient on all 64-bit processors */
> - return val * GOLDEN_RATIO_64 >> (64 - bits);
> + return (u32)(val * GOLDEN_RATIO_64 >> (64 - bits));
> #else
> /* Hash 64 bits using only 32x32-bit multiply. */
> return hash_32((u32)val ^ __hash_32(val >> 32), bits);
> diff --git a/tools/include/linux/math64.h b/tools/include/linux/math64.h
> index 4ad45d5943dc..03d6c5220957 100644
> --- a/tools/include/linux/math64.h
> +++ b/tools/include/linux/math64.h
> @@ -48,7 +48,7 @@ static inline u64 mul_u64_u32_shr(u64 a, u32 b, unsigned int shift)
> u32 ah, al;
> u64 ret;
>
> - al = a;
> + al = (u32)a;
> ah = a >> 32;
>
> ret = mul_u32_u32(al, b) >> shift;
> --
> 2.49.0.504.g3bcea36a83-goog
next prev parent reply other threads:[~2025-04-03 14:08 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-01 18:22 [PATCH v1 00/48] Perf build support for -Wshorten-64-to-32 Ian Rogers
2025-04-01 18:22 ` [PATCH v1 01/48] perf build: Avoid building libbpf/bpftool with LIBBPF_DYNAMIC Ian Rogers
2025-04-01 18:23 ` [PATCH v1 02/48] tools headers: Silence -Wshorten-64-to-32 warnings Ian Rogers
2025-04-03 14:08 ` Yury Norov [this message]
2025-04-03 14:26 ` Yury Norov
2025-04-03 14:52 ` Ian Rogers
2025-04-03 15:23 ` Yury Norov
2025-04-03 15:45 ` Ian Rogers
2025-04-03 18:12 ` Ian Rogers
2025-04-03 18:18 ` Yury Norov
2025-04-03 18:25 ` Ian Rogers
2025-04-01 18:23 ` [PATCH v1 03/48] arm64: cputype: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 04/48] x86/insn: " Ian Rogers
2025-04-02 11:10 ` Eder Zulian
2025-04-01 18:23 ` [PATCH v1 05/48] tools lib: " Ian Rogers
2025-04-03 14:19 ` Yury Norov
2025-04-01 18:23 ` [PATCH v1 06/48] libperf: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 07/48] tools subcmd: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 08/48] perf bench: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 09/48] perf tests: " Ian Rogers
2025-04-02 14:35 ` Leo Yan
2025-04-02 15:42 ` Ian Rogers
2025-04-02 16:38 ` Leo Yan
2025-04-02 16:53 ` Ian Rogers
2025-04-03 4:53 ` Namhyung Kim
2025-04-03 15:20 ` Ian Rogers
2025-04-28 11:10 ` Leo Yan
2025-04-28 16:29 ` Ian Rogers
2025-04-29 9:53 ` Leo Yan
2025-04-02 22:01 ` David Laight
2025-04-02 22:32 ` Ian Rogers
2025-04-01 18:23 ` [PATCH v1 10/48] perf arch x86: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 11/48] perf arm-spe: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 12/48] perf trace: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 13/48] perf trace-event: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 14/48] perf jvmti: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 15/48] perf pmu: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 16/48] perf annotate powerpc: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 17/48] perf s390: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 18/48] perf cs-etm: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 19/48] perf stat: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 20/48] perf dlfilter: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 21/48] perf demangle: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 22/48] perf ui: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 23/48] perf annotate: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 24/48] perf report: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 25/48] perf help: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 26/48] perf hisi-ptt: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 27/48] perf probe: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 28/48] perf kwork: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 29/48] perf buildid: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 30/48] perf lock: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 31/48] perf mem: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 32/48] perf script: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 33/48] perf evlist: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 34/48] perf bpf_counter: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 35/48] perf ftrace: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 36/48] perf record: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 37/48] perf inject: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 38/48] perf sched: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 39/48] perf timechart: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 40/48] perf list: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 41/48] perf kvm: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 42/48] perf diff: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 43/48] perf daemon: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 44/48] perf zlib: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 45/48] perf symbol: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 46/48] perf util: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 47/48] perf hashmap: " Ian Rogers
2025-04-01 18:23 ` [PATCH v1 48/48] perf: " Ian Rogers
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=Z-6WY4a6RV1bEbNU@thinkpad \
--to=yury.norov@gmail.com \
--cc=acme@kernel.org \
--cc=adityag@linux.ibm.com \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=algonell@gmail.com \
--cc=andrealmeid@igalia.com \
--cc=anshuman.khandual@arm.com \
--cc=arnd@arndb.de \
--cc=asmadeus@codewreck.org \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=ben.gainey@arm.com \
--cc=bgeffon@google.com \
--cc=cachen@purestorage.com \
--cc=charlie@rivosinc.com \
--cc=christophe.leroy@csgroup.eu \
--cc=colin.i.king@gmail.com \
--cc=ctshao@google.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=dirk@gouders.net \
--cc=dvhart@infradead.org \
--cc=dvyukov@google.com \
--cc=ezulian@redhat.com \
--cc=fzczx123@gmail.com \
--cc=gehao@kylinos.cn \
--cc=gmonaco@redhat.com \
--cc=graham.woodward@arm.com \
--cc=hejunhao3@huawei.com \
--cc=howardchu95@gmail.com \
--cc=ilkka@os.amperecomputing.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jannh@google.com \
--cc=jean-philippe.romain@foss.st.com \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=jonathan.cameron@huawei.com \
--cc=jpoimboe@kernel.org \
--cc=justinstitt@google.com \
--cc=kan.liang@linux.intel.com \
--cc=kjain@linux.ibm.com \
--cc=krzysztof.m.lopatowski@gmail.com \
--cc=kyle.meyer@hpe.com \
--cc=leo.yan@linux.dev \
--cc=lihuafei1@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=linux@treblig.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=namhyung@kernel.org \
--cc=nathan@kernel.org \
--cc=peterz@infradead.org \
--cc=quic_zhonhan@quicinc.com \
--cc=ravi.bangoria@amd.com \
--cc=scclevenger@os.amperecomputing.com \
--cc=sesse@google.com \
--cc=stephen.s.brennan@oracle.com \
--cc=tglx@linutronix.de \
--cc=thomas.falcon@intel.com \
--cc=tmricht@linux.ibm.com \
--cc=viro@zeniv.linux.org.uk \
--cc=visitorckw@gmail.com \
--cc=weilin.wang@intel.com \
--cc=will@kernel.org \
--cc=wutengda@huaweicloud.com \
--cc=xu.yang_2@nxp.com \
--cc=yangjihong@bytedance.com \
--cc=yangyicong@hisilicon.com \
--cc=yeoreum.yun@arm.com \
--cc=yujie.liu@intel.com \
--cc=zhe.he@windriver.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.