[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250401182347.3422199-48-irogers@google.com>
Date: Tue, 1 Apr 2025 11:23:45 -0700
From: Ian Rogers <irogers@...gle.com>
To: Yury Norov <yury.norov@...il.com>, Rasmus Villemoes <linux@...musvillemoes.dk>,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>,
Kan Liang <kan.liang@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>,
Darren Hart <dvhart@...radead.org>, Davidlohr Bueso <dave@...olabs.net>,
"André Almeida" <andrealmeid@...lia.com>, John Garry <john.g.garry@...cle.com>,
Will Deacon <will@...nel.org>, James Clark <james.clark@...aro.org>,
Mike Leach <mike.leach@...aro.org>, Leo Yan <leo.yan@...ux.dev>,
Yicong Yang <yangyicong@...ilicon.com>, Jonathan Cameron <jonathan.cameron@...wei.com>,
Nathan Chancellor <nathan@...nel.org>, Bill Wendling <morbo@...gle.com>,
Justin Stitt <justinstitt@...gle.com>, Josh Poimboeuf <jpoimboe@...nel.org>,
Al Viro <viro@...iv.linux.org.uk>, Kyle Meyer <kyle.meyer@....com>,
Ben Gainey <ben.gainey@....com>, Athira Rajeev <atrajeev@...ux.vnet.ibm.com>,
Kajol Jain <kjain@...ux.ibm.com>, Aditya Gupta <adityag@...ux.ibm.com>,
Eder Zulian <ezulian@...hat.com>, Dapeng Mi <dapeng1.mi@...ux.intel.com>,
Kuan-Wei Chiu <visitorckw@...il.com>, He Zhe <zhe.he@...driver.com>,
Dirk Gouders <dirk@...ders.net>, Brian Geffon <bgeffon@...gle.com>,
Ravi Bangoria <ravi.bangoria@....com>, Howard Chu <howardchu95@...il.com>,
Charlie Jenkins <charlie@...osinc.com>, Colin Ian King <colin.i.king@...il.com>,
Dominique Martinet <asmadeus@...ewreck.org>, Jann Horn <jannh@...gle.com>,
Masahiro Yamada <masahiroy@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Yang Jihong <yangjihong@...edance.com>, Dmitry Vyukov <dvyukov@...gle.com>,
Andi Kleen <ak@...ux.intel.com>, Graham Woodward <graham.woodward@....com>,
Ilkka Koskinen <ilkka@...amperecomputing.com>,
Anshuman Khandual <anshuman.khandual@....com>, Zhongqiu Han <quic_zhonhan@...cinc.com>,
Hao Ge <gehao@...inos.cn>, Tengda Wu <wutengda@...weicloud.com>,
Gabriele Monaco <gmonaco@...hat.com>, Chun-Tse Shao <ctshao@...gle.com>,
Casey Chen <cachen@...estorage.com>, "Dr. David Alan Gilbert" <linux@...blig.org>,
Li Huafei <lihuafei1@...wei.com>, "Steinar H. Gunderson" <sesse@...gle.com>, Levi Yun <yeoreum.yun@....com>,
Weilin Wang <weilin.wang@...el.com>, Thomas Falcon <thomas.falcon@...el.com>,
Thomas Richter <tmricht@...ux.ibm.com>, Andrew Kreimer <algonell@...il.com>,
"Krzysztof Łopatowski" <krzysztof.m.lopatowski@...il.com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Jean-Philippe Romain <jean-philippe.romain@...s.st.com>, Junhao He <hejunhao3@...wei.com>,
"Masami Hiramatsu (Google)" <mhiramat@...nel.org>, Xu Yang <xu.yang_2@....com>,
Steve Clevenger <scclevenger@...amperecomputing.com>, Zixian Cai <fzczx123@...il.com>,
Stephen Brennan <stephen.s.brennan@...cle.com>, Yujie Liu <yujie.liu@...el.com>,
linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, llvm@...ts.linux.dev
Subject: [PATCH v1 47/48] perf hashmap: Silence -Wshorten-64-to-32 warnings
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@...gle.com>
---
tools/perf/util/hashmap.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/hashmap.c b/tools/perf/util/hashmap.c
index 140ee4055676..f2719f522b84 100644
--- a/tools/perf/util/hashmap.c
+++ b/tools/perf/util/hashmap.c
@@ -115,7 +115,7 @@ static int hashmap_grow(struct hashmap *map)
return -ENOMEM;
hashmap__for_each_entry_safe(map, cur, tmp, bkt) {
- h = hash_bits(map->hash_fn(cur->key, map->ctx), new_cap_bits);
+ h = hash_bits(map->hash_fn(cur->key, map->ctx), (int)new_cap_bits);
hashmap_add_entry(&new_buckets[h], cur);
}
@@ -164,7 +164,7 @@ int hashmap_insert(struct hashmap *map, long key, long value,
if (old_value)
*old_value = 0;
- h = hash_bits(map->hash_fn(key, map->ctx), map->cap_bits);
+ h = hash_bits(map->hash_fn(key, map->ctx), (int)map->cap_bits);
if (strategy != HASHMAP_APPEND &&
hashmap_find_entry(map, key, h, NULL, &entry)) {
if (old_key)
@@ -188,7 +188,7 @@ int hashmap_insert(struct hashmap *map, long key, long value,
err = hashmap_grow(map);
if (err)
return err;
- h = hash_bits(map->hash_fn(key, map->ctx), map->cap_bits);
+ h = hash_bits(map->hash_fn(key, map->ctx), (int)map->cap_bits);
}
entry = malloc(sizeof(struct hashmap_entry));
@@ -208,7 +208,7 @@ bool hashmap_find(const struct hashmap *map, long key, long *value)
struct hashmap_entry *entry;
size_t h;
- h = hash_bits(map->hash_fn(key, map->ctx), map->cap_bits);
+ h = hash_bits(map->hash_fn(key, map->ctx), (int)map->cap_bits);
if (!hashmap_find_entry(map, key, h, NULL, &entry))
return false;
@@ -223,7 +223,7 @@ bool hashmap_delete(struct hashmap *map, long key,
struct hashmap_entry **pprev, *entry;
size_t h;
- h = hash_bits(map->hash_fn(key, map->ctx), map->cap_bits);
+ h = hash_bits(map->hash_fn(key, map->ctx), (int)map->cap_bits);
if (!hashmap_find_entry(map, key, h, &pprev, &entry))
return false;
--
2.49.0.504.g3bcea36a83-goog
Powered by blists - more mailing lists