Displaying 7 results from an estimated 7 matches for "config_lto".
Did you mean:
config_atm
2020 Jul 10
0
[PATCH v3 19/19] arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y
...b/arch/arm64/include/asm/rwonce.h
new file mode 100644
index 000000000000..d78eb4cb795b
--- /dev/null
+++ b/arch/arm64/include/asm/rwonce.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Google LLC.
+ */
+#ifndef __ASM_RWONCE_H
+#define __ASM_RWONCE_H
+
+#ifdef CONFIG_LTO
+
+#include <linux/compiler_types.h>
+#include <asm/alternative-macros.h>
+
+#ifndef BUILD_VDSO
+
+#ifdef CONFIG_AS_HAS_LDAPR
+#define __LOAD_RCPC(sfx, regs...) \
+ ALTERNATIVE( \
+ "ldar" #sfx "\t" #regs, \
+ ".arch_extension rcpc\n" \
+...
2020 Jul 02
0
[PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y
...(C) 2020 Google LLC.
> > + */
> > +#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 co...
2020 Jul 10
24
[PATCH 00/18] Allow architectures to override __READ_ONCE()
...tps://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org
Changes since v2 include:
* Actually add the barrier in READ_ONCE() for Alpha!
* Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than
the other way around.
* Further untangling of header files
* Use CONFIG_LTO instead of CONFIG_CLANG_LTO
I have booted this on arm64, and build-tested as follows:
- arm64 allnoconfig, defconfig (also bisected) and allmodconfig
- arm32 allnoconfig, defconfig and allmodconfig
- x86_64 allnoconfig, defconfig and allmodcofig
- alpha defconfig, defconfig+CONFIG_SMP=y...
2017 Oct 12
2
[PATCH v1 15/27] compiler: Option to default to hidden symbols
On Wed, Oct 11, 2017 at 01:30:15PM -0700, Thomas Garnier wrote:
> Provide an option to default visibility to hidden except for key
> symbols. This option is disabled by default and will be used by x86_64
> PIE support to remove errors between compilation units.
>
> The default visibility is also enabled for external symbols that are
> compared as they maybe equals (start/end of
2017 Oct 12
2
[PATCH v1 15/27] compiler: Option to default to hidden symbols
On Wed, Oct 11, 2017 at 01:30:15PM -0700, Thomas Garnier wrote:
> Provide an option to default visibility to hidden except for key
> symbols. This option is disabled by default and will be used by x86_64
> PIE support to remove errors between compilation units.
>
> The default visibility is also enabled for external symbols that are
> compared as they maybe equals (start/end of
2020 Jun 30
32
[PATCH 00/18] Allow architectures to override __READ_ONCE()
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
2020 Jun 30
32
[PATCH 00/18] Allow architectures to override __READ_ONCE()
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