This reverts commit 55a18d2f3ff7 ("perf build: enable
-fno-strict-aliasing"). With (get|put)_unaligned_* using memcpy
-fno-strict-aliasing is no longer necessary as memcpys are assumed to
possibly alias.

Signed-off-by: Ian Rogers <irogers@google.com>
---
 tools/perf/Makefile.config | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index a8dc72cfe48e..1d3dcefd8c95 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -19,10 +19,6 @@ detected_var = $(shell echo "$(1)=$($(1))" >> $(OUTPUT).config-detected)
 CFLAGS := $(EXTRA_CFLAGS) $(filter-out -Wnested-externs,$(EXTRA_WARNINGS))
 HOSTCFLAGS := $(filter-out -Wnested-externs,$(EXTRA_WARNINGS))
 
-# This is required because the kernel is built with this and some of the code
-# borrowed from kernel headers depends on it, e.g. put_unaligned_*().
-CFLAGS += -fno-strict-aliasing
-
 # Set target flag and options when using clang as compiler.
 ifeq ($(CC_NO_CLANG), 0)
   CLANG_TARGET_FLAGS_arm	:= arm-linux-gnueabi
-- 
2.53.0.959.g497ff81fa9-goog

On Fri, Mar 20, 2026 at 3:42 PM Ian Rogers <irogers@google.com> wrote:
>
> This reverts commit 55a18d2f3ff7 ("perf build: enable
> -fno-strict-aliasing"). With (get|put)_unaligned_* using memcpy
> -fno-strict-aliasing is no longer necessary as memcpys are assumed to
> possibly alias.

Sashiko noted strict aliasing violations in hashmap, so I sent out a fix [1]:

The commit message notes that put_unaligned_*() no longer requires this
flag, but does this change safely account for the hashmap API's type punning?

The hashmap API heavily uses type punning via hashmap_cast_ptr(), casting
pointer-to-pointer arguments (e.g., struct syscall_stats **stats or
struct hashmap_entry **entry) into long * for functions like hashmap_find().

Inside hashmap_find(), the pointer is written via *value = entry->value;
where value is of type long *. Under C strict aliasing rules, a long and a
pointer type are incompatible. When -fstrict-aliasing is active (the default
at -O2 or -O3), the compiler is allowed to assume that the write through
long * does not modify the caller's pointer variable.

If perf is compiled with Link-Time Optimization (LTO), the compiler can
analyze the cross-module call and conclude that hashmap_find() cannot
modify the caller's pointer variable.

Could this cause the compiler to optimize out the assignment, leading to
silent NULL pointer dereferences or the use of uninitialized memory?

[1] https://lore.kernel.org/lkml/20260321024446.692008-1-irogers@google.com/T/#t

Thanks,
Ian

> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
>  tools/perf/Makefile.config | 4 ----
>  1 file changed, 4 deletions(-)
>
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index a8dc72cfe48e..1d3dcefd8c95 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -19,10 +19,6 @@ detected_var = $(shell echo "$(1)=$($(1))" >> $(OUTPUT).config-detected)
>  CFLAGS := $(EXTRA_CFLAGS) $(filter-out -Wnested-externs,$(EXTRA_WARNINGS))
>  HOSTCFLAGS := $(filter-out -Wnested-externs,$(EXTRA_WARNINGS))
>
> -# This is required because the kernel is built with this and some of the code
> -# borrowed from kernel headers depends on it, e.g. put_unaligned_*().
> -CFLAGS += -fno-strict-aliasing
> -
>  # Set target flag and options when using clang as compiler.
>  ifeq ($(CC_NO_CLANG), 0)
>    CLANG_TARGET_FLAGS_arm       := arm-linux-gnueabi
> --
> 2.53.0.959.g497ff81fa9-goog
>