search for: config_lto_clang

...maybe leave it optional?). In future, for > > very aggressive non-LTO compilers even, one may then also select that > > if there is substantiated worry things do actually break. > > I agree, a separate config option would be better here. > > Also Will, the LTO patches use CONFIG_LTO_CLANG instead of CLANG_LTO. D'oh, sorry. I'll fix that (I had that #ifdef commented out for my testing). Will

...*/ > > +#ifndef __ASM_RWONCE_H > > +#define __ASM_RWONCE_H > > + > > +#ifdef CONFIG_CLANG_LTO > > Don't we have a generic option for LTO that's not specific to Clang. /me looks at the LTO series some more Oh yeah, there's CONFIG_LTO which is selected by CONFIG_LTO_CLANG, which is the non-typoed version of the above. I can switch this to CONFIG_LTO. > Also, can you illustrate code that can only be unsafe with Clang LTO? I don't have a concrete example, but it's an ongoing concern over on the LTO thread [1], so I cooked this to show one way we could dea...

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The