From: David Laight <david.laight.linux@gmail.com>
To: Leo Yan <leo.yan@arm.com>
Cc: "Ian Rogers" <irogers@google.com>,
"Yury Norov" <yury.norov@gmail.com>,
"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 09/48] perf tests: Silence -Wshorten-64-to-32 warnings
Date: Wed, 2 Apr 2025 23:01:25 +0100 [thread overview]
Message-ID: <20250402230125.366ac21c@pumpkin> (raw)
In-Reply-To: <20250402163807.GP115840@e132581.arm.com>
On Wed, 2 Apr 2025 17:38:07 +0100
Leo Yan <leo.yan@arm.com> wrote:
> Hi Ian,
...
> If we use casts just to silence warnings, we also lose the opportunity
> to improve code quality. The changes in this series that fix type
> mismatches are good, but I think the use of casts is not particularly
> helpful - we're simply switching from implicit compiler casts to
> explicit ones.
It is certainly my experience (a lot of years) that casts between
integers of different sizes just make code harder to read and possibly
even more buggy.
If the compiler really knew the valid range of the value (rather than
just the type) then perhaps a warning that significant bits were being
discarded might be more reasonable.
But even then you don't want anything for code like:
hi_32 = val_64 >> 32;
lo_32 = val_64;
David
next prev parent reply other threads:[~2025-04-02 22:01 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
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 [this message]
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=20250402230125.366ac21c@pumpkin \
--to=david.laight.linux@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@arm.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=yury.norov@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).