Re: [PATCH v1] perf build: Revert "enable -fno-strict-aliasing"

[Peter Zijlstra]

On Thu, Sep 04, 2025 at 02:33:24PM -0700, Ian Rogers wrote:
> On Thu, Sep 4, 2025 at 1:59 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > On Thu, Sep 04, 2025 at 10:41:17PM +0200, Peter Zijlstra wrote:
> > > On Thu, Sep 04, 2025 at 10:44:30AM -0700, Ian Rogers 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.
> > >
> > > I don't think this is a good idea. Much of tools/ includes kernel
> > > headers and various kernel code, all of which is written in the
> > > understanding that this (often called broken) C language feature does
> > > not exist.
> > >
> > > As such, I would strongly suggest all of tools is built with
> > > -fno-strict-aliasing.
> >
> > Similarly I would strongly suggest having -fwrapv on all code that
> > includes kernel headers.
> 
> Given we can build and run with sanitizers, ubsan covers fwrapv and
> type sanitizer is in development to detect strict aliasing violations.
> So we can have correct code without hamstringing the compiler.
> 
> There's lots wrong with C, a particular favorite of mine is:
> ```
> void foo(const int *p) {
>    int x = *p;
>    if (x == 10) {
>       mutex_lock(&global_mutex);
>       if (x == 10) {
>           // Code should always run ...
> ```
> The compiler can save registers by re-loading from p in the code
> above, meaning the second "if" may not always run.

mutex_lock() should imply barrier() which should very much inhibit this.