| Message ID | 35c0fc4ba93b11c4b8a55c2907f736a840cd12a3.1675161286.git.geert+renesas@glider.be (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [resend] compiler-intel: Remove duplicate RELOC_HIDE() | expand |
On Tue, Jan 31, 2023, at 11:37, Geert Uytterhoeven wrote: > The RELOC_HIDE() implementation for the Intel compiler is identical to > the generic version in <linux/compiler.h>, so the former can just be > removed. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > Not even compile-tested. > --- > include/linux/compiler-intel.h | 5 ----- > 1 file changed, 5 deletions(-) I thought the entire file was gone already. I don't see anyone objecting to the earlier patch https://lore.kernel.org/all/20221016182349.49308-1-masahiroy@kernel.org/ but it never made it in. Maybe we can revive that instead? Otherwise, your patch looks obviously correct as well. Acked-by: Arnd Bergmann <arnd@arndb.de>
On 31/01/2023 11.41, Arnd Bergmann wrote: > On Tue, Jan 31, 2023, at 11:37, Geert Uytterhoeven wrote: >> The RELOC_HIDE() implementation for the Intel compiler is identical to >> the generic version in <linux/compiler.h>, so the former can just be >> removed. >> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> >> --- >> Not even compile-tested. >> --- >> include/linux/compiler-intel.h | 5 ----- >> 1 file changed, 5 deletions(-) > > I thought the entire file was gone already. I don't see anyone > objecting to the earlier patch > > https://lore.kernel.org/all/20221016182349.49308-1-masahiroy@kernel.org/ > > but it never made it in. Maybe we can revive that instead? Yes, please!
On Tue, Jan 31, 2023 at 7:59 PM Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote: > > On 31/01/2023 11.41, Arnd Bergmann wrote: > > On Tue, Jan 31, 2023, at 11:37, Geert Uytterhoeven wrote: > >> The RELOC_HIDE() implementation for the Intel compiler is identical to > >> the generic version in <linux/compiler.h>, so the former can just be > >> removed. > >> > >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > >> --- > >> Not even compile-tested. > >> --- > >> include/linux/compiler-intel.h | 5 ----- > >> 1 file changed, 5 deletions(-) > > > > I thought the entire file was gone already. I don't see anyone > > objecting to the earlier patch > > > > https://lore.kernel.org/all/20221016182349.49308-1-masahiroy@kernel.org/ > > > > but it never made it in. Maybe we can revive that instead? > > Yes, please! > I hoped it would be picked up by Linus directly, or by an x86 maintainer. We can re-push it in the next merge window.
diff --git a/include/linux/compiler-intel.h b/include/linux/compiler-intel.h index b17f3cd18334df3d..efc8fafb58f595b2 100644 --- a/include/linux/compiler-intel.h +++ b/include/linux/compiler-intel.h @@ -16,11 +16,6 @@ #define barrier() __memory_barrier() #define barrier_data(ptr) barrier() -#define RELOC_HIDE(ptr, off) \ - ({ unsigned long __ptr; \ - __ptr = (unsigned long) (ptr); \ - (typeof(ptr)) (__ptr + (off)); }) - /* This should act as an optimization barrier on var. * Given that this compiler does not have inline assembly, a compiler barrier * is the best we can do.
The RELOC_HIDE() implementation for the Intel compiler is identical to the generic version in <linux/compiler.h>, so the former can just be removed. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> --- Not even compile-tested. --- include/linux/compiler-intel.h | 5 ----- 1 file changed, 5 deletions(-)