[Buildroot] [PATCH v4 00/15] Add gcc 9.1

[Buildroot] [PATCH v4 00/15] Add gcc 9.1

[Giulio Benetti]

Before adding gcc 9.1 [1] to Buildroot, add some fixes for issues discovered
by toolchain-builder [2] that are trigged by this new compiler version.
(disable powerpc Werror, uClibc-ng asm sparc and ARC glibc).

Then add gcc 9.1 for internal and extenal toolchain backend and switch gcc 8.x
as default compiler.

Thanks to Yann E. MORIN for providing a patch series that add new ARM cores
added by gcc 9.1.

Each new ARM core has been build tested for aarch64:
https://gitlab.com/kubu93/buildroot/pipelines/60318953

Finally, enable the new ork1 (openrisc) that will replace in the following
series the old gcc fork (gcc 5.x).

[1] https://gcc.gnu.org/gcc-9/changes.html
[2] https://gitlab.com/kubu93/toolchains-builder/pipelines/59794237

Romain Naour (9):
  package/glibc/arc: fix build issue with gcc-9.1
  linux: disable Werror for powerpc kernels
  package/uclibc: remove asm constraint
  toolchain: add gcc 9 entry
  package/gcc: add support for gcc 9.1
  arch: add BR2_ARCH_NEEDS_GCC_AT_LEAST_9
  toolchain-external: add gcc 9 entry
  package/gcc: switch to gcc 8.x as the default
  package/gcc: enable gcc 9.1 for ork1 (openrisc)

Yann E. MORIN (6):
  arch/arm: move dependency on 64-bit down to individual cores
  arch/arm: some cores have a different name with gcc-9
  arch/arm: saphira is in fact an armv8.4a
  arch/arm: add two new 64-bit-only armv8a cores
  arch/arm: add two new cortex-based armv8.2a cores
  arch/arm: add two new non-cortex-based armv8.2a cores

 arch/Config.in                                |   4 +
 arch/Config.in.arm                            |  95 +++++++++--
 linux/linux.mk                                |   2 +
 package/gcc/Config.in.host                    |   8 +-
 package/gcc/gcc.hash                          |   2 +
 package/gcc/gcc.mk                            |   4 +-
 ...Add-support-for-GCC-9-attribute-copy.patch | 160 ++++++++++++++++++
 ...arc-syscalls.h-remove-asm-constraint.patch |  46 +++++
 toolchain/Config.in                           |   5 +
 .../Config.in.options                         |   6 +
 10 files changed, 313 insertions(+), 19 deletions(-)
 create mode 100644 package/glibc/arc-2018.09-release/0001-Add-support-for-GCC-9-attribute-copy.patch
 create mode 100644 package/uclibc/0003-RFC-sparc-syscalls.h-remove-asm-constraint.patch

-- 
2.17.1

[Buildroot] [PATCH v4 01/15] package/glibc/arc: fix build issue with gcc-9.1

[Giulio Benetti]

From: Romain Naour <romain.naour@gmail.com>

Backport from upstream [1] to fix build issue with glibc arc-2018.09-release
(based on glibc 2.28) and gcc 9.1 [2]]

Using glibc arc-2.29-2019.02.08 or the upcoming arc-2019.03 release include
this patch.

The upstream patch [1] modify mostly x86_64 files, but also two generic headers
where the new __attribute_copy__() macro is defined *and* used to complement
existing attribute-related macros.

So, it is not much the x86_64 part we're interested in, but the generic
two headers, which changes percolate to the various functions via the
various attribute macros...

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=1626a1cfcd6ba1cc64721be1036c2873211d499b
[2] https://gitlab.com/kubu93/toolchains-builder/-/jobs/205435682

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
v2: remove x86_64 part of the backported patch (Yann).
    commit log (Yann)
---
 ...Add-support-for-GCC-9-attribute-copy.patch | 160 ++++++++++++++++++
 1 file changed, 160 insertions(+)
 create mode 100644 package/glibc/arc-2018.09-release/0001-Add-support-for-GCC-9-attribute-copy.patch

diff --git a/package/glibc/arc-2018.09-release/0001-Add-support-for-GCC-9-attribute-copy.patch b/package/glibc/arc-2018.09-release/0001-Add-support-for-GCC-9-attribute-copy.patch
new file mode 100644
index 0000000000..0c0a8a9337
--- /dev/null
+++ b/package/glibc/arc-2018.09-release/0001-Add-support-for-GCC-9-attribute-copy.patch
@@ -0,0 +1,160 @@
+From 3e0c7985c9535304d87af3ad728f5f6d34557f0d Mon Sep 17 00:00:00 2001
+From: Martin Sebor <msebor@redhat.com>
+Date: Fri, 9 Nov 2018 17:24:12 -0700
+Subject: [PATCH] Add support for GCC 9 attribute copy.
+
+GCC 9 has gained an enhancement to help detect attribute mismatches
+between alias declarations and their targets.  It consists of a new
+warning, -Wattribute-alias, an enhancement to an existing warning,
+-Wmissing-attributes, and a new attribute called copy.
+
+The purpose of the warnings is to help identify either possible bugs
+(an alias declared with more restrictive attributes than its target
+promises) or optimization or diagnostic opportunities (an alias target
+missing some attributes that it could be declared with that might
+benefit analysis and code generation).  The purpose of the new
+attribute is to easily apply (almost) the same set of attributes
+to one declaration as those already present on another.
+
+As expected (and intended) the enhancement triggers warnings for
+many alias declarations in Glibc code.  This change, tested on
+x86_64-linux, avoids all instances of the new warnings by making
+use of the attribute where appropriate.  To fully benefit from
+the enhancement Glibc will need to be compiled with
+ -Wattribute-alias=2 and remaining warnings reviewed and dealt with
+(there are a couple of thousand but most should be straightforward
+to deal with).
+
+ChangeLog:
+
+	* include/libc-symbols.h (__attribute_copy__): Define macro unless
+	it's already defined.
+	(_strong_alias): Use __attribute_copy__.
+	(_weak_alias,  __hidden_ver1,  __hidden_nolink2): Same.
+	* misc/sys/cdefs.h (__attribute_copy__): New macro.
+	* sysdeps/x86_64/multiarch/memchr.c (memchr): Use __attribute_copy__.
+	* sysdeps/x86_64/multiarch/memcmp.c (memcmp): Same.
+	* sysdeps/x86_64/multiarch/mempcpy.c (mempcpy): Same.
+	* sysdeps/x86_64/multiarch/memset.c (memset): Same.
+	* sysdeps/x86_64/multiarch/stpcpy.c (stpcpy): Same.
+	* sysdeps/x86_64/multiarch/strcat.c (strcat): Same.
+	* sysdeps/x86_64/multiarch/strchr.c (strchr): Same.
+	* sysdeps/x86_64/multiarch/strcmp.c (strcmp): Same.
+	* sysdeps/x86_64/multiarch/strcpy.c (strcpy): Same.
+	* sysdeps/x86_64/multiarch/strcspn.c (strcspn): Same.
+	* sysdeps/x86_64/multiarch/strlen.c (strlen): Same.
+	* sysdeps/x86_64/multiarch/strncmp.c (strncmp): Same.
+	* sysdeps/x86_64/multiarch/strncpy.c (strncpy): Same.
+	* sysdeps/x86_64/multiarch/strnlen.c (strnlen): Same.
+	* sysdeps/x86_64/multiarch/strpbrk.c (strpbrk): Same.
+	* sysdeps/x86_64/multiarch/strrchr.c (strrchr): Same.
+	* sysdeps/x86_64/multiarch/strspn.c (strspn): Same.
+
+Using glibc arc-2.29-2019.02.08 or the upcoming arc-2019.03 release include this patch.
+
+[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=1626a1cfcd6ba1cc64721be1036c2873211d499b
+[2] https://gitlab.com/kubu93/toolchains-builder/-/jobs/205435682
+
+Signed-off-by: Romain Naour <romain.naour@gmail.com>
+[Romain:
+    - Backport from upstream [1] to fix build issue with glibc arc-2018.09-release
+      (based on glibc 2.28) and gcc 9.1 [2]
+    - Also drop the x86-64 related hunks to avoid confusion.
+]
+Cc: Alexey Brodkin <alexey.brodkin@synopsys.com>
+Cc: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
+Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
+---
+ include/libc-symbols.h | 20 +++++++++++++++-----
+ misc/sys/cdefs.h       | 10 ++++++++++
+ 2 files changed, 25 insertions(+), 5 deletions(-)
+
+diff --git a/include/libc-symbols.h b/include/libc-symbols.h
+index 8b9273c13a..e71a479e84 100644
+--- a/include/libc-symbols.h
++++ b/include/libc-symbols.h
+@@ -125,6 +125,11 @@
+ # define ASM_LINE_SEP ;
+ #endif
+ 
++#ifndef __attribute_copy__
++/* Provide an empty definition when cdefs.h is not included.  */
++# define __attribute_copy__(arg)
++#endif
++
+ #ifndef __ASSEMBLER__
+ /* GCC understands weak symbols and aliases; use its interface where
+    possible, instead of embedded assembly language.  */
+@@ -132,7 +137,8 @@
+ /* Define ALIASNAME as a strong alias for NAME.  */
+ # define strong_alias(name, aliasname) _strong_alias(name, aliasname)
+ # define _strong_alias(name, aliasname) \
+-  extern __typeof (name) aliasname __attribute__ ((alias (#name)));
++  extern __typeof (name) aliasname __attribute__ ((alias (#name))) \
++    __attribute_copy__ (name);
+ 
+ /* This comes between the return type and function name in
+    a function definition to make that definition weak.  */
+@@ -143,14 +149,16 @@
+    If weak aliases are not available, this defines a strong alias.  */
+ # define weak_alias(name, aliasname) _weak_alias (name, aliasname)
+ # define _weak_alias(name, aliasname) \
+-  extern __typeof (name) aliasname __attribute__ ((weak, alias (#name)));
++  extern __typeof (name) aliasname __attribute__ ((weak, alias (#name))) \
++    __attribute_copy__ (name);
+ 
+ /* Same as WEAK_ALIAS, but mark symbol as hidden.  */
+ # define weak_hidden_alias(name, aliasname) \
+   _weak_hidden_alias (name, aliasname)
+ # define _weak_hidden_alias(name, aliasname) \
+   extern __typeof (name) aliasname \
+-    __attribute__ ((weak, alias (#name), __visibility__ ("hidden")));
++    __attribute__ ((weak, alias (#name), __visibility__ ("hidden"))) \
++    __attribute_copy__ (name);
+ 
+ /* Declare SYMBOL as weak undefined symbol (resolved to 0 if not defined).  */
+ # define weak_extern(symbol) _weak_extern (weak symbol)
+@@ -532,7 +540,8 @@ for linking")
+ #  define __hidden_ver1(local, internal, name) \
+   extern __typeof (name) __EI_##name __asm__(__hidden_asmname (#internal)); \
+   extern __typeof (name) __EI_##name \
+-	__attribute__((alias (__hidden_asmname (#local))))
++    __attribute__((alias (__hidden_asmname (#local))))	\
++    __attribute_copy__ (name)
+ #  define hidden_ver(local, name)	__hidden_ver1(local, __GI_##name, name);
+ #  define hidden_data_ver(local, name)	hidden_ver(local, name)
+ #  define hidden_def(name)		__hidden_ver1(__GI_##name, name, name);
+@@ -545,7 +554,8 @@ for linking")
+ #  define __hidden_nolink1(local, internal, name, version) \
+   __hidden_nolink2 (local, internal, name, version)
+ #  define __hidden_nolink2(local, internal, name, version) \
+-  extern __typeof (name) internal __attribute__ ((alias (#local))); \
++  extern __typeof (name) internal __attribute__ ((alias (#local)))	\
++    __attribute_copy__ (name);						\
+   __hidden_nolink3 (local, internal, #name "@" #version)
+ #  define __hidden_nolink3(local, internal, vername) \
+   __asm__ (".symver " #internal ", " vername);
+diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h
+index 3f6fe3cc85..8d585680a6 100644
+--- a/misc/sys/cdefs.h
++++ b/misc/sys/cdefs.h
+@@ -431,6 +431,16 @@
+ # define __attribute_nonstring__
+ #endif
+ 
++/* Undefine (also defined in libc-symbols.h).  */
++#undef __attribute_copy__
++#if __GNUC_PREREQ (9, 0)
++/* Copies attributes from the declaration or type referenced by
++   the argument.  */
++# define __attribute_copy__(arg) __attribute__ ((__copy__ (arg)))
++#else
++# define __attribute_copy__(arg)
++#endif
++
+ #if (!defined _Static_assert && !defined __cplusplus \
+      && (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) < 201112 \
+      && (!__GNUC_PREREQ (4, 6) || defined __STRICT_ANSI__))
+-- 
+2.14.5
+
-- 
2.17.1

[Buildroot] [PATCH v4 01/15] package/glibc/arc: fix build issue with gcc-9.1

[Thomas Petazzoni]

On Thu, 20 Jun 2019 12:07:11 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:

> From: Romain Naour <romain.naour@gmail.com>
> 
> Backport from upstream [1] to fix build issue with glibc arc-2018.09-release
> (based on glibc 2.28) and gcc 9.1 [2]]
> 
> Using glibc arc-2.29-2019.02.08 or the upcoming arc-2019.03 release include
> this patch.

Since then, we have indeed updated ARC glibc's version to 2019.03, so
this patch is no longer necessary if I understood correctly. I marked
it as "Not Applicable" in patchwork.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 02/15] linux: disable Werror for powerpc kernels

[Giulio Benetti]

From: Romain Naour <romain.naour@gmail.com>

From patch [1] included in kernel >= 5.0:
"The upcoming GCC 9 release extends the -Wmissing-attributes warnings
(enabled by -Wall) to C and aliases: it warns when particular function
attributes are missing in the aliases but not in their target.

In particular, it triggers for all the init/cleanup_module
aliases in the kernel (defined by the module_init/exit macros),
ending up being very noisy.

These aliases point to the __init/__exit functions of a module,
which are defined as __cold (among other attributes). However,
the aliases themselves do not have the __cold attribute.

Since the compiler behaves differently when compiling a __cold
function as well as when compiling paths leading to calls
to __cold functions, the warning is trying to point out
the possibly-forgotten attribute in the alias."

Werror is set by default while building ppc kernel [2], but
some warning can be introduced while building current kernel with
newer compiler (for example building kernel 4.19 with gcc 9.1).

For the same reason why we remove Werror in packages's compiler
flags. Building with Werror is not bulletproof when we start
using a newer compiler that introduce new warnings.
This is the case here.

Also this option is a bit strange since it's specific to ppc kernels:
"The intention is to make it harder for people to inadvertantly
introduce warnings in the arch/powerpc code."
Other kernel developers on other arch may be interested by a
similar/more generic option.

So, It's clearly intended for kernel developers.

Instead of backporting this patch [1] to kernel 4.19, select
unconditionally the Kconfig option CONFIG_PPC_DISABLE_WERROR
that allow to disable Werror.

Fixes:
https://gitlab.com/kubu93/toolchains-builder/-/jobs/205435741

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=a6e60d84989fa0e91db7f236eda40453b0e44afa
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=ba55bd74360ea4b8b95e73ed79474d37ff482b36
[3] https://gitlab.com/bootlin/toolchains-builder

Fix-suggested-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
v2: add a shared fragment in board/fragments/linux and update
    qemu ppc* defconfigs. (Arnout)

v3: commit log (Yann)
    enable the option from linux.mk instead of the defconfig.
---
 linux/linux.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/linux/linux.mk b/linux/linux.mk
index dd182d06b2..a1378345c3 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -316,6 +316,8 @@ define LINUX_KCONFIG_FIXUP_CMDS
 	$(LINUX_FIXUP_CONFIG_ENDIANNESS)
 	$(if $(BR2_arm)$(BR2_armeb),
 		$(call KCONFIG_ENABLE_OPT,CONFIG_AEABI,$(@D)/.config))
+	$(if $(BR2_powerpc)$(BR2_powerpc64)$(BR2_powerpc64le),
+		$(call KCONFIG_ENABLE_OPT,CONFIG_PPC_DISABLE_WERROR,$(@D)/.config))
 	$(if $(BR2_TARGET_ROOTFS_CPIO),
 		$(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_INITRD,$(@D)/.config))
 	# As the kernel gets compiled before root filesystems are
-- 
2.17.1

[Buildroot] [PATCH v4 02/15] linux: disable Werror for powerpc kernels

[Thomas Petazzoni]

On Thu, 20 Jun 2019 12:07:12 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:

> From: Romain Naour <romain.naour@gmail.com>
> 
> From patch [1] included in kernel >= 5.0:
> "The upcoming GCC 9 release extends the -Wmissing-attributes warnings
> (enabled by -Wall) to C and aliases: it warns when particular function
> attributes are missing in the aliases but not in their target.
> 
> In particular, it triggers for all the init/cleanup_module
> aliases in the kernel (defined by the module_init/exit macros),
> ending up being very noisy.
> 
> These aliases point to the __init/__exit functions of a module,
> which are defined as __cold (among other attributes). However,
> the aliases themselves do not have the __cold attribute.
> 
> Since the compiler behaves differently when compiling a __cold
> function as well as when compiling paths leading to calls
> to __cold functions, the warning is trying to point out
> the possibly-forgotten attribute in the alias."
> 
> Werror is set by default while building ppc kernel [2], but
> some warning can be introduced while building current kernel with
> newer compiler (for example building kernel 4.19 with gcc 9.1).
> 
> For the same reason why we remove Werror in packages's compiler
> flags. Building with Werror is not bulletproof when we start
> using a newer compiler that introduce new warnings.
> This is the case here.
> 
> Also this option is a bit strange since it's specific to ppc kernels:
> "The intention is to make it harder for people to inadvertantly
> introduce warnings in the arch/powerpc code."
> Other kernel developers on other arch may be interested by a
> similar/more generic option.
> 
> So, It's clearly intended for kernel developers.
> 
> Instead of backporting this patch [1] to kernel 4.19, select
> unconditionally the Kconfig option CONFIG_PPC_DISABLE_WERROR
> that allow to disable Werror.
> 
> Fixes:
> https://gitlab.com/kubu93/toolchains-builder/-/jobs/205435741
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=a6e60d84989fa0e91db7f236eda40453b0e44afa
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=ba55bd74360ea4b8b95e73ed79474d37ff482b36
> [3] https://gitlab.com/bootlin/toolchains-builder
> 
> Fix-suggested-by: Yann E. MORIN <yann.morin.1998@free.fr>
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
> v2: add a shared fragment in board/fragments/linux and update
>     qemu ppc* defconfigs. (Arnout)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 02/15] linux: disable Werror for powerpc kernels

[Peter Korsgaard]

>>>>> "Giulio" == Giulio Benetti <giulio.benetti@micronovasrl.com> writes:

 > From: Romain Naour <romain.naour@gmail.com>
 > From patch [1] included in kernel >= 5.0:
 > "The upcoming GCC 9 release extends the -Wmissing-attributes warnings
 > (enabled by -Wall) to C and aliases: it warns when particular function
 > attributes are missing in the aliases but not in their target.

 > In particular, it triggers for all the init/cleanup_module
 > aliases in the kernel (defined by the module_init/exit macros),
 > ending up being very noisy.

 > These aliases point to the __init/__exit functions of a module,
 > which are defined as __cold (among other attributes). However,
 > the aliases themselves do not have the __cold attribute.

 > Since the compiler behaves differently when compiling a __cold
 > function as well as when compiling paths leading to calls
 > to __cold functions, the warning is trying to point out
 > the possibly-forgotten attribute in the alias."

 > Werror is set by default while building ppc kernel [2], but
 > some warning can be introduced while building current kernel with
 > newer compiler (for example building kernel 4.19 with gcc 9.1).

 > For the same reason why we remove Werror in packages's compiler
 > flags. Building with Werror is not bulletproof when we start
 > using a newer compiler that introduce new warnings.
 > This is the case here.

 > Also this option is a bit strange since it's specific to ppc kernels:
 > "The intention is to make it harder for people to inadvertantly
 > introduce warnings in the arch/powerpc code."
 > Other kernel developers on other arch may be interested by a
 > similar/more generic option.

 > So, It's clearly intended for kernel developers.

 > Instead of backporting this patch [1] to kernel 4.19, select
 > unconditionally the Kconfig option CONFIG_PPC_DISABLE_WERROR
 > that allow to disable Werror.

 > Fixes:
 > https://gitlab.com/kubu93/toolchains-builder/-/jobs/205435741

 > [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=a6e60d84989fa0e91db7f236eda40453b0e44afa
 > [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=ba55bd74360ea4b8b95e73ed79474d37ff482b36
 > [3] https://gitlab.com/bootlin/toolchains-builder

 > Fix-suggested-by: Yann E. MORIN <yann.morin.1998@free.fr>
 > Signed-off-by: Romain Naour <romain.naour@gmail.com>
 > Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
 > ---
 > v2: add a shared fragment in board/fragments/linux and update
 >     qemu ppc* defconfigs. (Arnout)

 > v3: commit log (Yann)
 >     enable the option from linux.mk instead of the defconfig.

Committed to 2019.02.x and 2019.05.x, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v4 02/15] linux: disable Werror for powerpc kernels

[Baruch Siach]

Hi Peter,

On Mon, Jun 24 2019, Peter Korsgaard wrote:

>>>>>> "Giulio" == Giulio Benetti <giulio.benetti@micronovasrl.com> writes:
>
>  > From: Romain Naour <romain.naour@gmail.com>
>  > From patch [1] included in kernel >= 5.0:
>  > "The upcoming GCC 9 release extends the -Wmissing-attributes warnings
>  > (enabled by -Wall) to C and aliases: it warns when particular function
>  > attributes are missing in the aliases but not in their target.
>
>  > In particular, it triggers for all the init/cleanup_module
>  > aliases in the kernel (defined by the module_init/exit macros),
>  > ending up being very noisy.
>
>  > These aliases point to the __init/__exit functions of a module,
>  > which are defined as __cold (among other attributes). However,
>  > the aliases themselves do not have the __cold attribute.
>
>  > Since the compiler behaves differently when compiling a __cold
>  > function as well as when compiling paths leading to calls
>  > to __cold functions, the warning is trying to point out
>  > the possibly-forgotten attribute in the alias."
>
>  > Werror is set by default while building ppc kernel [2], but
>  > some warning can be introduced while building current kernel with
>  > newer compiler (for example building kernel 4.19 with gcc 9.1).
>
>  > For the same reason why we remove Werror in packages's compiler
>  > flags. Building with Werror is not bulletproof when we start
>  > using a newer compiler that introduce new warnings.
>  > This is the case here.
>
>  > Also this option is a bit strange since it's specific to ppc kernels:
>  > "The intention is to make it harder for people to inadvertantly
>  > introduce warnings in the arch/powerpc code."
>  > Other kernel developers on other arch may be interested by a
>  > similar/more generic option.
>
>  > So, It's clearly intended for kernel developers.
>
>  > Instead of backporting this patch [1] to kernel 4.19, select
>  > unconditionally the Kconfig option CONFIG_PPC_DISABLE_WERROR
>  > that allow to disable Werror.
>
>  > Fixes:
>  > https://gitlab.com/kubu93/toolchains-builder/-/jobs/205435741
>
>  > [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=a6e60d84989fa0e91db7f236eda40453b0e44afa
>  > [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=ba55bd74360ea4b8b95e73ed79474d37ff482b36
>  > [3] https://gitlab.com/bootlin/toolchains-builder
>
>  > Fix-suggested-by: Yann E. MORIN <yann.morin.1998@free.fr>
>  > Signed-off-by: Romain Naour <romain.naour@gmail.com>
>  > Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
>  > ---
>  > v2: add a shared fragment in board/fragments/linux and update
>  >     qemu ppc* defconfigs. (Arnout)
>
>  > v3: commit log (Yann)
>  >     enable the option from linux.mk instead of the defconfig.
>
> Committed to 2019.02.x and 2019.05.x, thanks.

It is in 2019.02.x, but not in 2019.05.x as of commit 1818dae1e0.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[Buildroot] [PATCH v4 02/15] linux: disable Werror for powerpc kernels

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

Hi,

 >> Committed to 2019.02.x and 2019.05.x, thanks.

 > It is in 2019.02.x, but not in 2019.05.x as of commit 1818dae1e0.

Ups, indeed - Fixed now, thanks!

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v4 03/15] package/uclibc: remove asm constraint

[Giulio Benetti]

From: Romain Naour <romain.naour@gmail.com>

uClibc-ng don't build with gcc 9.1 [1] due to a new check that
"catch illegal asm constraint usage" [2].

gcc 9.1 print this error:
"invalid hard register usage between earlyclobber operand and input operand"

The asm constraint is present in uClibc since it support sparc (back in 2002)[3].

Note: There is no such constraint is Glibc counterpart code [4].

[1] https://gitlab.com/kubu93/toolchains-builder/-/jobs/205435757
[2] https://github.com/gcc-mirror/gcc/commit/b782636f28f5c378897c238081d28d7a4a6ca578
[3] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=3b6d086531102b6d09ce852feb1e370d5dca3ce9
[4] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/sparc/sysdep.h;h=981b2a26b7a91093f821c97876e55bc4be2d9f8a;hb=HEAD

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
I did not fully analyze the asm code to understand why the constraint is present.
I lightly tested using qemu_sparc_ss10_defconfig.
Any help is welcome(Romain)
---
 ...arc-syscalls.h-remove-asm-constraint.patch | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 package/uclibc/0003-RFC-sparc-syscalls.h-remove-asm-constraint.patch

diff --git a/package/uclibc/0003-RFC-sparc-syscalls.h-remove-asm-constraint.patch b/package/uclibc/0003-RFC-sparc-syscalls.h-remove-asm-constraint.patch
new file mode 100644
index 0000000000..050dc573b0
--- /dev/null
+++ b/package/uclibc/0003-RFC-sparc-syscalls.h-remove-asm-constraint.patch
@@ -0,0 +1,46 @@
+From 1854c332efa0ed5b9140d8df2a983625a1e2d9ef Mon Sep 17 00:00:00 2001
+From: Romain Naour <romain.naour@gmail.com>
+Date: Sun, 5 May 2019 10:56:30 +0200
+Subject: [PATCH] [RFC] sparc: syscalls.h: remove asm constraint
+
+uClibc-ng don't build with gcc 9.1 [1] due to a new check that
+"catch illegal asm constraint usage" [2].
+
+gcc 9.1 print this error:
+"invalid hard register usage between earlyclobber operand and input operand"
+
+The asm constraint is present in uClibc since it support sparc (back in 2002)[3].
+
+Note: There is no such constraint is Glibc counterpart code [4].
+
+[1] https://gitlab.com/kubu93/toolchains-builder/-/jobs/205435757
+[2] https://github.com/gcc-mirror/gcc/commit/b782636f28f5c378897c238081d28d7a4a6ca578
+[3] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=3b6d086531102b6d09ce852feb1e370d5dca3ce9
+[4] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/sparc/sysdep.h;h=981b2a26b7a91093f821c97876e55bc4be2d9f8a;hb=HEAD
+
+Signed-off-by: Romain Naour <romain.naour@gmail.com>
+Cc: Waldemar Brodkorb <wbx@openadk.org>
+---
+I did not fully analyze the asm code to understand why the constraint is present.
+I lightly tested using qemu_sparc_ss10_defconfig.
+Any help is welcome :)
+---
+ libc/sysdeps/linux/sparc/bits/syscalls.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libc/sysdeps/linux/sparc/bits/syscalls.h b/libc/sysdeps/linux/sparc/bits/syscalls.h
+index 75af7a1573..e52ab98466 100644
+--- a/libc/sysdeps/linux/sparc/bits/syscalls.h
++++ b/libc/sysdeps/linux/sparc/bits/syscalls.h
+@@ -33,7 +33,7 @@
+             register long __g1 __asm__("g1") = sys_num;     \
+             LOAD_ARGS_##nr(args)                            \
+             __asm__ __volatile__( __SYSCALL_STRING          \
+-                : "=r" (__res), "=&r" (__o0)                \
++                : "=r" (__res), "=r" (__o0)                 \
+                 : "1" (__o0) ASM_ARGS_##nr, "r" (__g1)     \
+                 : __SYSCALL_CLOBBERS );                                   \
+         }                                                   \
+-- 
+2.14.5
+
-- 
2.17.1

[Buildroot] [PATCH v4 03/15] package/uclibc: remove asm constraint

[Thomas Petazzoni]

On Thu, 20 Jun 2019 12:07:13 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:

> From: Romain Naour <romain.naour@gmail.com>
> 
> uClibc-ng don't build with gcc 9.1 [1] due to a new check that
> "catch illegal asm constraint usage" [2].
> 
> gcc 9.1 print this error:
> "invalid hard register usage between earlyclobber operand and input operand"
> 
> The asm constraint is present in uClibc since it support sparc (back in 2002)[3].
> 
> Note: There is no such constraint is Glibc counterpart code [4].
> 
> [1] https://gitlab.com/kubu93/toolchains-builder/-/jobs/205435757
> [2] https://github.com/gcc-mirror/gcc/commit/b782636f28f5c378897c238081d28d7a4a6ca578
> [3] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=3b6d086531102b6d09ce852feb1e370d5dca3ce9
> [4] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/sparc/sysdep.h;h=981b2a26b7a91093f821c97876e55bc4be2d9f8a;hb=HEAD
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: Waldemar Brodkorb <wbx@openadk.org>
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
> I did not fully analyze the asm code to understand why the constraint is present.
> I lightly tested using qemu_sparc_ss10_defconfig.
> Any help is welcome(Romain)
> ---
>  ...arc-syscalls.h-remove-asm-constraint.patch | 46 +++++++++++++++++++
>  1 file changed, 46 insertions(+)
>  create mode 100644 package/uclibc/0003-RFC-sparc-syscalls.h-remove-asm-constraint.patch

Since the patch was applied upstream in uclibc-ng, I backported the
uclibc-ng patch. Of course the code is the same, but the file name was
a bit different. Also, I updated the commit log to indicate that we're
talking about a sparc issue.

Applied with those changes. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 04/15] toolchain: add gcc 9 entry

[Giulio Benetti]

From: Romain Naour <romain.naour@gmail.com>

In order to add gcc 9 support for internal and external toolchain in
follow-up commits, introduce BR2_TOOLCHAIN_GCC_AT_LEAST_9 symbol.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 toolchain/Config.in | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/toolchain/Config.in b/toolchain/Config.in
index 2da537e7d4..7726ae6fae 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -507,10 +507,15 @@ config BR2_TOOLCHAIN_GCC_AT_LEAST_8
 	bool
 	select BR2_TOOLCHAIN_GCC_AT_LEAST_7
 
+config BR2_TOOLCHAIN_GCC_AT_LEAST_9
+	bool
+	select BR2_TOOLCHAIN_GCC_AT_LEAST_8
+
 # This order guarantees that the highest version is set, as kconfig
 # stops affecting a value on the first matching default.
 config BR2_TOOLCHAIN_GCC_AT_LEAST
 	string
+	default "9"	if BR2_TOOLCHAIN_GCC_AT_LEAST_9
 	default "8"	if BR2_TOOLCHAIN_GCC_AT_LEAST_8
 	default "7"	if BR2_TOOLCHAIN_GCC_AT_LEAST_7
 	default "6"	if BR2_TOOLCHAIN_GCC_AT_LEAST_6
-- 
2.17.1

[Buildroot] [PATCH v4 04/15] toolchain: add gcc 9 entry

[Thomas Petazzoni]

On Thu, 20 Jun 2019 12:07:14 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:

> From: Romain Naour <romain.naour@gmail.com>
> 
> In order to add gcc 9 support for internal and external toolchain in
> follow-up commits, introduce BR2_TOOLCHAIN_GCC_AT_LEAST_9 symbol.
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
>  toolchain/Config.in | 5 +++++
>  1 file changed, 5 insertions(+)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 05/15] package/gcc: add support for gcc 9.1

[Giulio Benetti]

From: Romain Naour <romain.naour@gmail.com>

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
v2: remove !BR2_ARCH_NEEDS_GCC_AT_LEAST_9 from gcc 8.x
    This symbol will be introduced by the next patch (Yann)
v3: rebase patch on top of master branch sha1:
    04efb17c863606cdbc2405d01c3d48d6868c5245 (Giulio)
v4: rebase patch on top of master branch sha1:
    b34ead55c06cad5b6443da358cd63e9c71265d69 (Giulio)
---
 package/gcc/Config.in.host | 7 +++++++
 package/gcc/gcc.hash       | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
index e451ed9ba9..a1559bb1c6 100644
--- a/package/gcc/Config.in.host
+++ b/package/gcc/Config.in.host
@@ -83,6 +83,12 @@ config BR2_GCC_VERSION_8_X
 	depends on !BR2_powerpc_SPE
 	select BR2_TOOLCHAIN_GCC_AT_LEAST_8
 
+config BR2_GCC_VERSION_9_X
+	bool "gcc 9.x"
+	# Broken or unsupported architectures
+	depends on !BR2_or1k
+	select BR2_TOOLCHAIN_GCC_AT_LEAST_9
+
 endchoice
 
 # libcilkrts was introduced in gcc 4.9 (oldest gcc version we
@@ -98,6 +104,7 @@ config BR2_GCC_VERSION
 	default "6.5.0"     if BR2_GCC_VERSION_6_X
 	default "7.4.0"     if BR2_GCC_VERSION_7_X
 	default "8.3.0"     if BR2_GCC_VERSION_8_X
+	default "9.1.0"     if BR2_GCC_VERSION_9_X
 	default "arc-2019.03-release" if BR2_GCC_VERSION_ARC
 	default "or1k-musl-5.4.0-20170218" if BR2_GCC_VERSION_OR1K
 	default "48152afb96c59733d5bc79e3399bb7b3d4b44266" if BR2_GCC_VERSION_CSKY
diff --git a/package/gcc/gcc.hash b/package/gcc/gcc.hash
index 3f68e6758f..91562aef1e 100644
--- a/package/gcc/gcc.hash
+++ b/package/gcc/gcc.hash
@@ -8,6 +8,8 @@ sha512  ce046f9a50050fd54b870aab764f7db187fe7ea92eb4aaffb7c3689ca623755604e231f2
 sha512  8864d8e4b97c2e1a4f17422f6e68120172ebefeab97b1757734f7185ca68a6b9a89011c6833c03fa454c17b0ac35b15e1d284881e6971035948ac6100f3aa45e  gcc-7.4.0.tar.xz
 # From ftp://gcc.gnu.org/pub/gcc/releases/gcc-8.3.0/sha512.sum
 sha512  1811337ae3add9680cec64968a2509d085b6dc5b6783fc1e8c295e3e47416196fd1a3ad8dfe7e10be2276b4f62c357659ce2902f239f60a8648548231b4b5802  gcc-8.3.0.tar.xz
+#  From ftp://gcc.gnu.org/pub/gcc/releases/gcc-9.1.0/sha512.sum
+sha512  b6134df027e734cee5395afd739fcfa4ea319a6017d662e54e89df927dea19d3fff7a6e35d676685383034e3db01c9d0b653f63574c274eeb15a2cb0bc7a1f28  gcc-9.1.0.tar.xz
 
 # Locally calculated (fetched from Github)
 sha512  c3f63fb601140f92d2dbef96b2dcc025ef754d2f049bfcc3d33e746c7b218b5138f2d8768cd580134858a8d347d234cf3ead276638f6de409f8f07c986e136b6  gcc-arc-2019.03-release.tar.gz
-- 
2.17.1

[Buildroot] [PATCH v4 05/15] package/gcc: add support for gcc 9.1

[Thomas Petazzoni]

On Thu, 20 Jun 2019 12:07:15 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:

> +config BR2_GCC_VERSION_9_X
> +	bool "gcc 9.x"
> +	# Broken or unsupported architectures
> +	depends on !BR2_or1k

gcc 8.x also had a depends on !BR2_csky, but I see that C-SKY support
has been merged in gcc 9.x, so I guess this one is not needed.

However, the depends !BR2_powerpc_spe that gcc 8.x has seemed
necessary, so I've added it for gcc 9.x as well.

Applied with this change. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 06/15] arch: add BR2_ARCH_NEEDS_GCC_AT_LEAST_9

[Giulio Benetti]

From: Romain Naour <romain.naour@gmail.com>

This new symbol will be used by architectures introduced with gcc 9 and
by external toolchains based on gcc 9.

[1] https://gcc.gnu.org/gcc-9/changes.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
v3: rebase patch on top of master branch sha1:
    04efb17c863606cdbc2405d01c3d48d6868c5245 (Giulio)
---
 arch/Config.in             | 4 ++++
 package/gcc/Config.in.host | 1 +
 2 files changed, 5 insertions(+)

diff --git a/arch/Config.in b/arch/Config.in
index db1199c6a2..d8d841b1a2 100644
--- a/arch/Config.in
+++ b/arch/Config.in
@@ -301,6 +301,10 @@ config BR2_ARCH_NEEDS_GCC_AT_LEAST_8
 	bool
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
 
+config BR2_ARCH_NEEDS_GCC_AT_LEAST_9
+	bool
+	select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
+
 # The following string values are defined by the individual
 # Config.in.$ARCH files
 config BR2_ARCH
diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
index a1559bb1c6..b292b49faa 100644
--- a/package/gcc/Config.in.host
+++ b/package/gcc/Config.in.host
@@ -75,6 +75,7 @@ config BR2_GCC_VERSION_7_X
 
 config BR2_GCC_VERSION_8_X
 	bool "gcc 8.x"
+	depends on !BR2_ARCH_NEEDS_GCC_AT_LEAST_9
 	# Broken or unsupported architectures
 	depends on !BR2_csky
 	depends on !BR2_or1k
-- 
2.17.1

[Buildroot] [PATCH v4 06/15] arch: add BR2_ARCH_NEEDS_GCC_AT_LEAST_9

[Thomas Petazzoni]

On Thu, 20 Jun 2019 12:07:16 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:

> From: Romain Naour <romain.naour@gmail.com>
> 
> This new symbol will be used by architectures introduced with gcc 9 and
> by external toolchains based on gcc 9.
> 
> [1] https://gcc.gnu.org/gcc-9/changes.html
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
> v3: rebase patch on top of master branch sha1:
>     04efb17c863606cdbc2405d01c3d48d6868c5245 (Giulio)
> ---
>  arch/Config.in             | 4 ++++
>  package/gcc/Config.in.host | 1 +
>  2 files changed, 5 insertions(+)

Applied to master, thanks. Shouldn't we be using this a bit more ?

I believe C-SKY could select BR2_ARCH_NEEDS_GCC_AT_LEAST_9, and ARC
could select BR2_ARCH_NEEDS_GCC_AT_LEAST_8, this would allow to remove
a few "depends !" from package/gcc/Config.in.host.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 06/15] arch: add BR2_ARCH_NEEDS_GCC_AT_LEAST_9

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > Applied to master, thanks. Shouldn't we be using this a bit more ?

 > I believe C-SKY could select BR2_ARCH_NEEDS_GCC_AT_LEAST_9, and ARC
 > could select BR2_ARCH_NEEDS_GCC_AT_LEAST_8, this would allow to remove
 > a few "depends !" from package/gcc/Config.in.host.

Yes, that could be a nice cleanup - Even though we don't have a lot of
such conditionals.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v4 07/15] toolchain-external: add gcc 9 entry

[Giulio Benetti]

From: Romain Naour <romain.naour@gmail.com>

This patch allows to use an external toolchain based on gcc 9.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 .../toolchain-external-custom/Config.in.options             | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/toolchain/toolchain-external/toolchain-external-custom/Config.in.options b/toolchain/toolchain-external/toolchain-external-custom/Config.in.options
index cb7095632f..a2cc97f936 100644
--- a/toolchain/toolchain-external/toolchain-external-custom/Config.in.options
+++ b/toolchain/toolchain-external/toolchain-external-custom/Config.in.options
@@ -27,6 +27,7 @@ config BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX
 
 choice
 	bool "External toolchain gcc version"
+	default BR2_TOOLCHAIN_EXTERNAL_GCC_9   if BR2_ARCH_NEEDS_GCC_AT_LEAST_9
 	default BR2_TOOLCHAIN_EXTERNAL_GCC_8   if BR2_ARCH_NEEDS_GCC_AT_LEAST_8
 	default BR2_TOOLCHAIN_EXTERNAL_GCC_7   if BR2_ARCH_NEEDS_GCC_AT_LEAST_7
 	default BR2_TOOLCHAIN_EXTERNAL_GCC_6   if BR2_ARCH_NEEDS_GCC_AT_LEAST_6
@@ -38,8 +39,13 @@ choice
 	  Set to the gcc version that is used by your external
 	  toolchain.
 
+config BR2_TOOLCHAIN_EXTERNAL_GCC_9
+	bool "9.x"
+	select BR2_TOOLCHAIN_GCC_AT_LEAST_9
+
 config BR2_TOOLCHAIN_EXTERNAL_GCC_8
 	bool "8.x"
+	depends on !BR2_ARCH_NEEDS_GCC_AT_LEAST_9
 	select BR2_TOOLCHAIN_GCC_AT_LEAST_8
 
 config BR2_TOOLCHAIN_EXTERNAL_GCC_7
-- 
2.17.1

[Buildroot] [PATCH v4 07/15] toolchain-external: add gcc 9 entry

[Thomas Petazzoni]

On Thu, 20 Jun 2019 12:07:17 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:

> From: Romain Naour <romain.naour@gmail.com>
> 
> This patch allows to use an external toolchain based on gcc 9.
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
>  .../toolchain-external-custom/Config.in.options             | 6 ++++++
>  1 file changed, 6 insertions(+)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Giulio Benetti]

From: Romain Naour <romain.naour@gmail.com>

Even if gcc 7 is still maintained for some time (gcc 7.5 is pending),
switch to gcc 8.x since it has been released since 2018-05-02 and
gcc 9.x is available since 2019-05-03.

We have been having toolchains in the autobuilders with gcc
8.x for a while, so the vast majority of the problems should have
already been solved.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
v3: rebase patch on top of master branch sha1:
    04efb17c863606cdbc2405d01c3d48d6868c5245 (Giulio)
---
 package/gcc/Config.in.host | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
index b292b49faa..15f1e8f06a 100644
--- a/package/gcc/Config.in.host
+++ b/package/gcc/Config.in.host
@@ -5,7 +5,7 @@ choice
 	default BR2_GCC_VERSION_ARC if BR2_arc
 	default BR2_GCC_VERSION_CSKY if BR2_csky
 	default BR2_GCC_VERSION_OR1K if BR2_or1k
-	default BR2_GCC_VERSION_7_X
+	default BR2_GCC_VERSION_8_X
 	help
 	  Select the version of gcc you wish to use.
 
-- 
2.17.1

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Thomas Petazzoni]

On Thu, 20 Jun 2019 12:07:18 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:

> From: Romain Naour <romain.naour@gmail.com>
> 
> Even if gcc 7 is still maintained for some time (gcc 7.5 is pending),
> switch to gcc 8.x since it has been released since 2018-05-02 and
> gcc 9.x is available since 2019-05-03.
> 
> We have been having toolchains in the autobuilders with gcc
> 8.x for a while, so the vast majority of the problems should have
> already been solved.
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
> v3: rebase patch on top of master branch sha1:
>     04efb17c863606cdbc2405d01c3d48d6868c5245 (Giulio)
> ---
>  package/gcc/Config.in.host | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to master, thanks.

What do we do with the older gcc versions ? We now have 4.9, 5, 6, 7, 8
and 9, which is quite a bit more than the normal number of 3 versions
we want to support.

Arnout: do you still think gcc 4.9 is needed at this point ? If it is
the case, should we keep gcc 4.9, but drop gcc 5 and 6 ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Romain Naour]

Hi Thomas,

Le 22/06/2019 ? 21:44, Thomas Petazzoni a ?crit?:
> On Thu, 20 Jun 2019 12:07:18 +0200
> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:
> 
>> From: Romain Naour <romain.naour@gmail.com>
>>
>> Even if gcc 7 is still maintained for some time (gcc 7.5 is pending),
>> switch to gcc 8.x since it has been released since 2018-05-02 and
>> gcc 9.x is available since 2019-05-03.
>>
>> We have been having toolchains in the autobuilders with gcc
>> 8.x for a while, so the vast majority of the problems should have
>> already been solved.
>>
>> Signed-off-by: Romain Naour <romain.naour@gmail.com>
>> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
>> ---
>> v3: rebase patch on top of master branch sha1:
>>     04efb17c863606cdbc2405d01c3d48d6868c5245 (Giulio)
>> ---
>>  package/gcc/Config.in.host | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Applied to master, thanks.

Thanks for merging this series :)

> 
> What do we do with the older gcc versions ? We now have 4.9, 5, 6, 7, 8
> and 9, which is quite a bit more than the normal number of 3 versions
> we want to support.
> 
> Arnout: do you still think gcc 4.9 is needed at this point ? If it is
> the case, should we keep gcc 4.9, but drop gcc 5 and 6 ?

Currently glibc >= 2.29 needs gcc >= 5 on all architectures.
So we can only build a toolchain with gcc 4.9 with uClibc and musl.
The upcoming release of glibc will require at least gcc 6.2 on all architectures
[1].

If a toolchain with gcc 4.9 is really needed, it can be build with the 2019.02
LTS version.

Thomas, I have the same question about gdb 7.12.x.

[1]
https://sourceware.org/git/?p=glibc.git;a=commit;h=4dcbbc3b28aaeafe23e1a30db84055aa6f6fa987

Best regards,
Romain

> 
> Best regards,
> 
> Thomas
> 

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Thomas Petazzoni]

Hello,

On Sun, 23 Jun 2019 00:35:38 +0200
Romain Naour <romain.naour@gmail.com> wrote:

> > Arnout: do you still think gcc 4.9 is needed at this point ? If it is
> > the case, should we keep gcc 4.9, but drop gcc 5 and 6 ?  
> 
> Currently glibc >= 2.29 needs gcc >= 5 on all architectures.
> So we can only build a toolchain with gcc 4.9 with uClibc and musl.
> The upcoming release of glibc will require at least gcc 6.2 on all architectures
> [1].
> 
> If a toolchain with gcc 4.9 is really needed, it can be build with the 2019.02
> LTS version.

So, Peter said for the next LTS (2020.02), we probably want to have
removed the oldest gcc versions (4.9, 5 and 6, most likely).

> Thomas, I have the same question about gdb 7.12.x.

I think we should also drop it. I was keeping it because it was the
last gdb version that could be built with a toolchain that doesn't have
C++11 support. But well, C++11 is there since gcc 4.8, so let's assume
most sane people have moved their distribution to a version that has
gcc 4.8 at least.

So on my side, green light to drop gdb 7.12.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

Hi,

 >> Thomas, I have the same question about gdb 7.12.x.

 > I think we should also drop it. I was keeping it because it was the
 > last gdb version that could be built with a toolchain that doesn't have
 > C++11 support. But well, C++11 is there since gcc 4.8, so let's assume
 > most sane people have moved their distribution to a version that has
 > gcc 4.8 at least.

 > So on my side, green light to drop gdb 7.12.

Same from me!

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Arnout Vandecappelle]

On 23/06/2019 18:21, Thomas Petazzoni wrote:
> Hello,
> 
> On Sun, 23 Jun 2019 00:35:38 +0200
> Romain Naour <romain.naour@gmail.com> wrote:
> 
>>> Arnout: do you still think gcc 4.9 is needed at this point ? If it is
>>> the case, should we keep gcc 4.9, but drop gcc 5 and 6 ?  
>>
>> Currently glibc >= 2.29 needs gcc >= 5 on all architectures.
>> So we can only build a toolchain with gcc 4.9 with uClibc and musl.
>> The upcoming release of glibc will require at least gcc 6.2 on all architectures
>> [1].
>>
>> If a toolchain with gcc 4.9 is really needed, it can be build with the 2019.02
>> LTS version.
> 
> So, Peter said for the next LTS (2020.02), we probably want to have
> removed the oldest gcc versions (4.9, 5 and 6, most likely).

 Yes indeed, we can't keep 4.9 around indefinitely, so let's drop it and 5 and 6
as well, leaving just the three most recent ones: 7, 8, 9.


>> Thomas, I have the same question about gdb 7.12.x.
> 
> I think we should also drop it. I was keeping it because it was the
> last gdb version that could be built with a toolchain that doesn't have
> C++11 support. But well, C++11 is there since gcc 4.8, so let's assume
> most sane people have moved their distribution to a version that has
> gcc 4.8 at least.
> 
> So on my side, green light to drop gdb 7.12.

 For gdb, does it actually make sense to keep multiple versions?

 Regards,
 Arnout

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Romain Naour]

Hi Arnout, All,

Le 26/06/2019 ? 00:25, Arnout Vandecappelle a ?crit?:
> 
> 
> On 23/06/2019 18:21, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Sun, 23 Jun 2019 00:35:38 +0200
>> Romain Naour <romain.naour@gmail.com> wrote:
>>
>>>> Arnout: do you still think gcc 4.9 is needed at this point ? If it is
>>>> the case, should we keep gcc 4.9, but drop gcc 5 and 6 ?  
>>>
>>> Currently glibc >= 2.29 needs gcc >= 5 on all architectures.
>>> So we can only build a toolchain with gcc 4.9 with uClibc and musl.
>>> The upcoming release of glibc will require at least gcc 6.2 on all architectures
>>> [1].
>>>
>>> If a toolchain with gcc 4.9 is really needed, it can be build with the 2019.02
>>> LTS version.
>>
>> So, Peter said for the next LTS (2020.02), we probably want to have
>> removed the oldest gcc versions (4.9, 5 and 6, most likely).
> 
>  Yes indeed, we can't keep 4.9 around indefinitely, so let's drop it and 5 and 6
> as well, leaving just the three most recent ones: 7, 8, 9.

Note: gcc 5 is still used by beaglebone_qt5_defconfig in order to test the SGX
PowerVR GPU using TI's sgx demo package.
This defconfig doesn't seems maintained for a long time (compared to
beaglebone_defconfig). I'm adding Lothar Felten in Cc.

Lothar: it would be great if you can have a look at this defconfig and try to
use gcc 8 (or at least gcc 7).

> 
> 
>>> Thomas, I have the same question about gdb 7.12.x.
>>
>> I think we should also drop it. I was keeping it because it was the
>> last gdb version that could be built with a toolchain that doesn't have
>> C++11 support. But well, C++11 is there since gcc 4.8, so let's assume
>> most sane people have moved their distribution to a version that has
>> gcc 4.8 at least.
>>
>> So on my side, green light to drop gdb 7.12.
> 
>  For gdb, does it actually make sense to keep multiple versions?

It would make the maintenance easier...

Best regards,
Romain

> 
>  Regards,
>  Arnout
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Thomas Petazzoni]

On Wed, 26 Jun 2019 08:55:00 +0200
Romain Naour <romain.naour@smile.fr> wrote:

> Note: gcc 5 is still used by beaglebone_qt5_defconfig in order to test the SGX
> PowerVR GPU using TI's sgx demo package.
> This defconfig doesn't seems maintained for a long time (compared to
> beaglebone_defconfig). I'm adding Lothar Felten in Cc.
> 
> Lothar: it would be great if you can have a look at this defconfig and try to
> use gcc 8 (or at least gcc 7).

Lothar did quite a bit of work on this, but we had the issue of the GBM
API, where I tried to do a virtual package, but it didn't work well,
Lothar did further experiments with Qt with GBM, and it worked, but I
never had the chance to have a look.

So, I wouldn't blame Lothar for not updating the defconfig here :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Romain Naour]

Hi Thomas,

Hi Thomas,

Le 26/06/2019 ? 09:23, Thomas Petazzoni a ?crit?:
> On Wed, 26 Jun 2019 08:55:00 +0200
> Romain Naour <romain.naour@smile.fr> wrote:
> 
>> Note: gcc 5 is still used by beaglebone_qt5_defconfig in order to test the SGX
>> PowerVR GPU using TI's sgx demo package.
>> This defconfig doesn't seems maintained for a long time (compared to
>> beaglebone_defconfig). I'm adding Lothar Felten in Cc.
>>
>> Lothar: it would be great if you can have a look at this defconfig and try to
>> use gcc 8 (or at least gcc 7).
> 
> Lothar did quite a bit of work on this, but we had the issue of the GBM
> API, where I tried to do a virtual package, but it didn't work well,
> Lothar did further experiments with Qt with GBM, and it worked, but I
> never had the chance to have a look.

I used git log for having the history on this defconfig, the drawback of this
method is I'm missing all work that is not merged yet.
I wasn't aware of Lothar's work, sorry.
> 
> So, I wouldn't blame Lothar for not updating the defconfig here :-)

I don't blame Lothar for not updating this defconfig, I understand working on
TI's SGX packages is difficult :)
My intention is to notify Lothar that we are going to remove gcc 5.x.

Best regards,
Romain

> 
> Best regards,
> 
> Thomas
> 

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Thomas Petazzoni]

On Wed, 26 Jun 2019 00:25:59 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:

> > So on my side, green light to drop gdb 7.12.  
> 
>  For gdb, does it actually make sense to keep multiple versions?

I think it made sense for gdb 7.12 vs. gdb >= 8.x, due to this C++11
requirement on the host.

But if we are going to remove 7.12, then indeed, it probably no longer
makes sense to have a version choice.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 08/15] package/gcc: switch to gcc 8.x as the default

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

Hi,

 > What do we do with the older gcc versions ? We now have 4.9, 5, 6, 7, 8
 > and 9, which is quite a bit more than the normal number of 3 versions
 > we want to support.

 > Arnout: do you still think gcc 4.9 is needed at this point ? If it is
 > the case, should we keep gcc 4.9, but drop gcc 5 and 6 ?

I know it is painful for people stuck on E.G. old bootloader/kernel
versions, but I think it makes sense to slowly remove these old gcc
versions, so E.G. by the time we release 2020.02 that we only support
gcc 7/8/9.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v4 09/15] arch/arm: move dependency on 64-bit down to individual cores

[Giulio Benetti]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

It will make it easier to introduce new variants anywhere in the
list, when those variants have different bitness requirements.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 arch/Config.in.arm | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 93031ab147..5557261604 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -376,50 +376,55 @@ config BR2_exynos_m1
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
-if BR2_ARCH_IS_64
 config BR2_falkor
 	bool "falkor"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
 config BR2_qdf24xx
 	bool "qdf24xx"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
 config BR2_thunderx
 	bool "thunderx"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
 config BR2_thunderxt81
 	bool "thunderxt81"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
 config BR2_thunderxt83
 	bool "thunderxt83"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
 config BR2_thunderxt88
 	bool "thunderxt88"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
 config BR2_thunderxt88p1
 	bool "thunderxt88p1"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
-endif # BR2_ARCH_IS_64
 config BR2_xgene1
 	bool "xgene1"
 	select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
@@ -430,59 +435,60 @@ config BR2_xgene1
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
 
-if BR2_ARCH_IS_64
 comment "armv8.1a cores"
 config BR2_thunderx2t99
 	bool "thunderx2t99"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
 config BR2_thunderx2t99p1
 	bool "thunderx2t99p1"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
 config BR2_vulcan
 	bool "vulcan"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
-endif # BR2_ARCH_IS_64
 
-if BR2_ARCH_IS_64
 comment "armv8.2a cores"
 config BR2_cortex_a55
 	bool "cortex-A55"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
 config BR2_cortex_a75
 	bool "cortex-A75"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
 config BR2_cortex_a75_a55
 	bool "cortex-A75/A55 big.LITTLE"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
-endif # BR2_ARCH_IS_64
 
-if BR2_ARCH_IS_64
 comment "armv8.3a cores"
 config BR2_saphira
 	bool "saphira"
+	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
-endif # BR2_ARCH_IS_64
 endchoice
 
 config BR2_ARM_ENABLE_NEON
-- 
2.17.1

[Buildroot] [PATCH v4 09/15] arch/arm: move dependency on 64-bit down to individual cores

[Arnout Vandecappelle]

On 20/06/2019 12:07, Giulio Benetti wrote:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> It will make it easier to introduce new variants anywhere in the
> list, when those variants have different bitness requirements.
> 
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>

 I've applied this and the rest of the series to master, thanks. With some small
modifications, noted in each individual patch.

 Regards,
 Arnout

[Buildroot] [PATCH v4 10/15] arch/arm: some cores have a different name with gcc-9

[Giulio Benetti]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

In gcc-9, some cores from the ThunderX familly have been renamed to
their marketting names, i.e. OcteonTX. Subsequently, new core names
have been added to gcc, with the old names still being around.

Update the prompts with the new names as alternative to the existing
names. We still keep the kconfig options as-is, so that we do not need
to add legacy handling.

However, since there is no guarantee for how long gcc will retain
compatibility for the older names, we readily switch over to using the
new names when using a gcc 9-or-later, but keep using the older names
with gcc older than 9.

The ordering of the 'default' clauses in kconfig is important, with the
first default which conditions is satisfied, to be used, so we just add
the new core names under a more liberal condition than the older names.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 arch/Config.in.arm | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 5557261604..e10d308767 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -391,21 +391,21 @@ config BR2_qdf24xx
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
 config BR2_thunderx
-	bool "thunderx"
+	bool "thunderx (aka octeontx)"
 	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
 config BR2_thunderxt81
-	bool "thunderxt81"
+	bool "thunderxt81 (aka octeontx81)"
 	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
 config BR2_thunderxt83
-	bool "thunderxt83"
+	bool "thunderxt83 (aka octeontx83)"
 	depends on BR2_ARCH_IS_64
 	select BR2_ARM_CPU_HAS_FP_ARMV8
 	select BR2_ARM_CPU_ARMV8A
@@ -824,9 +824,12 @@ config BR2_GCC_TARGET_CPU
 	default "exynos-m1"	if BR2_exynos_m1
 	default "falkor"	if BR2_falkor
 	default "qdf24xx"	if BR2_qdf24xx
-	default "thunderx"	if BR2_thunderx
-	default "thunderxt81"	if BR2_thunderxt81
-	default "thunderxt83"	if BR2_thunderxt83
+	default "thunderx"	if BR2_thunderx && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
+	default "octeontx"	if BR2_thunderx
+	default "thunderxt81"	if BR2_thunderxt81 && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
+	default "octeontx81"	if BR2_thunderxt81
+	default "thunderxt83"	if BR2_thunderxt83 && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
+	default "octeontx83"	if BR2_thunderxt83
 	default "thunderxt88"	if BR2_thunderxt88
 	default "thunderxt88p1"	if BR2_thunderxt88p1
 	default "xgene1"	if BR2_xgene1
-- 
2.17.1

[Buildroot] [PATCH v4 10/15] arch/arm: some cores have a different name with gcc-9

[Arnout Vandecappelle]

On 20/06/2019 12:07, Giulio Benetti wrote:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
[snip]
> The ordering of the 'default' clauses in kconfig is important, with the
> first default which conditions is satisfied, to be used, so we just add
> the new core names under a more liberal condition than the older names.

 This is not so readable / readily understandable, IMO. Therefore, I've changed
this into:

[snip]
> +	default "thunderx"	if BR2_thunderx && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
> +	default "octeontx"	if BR2_thunderx

	default "thunderx"	if BR2_thunderx && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
	default "octeontx"	if BR2_thunderx && BR2_TOOLCHAIN_GCC_AT_LEAST_9

etc.

 Regards,
 Arnout

> +	default "thunderxt81"	if BR2_thunderxt81 && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
> +	default "octeontx81"	if BR2_thunderxt81
> +	default "thunderxt83"	if BR2_thunderxt83 && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
> +	default "octeontx83"	if BR2_thunderxt83
>  	default "thunderxt88"	if BR2_thunderxt88
>  	default "thunderxt88p1"	if BR2_thunderxt88p1
>  	default "xgene1"	if BR2_xgene1
> 

[Buildroot] [PATCH v4 10/15] arch/arm: some cores have a different name with gcc-9

[Yann E. MORIN]

Arnout, All,

Thanks for eventually applying the series. :-)

On 2019-07-13 23:13 +0200, Arnout Vandecappelle spake thusly:
> On 20/06/2019 12:07, Giulio Benetti wrote:
> > From: "Yann E. MORIN" <yann.morin.1998@free.fr>
> [snip]
> > The ordering of the 'default' clauses in kconfig is important, with the
> > first default which conditions is satisfied, to be used, so we just add
> > the new core names under a more liberal condition than the older names.
> 
>  This is not so readable / readily understandable, IMO. Therefore, I've changed
> this into:

We depend on the default ordering in other places as well.

> [snip]
> > +	default "thunderx"	if BR2_thunderx && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
> > +	default "octeontx"	if BR2_thunderx
> 
> 	default "thunderx"	if BR2_thunderx && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
> 	default "octeontx"	if BR2_thunderx && BR2_TOOLCHAIN_GCC_AT_LEAST_9

You and I reallt have a differnt way toi see things, because I find this
less readable now...

But oh well...

Thanks for applying anyway. :-)

Regards,
Yann E. MORIN.

> etc.
> 
>  Regards,
>  Arnout
> 
> > +	default "thunderxt81"	if BR2_thunderxt81 && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
> > +	default "octeontx81"	if BR2_thunderxt81
> > +	default "thunderxt83"	if BR2_thunderxt83 && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
> > +	default "octeontx83"	if BR2_thunderxt83
> >  	default "thunderxt88"	if BR2_thunderxt88
> >  	default "thunderxt88p1"	if BR2_thunderxt88p1
> >  	default "xgene1"	if BR2_xgene1
> > 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v4 11/15] arch/arm: saphira is in fact an armv8.4a

[Giulio Benetti]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

... and not an armv8.3a like previously supposed:
    https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=886d991373e4dc5a746d0a33de64f1b36e61eed9

So, change the correspoding labels and comments.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 arch/Config.in.arm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index e10d308767..113b83a738 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -481,7 +481,7 @@ config BR2_cortex_a75_a55
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
 
-comment "armv8.3a cores"
+comment "armv8.4a cores"
 config BR2_saphira
 	bool "saphira"
 	depends on BR2_ARCH_IS_64
@@ -841,7 +841,7 @@ config BR2_GCC_TARGET_CPU
 	default "cortex-a55"	if BR2_cortex_a55
 	default "cortex-a75"	if BR2_cortex_a75
 	default "cortex-a75.cortex-a55"	if BR2_cortex_a75_a55
-	# armv8.3a
+	# armv8.4a
 	default "saphira"	if BR2_saphira
 
 config BR2_GCC_TARGET_ABI
-- 
2.17.1

[Buildroot] [PATCH v4 12/15] arch/arm: add two new 64-bit-only armv8a cores

[Giulio Benetti]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

Build tested:
https://gitlab.com/kubu93/buildroot/pipelines/60318953

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 arch/Config.in.arm | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 113b83a738..4685b72510 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -367,6 +367,13 @@ config BR2_cortex_a73_a53
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
+config BR2_emag
+	bool "emag"
+	depends on BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_FP_ARMV8
+	select BR2_ARM_CPU_ARMV8A
+	select BR2_ARCH_HAS_MMU_OPTIONAL
+	select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
 config BR2_exynos_m1
 	bool "exynos-m1"
 	select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
@@ -383,6 +390,13 @@ config BR2_falkor
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
+config BR2_phecda
+	bool "phecda"
+	depends on BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_FP_ARMV8
+	select BR2_ARM_CPU_ARMV8A
+	select BR2_ARCH_HAS_MMU_OPTIONAL
+	select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
 config BR2_qdf24xx
 	bool "qdf24xx"
 	depends on BR2_ARCH_IS_64
@@ -821,8 +835,10 @@ config BR2_GCC_TARGET_CPU
 	default "cortex-a73"	if BR2_cortex_a73
 	default "cortex-a73.cortex-a35"	if BR2_cortex_a73_a35
 	default "cortex-a73.cortex-a53"	if BR2_cortex_a73_a53
+	default "emag"		if BR2_emag
 	default "exynos-m1"	if BR2_exynos_m1
 	default "falkor"	if BR2_falkor
+	default "phecda"	if BR2_phecda
 	default "qdf24xx"	if BR2_qdf24xx
 	default "thunderx"	if BR2_thunderx && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
 	default "octeontx"	if BR2_thunderx
-- 
2.17.1

[Buildroot] [PATCH v4 13/15] arch/arm: add two new cortex-based armv8.2a cores

[Giulio Benetti]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

The cortex-a76 implements the full amrv8.2a extensions, and some
optional extensions from the armv8.3a, armv8.4a, and armv8.5a sets,
but none of their mandatory extensions, which means that it does not
qualify for better than an armv8.2a:
    https://developer.arm.com/products/processors/cortex-a/cortex-a76
    http://infocenter.arm.com/help/topic/com.arm.doc.100798_0301_00_en/giq1479805174793.html
    http://infocenter.arm.com/help/topic/com.arm.doc.100798_0301_00_en/fjv1477559794375.html

Also, gcc fits it in the armv8.2a category, too:
    https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;h=67ce42fb8aacd4c246295f32151a03b1f318ae44;hb=HEAD#l97

Build tested:
https://gitlab.com/kubu93/buildroot/pipelines/60318953

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 arch/Config.in.arm | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 4685b72510..a664cfe0e2 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -494,6 +494,24 @@ config BR2_cortex_a75_a55
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
+config BR2_cortex_a76
+	bool "cortex-A76"
+	select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_FP_ARMV8
+	select BR2_ARM_CPU_ARMV8A
+	select BR2_ARCH_HAS_MMU_OPTIONAL
+	select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
+config BR2_cortex_a76_a55
+	bool "cortex-A76/A55 big.LITTLE"
+	select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_FP_ARMV8
+	select BR2_ARM_CPU_ARMV8A
+	select BR2_ARCH_HAS_MMU_OPTIONAL
+	select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
 
 comment "armv8.4a cores"
 config BR2_saphira
@@ -857,6 +875,8 @@ config BR2_GCC_TARGET_CPU
 	default "cortex-a55"	if BR2_cortex_a55
 	default "cortex-a75"	if BR2_cortex_a75
 	default "cortex-a75.cortex-a55"	if BR2_cortex_a75_a55
+	default "cortex-a76"	if BR2_cortex_a76
+	default "cortex-a76.cortex-a55"	if BR2_cortex_a76_a55
 	# armv8.4a
 	default "saphira"	if BR2_saphira
 
-- 
2.17.1

[Buildroot] [PATCH v4 14/15] arch/arm: add two new non-cortex-based armv8.2a cores

[Giulio Benetti]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

The Neoverse N1 CPU was supported in GCC earlier through the codename Ares [1].

[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=37cf0ddecfd1eb5c6852a44135af5a92e5103931

Build tested:
https://gitlab.com/kubu93/buildroot/pipelines/60318953

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Romain: rename BR2_ares to BR2_neoverse_n1]
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
v2: add neoverse-e1 (Yann)
    reorder alphabetically after renaming ares to neoverse-n1.

Note: The Neoverse E1 CPU needs at least binutils 2.32 to support Speculative Store
Bypass Safe instruction (SSBS) which is part of ARMv8.5-A architecture extensions.
Postpone the support for this new ARM core.
See: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=104fefeebb544b7745bb353b63110afa46119647
---
 arch/Config.in.arm | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index a664cfe0e2..eea77cdabe 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -512,6 +512,22 @@ config BR2_cortex_a76_a55
 	select BR2_ARM_CPU_ARMV8A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 	select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
+config BR2_neoverse_n1
+	bool "neoverse-N1 (alias ares)"
+	select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_FP_ARMV8
+	select BR2_ARM_CPU_ARMV8A
+	select BR2_ARCH_HAS_MMU_OPTIONAL
+	select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
+config BR2_tsv110
+	bool "tsv110"
+	depends on BR2_ARCH_IS_64
+	select BR2_ARM_CPU_HAS_FP_ARMV8
+	select BR2_ARM_CPU_ARMV8A
+	select BR2_ARCH_HAS_MMU_OPTIONAL
+	select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
 
 comment "armv8.4a cores"
 config BR2_saphira
@@ -877,6 +893,8 @@ config BR2_GCC_TARGET_CPU
 	default "cortex-a75.cortex-a55"	if BR2_cortex_a75_a55
 	default "cortex-a76"	if BR2_cortex_a76
 	default "cortex-a76.cortex-a55"	if BR2_cortex_a76_a55
+	default "neoverse-n1"	if BR2_neoverse_n1
+	default "tsv110"	if BR2_tsv110
 	# armv8.4a
 	default "saphira"	if BR2_saphira
 
-- 
2.17.1

[Buildroot] [PATCH v4 14/15] arch/arm: add two new non-cortex-based armv8.2a cores

[Arnout Vandecappelle]

On 20/06/2019 12:07, Giulio Benetti wrote:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> The Neoverse N1 CPU was supported in GCC earlier through the codename Ares [1].
> 
> [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=37cf0ddecfd1eb5c6852a44135af5a92e5103931
> 
> Build tested:
> https://gitlab.com/kubu93/buildroot/pipelines/60318953
> 
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> [Romain: rename BR2_ares to BR2_neoverse_n1]
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
> v2: add neoverse-e1 (Yann)
>     reorder alphabetically after renaming ares to neoverse-n1.
> 
> Note: The Neoverse E1 CPU needs at least binutils 2.32 to support Speculative Store
> Bypass Safe instruction (SSBS) which is part of ARMv8.5-A architecture extensions.
> Postpone the support for this new ARM core.
> See: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=104fefeebb544b7745bb353b63110afa46119647
> ---
>  arch/Config.in.arm | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index a664cfe0e2..eea77cdabe 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -512,6 +512,22 @@ config BR2_cortex_a76_a55
>  	select BR2_ARM_CPU_ARMV8A
>  	select BR2_ARCH_HAS_MMU_OPTIONAL
>  	select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
> +config BR2_neoverse_n1
> +	bool "neoverse-N1 (alias ares)"

 In an earlier patch, you used 'aka', so I did the same here.

> +	select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
> +	select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
> +	select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
> +	select BR2_ARM_CPU_HAS_FP_ARMV8
> +	select BR2_ARM_CPU_ARMV8A
> +	select BR2_ARCH_HAS_MMU_OPTIONAL
> +	select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
> +config BR2_tsv110
> +	bool "tsv110"
> +	depends on BR2_ARCH_IS_64
> +	select BR2_ARM_CPU_HAS_FP_ARMV8
> +	select BR2_ARM_CPU_ARMV8A
> +	select BR2_ARCH_HAS_MMU_OPTIONAL

 Somewhat unrelated to this patch, but: is this really correct? I thought the
MMU was mandatory on 64-bit ARM. At least, the kernel forces MMU on for arm64.

 Regards,
 Arnout

> +	select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
>  
>  comment "armv8.4a cores"
>  config BR2_saphira
> @@ -877,6 +893,8 @@ config BR2_GCC_TARGET_CPU
>  	default "cortex-a75.cortex-a55"	if BR2_cortex_a75_a55
>  	default "cortex-a76"	if BR2_cortex_a76
>  	default "cortex-a76.cortex-a55"	if BR2_cortex_a76_a55
> +	default "neoverse-n1"	if BR2_neoverse_n1
> +	default "tsv110"	if BR2_tsv110
>  	# armv8.4a
>  	default "saphira"	if BR2_saphira
>  
> 

[Buildroot] [PATCH v4 14/15] arch/arm: add two new non-cortex-based armv8.2a cores

[Yann E. MORIN]

Arnout, All,

On 2019-07-13 23:22 +0200, Arnout Vandecappelle spake thusly:
> On 20/06/2019 12:07, Giulio Benetti wrote:
> > From: "Yann E. MORIN" <yann.morin.1998@free.fr>
[--SNIP--]
> > +config BR2_tsv110
> > +	bool "tsv110"
> > +	depends on BR2_ARCH_IS_64
> > +	select BR2_ARM_CPU_HAS_FP_ARMV8
> > +	select BR2_ARM_CPU_ARMV8A
> > +	select BR2_ARCH_HAS_MMU_OPTIONAL
>  Somewhat unrelated to this patch, but: is this really correct? I thought the
> MMU was mandatory on 64-bit ARM. At least, the kernel forces MMU on for arm64.

TBH, I don't know. I stupidly replicated the settings from the other
existing AArch64 cores we already had in the list.

Thanks!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1 (openrisc)

[Giulio Benetti]

From: Romain Naour <romain.naour@gmail.com>

openrisc support has been added with gcc 9.1.
Keep for now the old gcc 5 fork for ork1.

https://gcc.gnu.org/gcc-9/changes.html

Tested using qemu_or1k_defconfig.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
v3: rebase patch on top of master branch sha1:
    04efb17c863606cdbc2405d01c3d48d6868c5245 (Giulio)
---
 package/gcc/Config.in.host | 2 --
 package/gcc/gcc.mk         | 4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
index 15f1e8f06a..80129ae2ef 100644
--- a/package/gcc/Config.in.host
+++ b/package/gcc/Config.in.host
@@ -86,8 +86,6 @@ config BR2_GCC_VERSION_8_X
 
 config BR2_GCC_VERSION_9_X
 	bool "gcc 9.x"
-	# Broken or unsupported architectures
-	depends on !BR2_or1k
 	select BR2_TOOLCHAIN_GCC_AT_LEAST_9
 
 endchoice
diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index abc29c7df0..46ad16df13 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -13,7 +13,7 @@ GCC_VERSION = $(call qstrip,$(BR2_GCC_VERSION))
 ifeq ($(BR2_GCC_VERSION_ARC),y)
 GCC_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,gcc,$(GCC_VERSION))
 GCC_SOURCE = gcc-$(GCC_VERSION).tar.gz
-else ifeq ($(BR2_or1k),y)
+else ifeq ($(BR2_GCC_VERSION_OR1K),y)
 GCC_SITE = $(call github,openrisc,or1k-gcc,$(GCC_VERSION))
 GCC_SOURCE = gcc-$(GCC_VERSION).tar.gz
 else ifeq ($(BR2_csky),y)
@@ -180,7 +180,7 @@ else
 HOST_GCC_COMMON_CONF_OPTS += --without-isl --without-cloog
 endif
 
-ifeq ($(BR2_arc)$(BR2_or1k),y)
+ifeq ($(BR2_arc)$(BR2_GCC_VERSION_OR1K),y)
 HOST_GCC_COMMON_DEPENDENCIES += host-flex host-bison
 endif
 
-- 
2.17.1

[Buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1 (openrisc)

[Arnout Vandecappelle]

On 20/06/2019 12:07, Giulio Benetti wrote:
> openrisc support has been added with gcc 9.1.
> Keep for now the old gcc 5 fork for ork1.

 So, when will we remove this?

 Same for ARC (GCC 8.x fork) and C-SKY (GCC 6.x fork): they are available in
GCC9, do we need to keep those old forks?

 Regards,
 Arnout

[Buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1 (openrisc)

[Guo Ren]

On Sun, Jul 14, 2019 at 5:24 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 20/06/2019 12:07, Giulio Benetti wrote:
> > openrisc support has been added with gcc 9.1.
> > Keep for now the old gcc 5 fork for ork1.
>
>  So, when will we remove this?
>
>  Same for ARC (GCC 8.x fork) and C-SKY (GCC 6.x fork): they are available in
> GCC9, do we need to keep those old forks?
Keep the fork for C-SKY, the upstream of csky backend in gcc9 only
support abiv2.

>
>  Regards,
>  Arnout
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

[Buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1 (openrisc)

[Yann E. MORIN]

Guo, All,

On 2019-07-14 07:57 +0800, Guo Ren spake thusly:
> On Sun, Jul 14, 2019 at 5:24 AM Arnout Vandecappelle <arnout@mind.be> wrote:
> > On 20/06/2019 12:07, Giulio Benetti wrote:
> > > openrisc support has been added with gcc 9.1.
> > > Keep for now the old gcc 5 fork for ork1.
> >  So, when will we remove this?
> >  Same for ARC (GCC 8.x fork) and C-SKY (GCC 6.x fork): they are available in
> > GCC9, do we need to keep those old forks?
> Keep the fork for C-SKY, the upstream of csky backend in gcc9 only
> support abiv2.

As far as I can see, we have no way to choose the ABI in Buildroot.
So, what would we loose by keeping only gcc-9?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1 (openrisc)

[Guo Ren]

On Sun, Jul 14, 2019 at 4:41 PM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> Guo, All,
>
> On 2019-07-14 07:57 +0800, Guo Ren spake thusly:
> > On Sun, Jul 14, 2019 at 5:24 AM Arnout Vandecappelle <arnout@mind.be> wrote:
> > > On 20/06/2019 12:07, Giulio Benetti wrote:
> > > > openrisc support has been added with gcc 9.1.
> > > > Keep for now the old gcc 5 fork for ork1.
> > >  So, when will we remove this?
> > >  Same for ARC (GCC 8.x fork) and C-SKY (GCC 6.x fork): they are available in
> > > GCC9, do we need to keep those old forks?
> > Keep the fork for C-SKY, the upstream of csky backend in gcc9 only
> > support abiv2.
>
> As far as I can see, we have no way to choose the ABI in Buildroot.
> So, what would we loose by keeping only gcc-9?
See package/Makefile.in

# For C-SKY abiv1 & abiv2
ifeq ($(BR2_csky),y)
ifeq ($(BR2_ck610),y)
ABI = abiv1
else
ABI = abiv2
endif
endif

gcc-9 don't support 610.


-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

[Buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1 (openrisc)

[Yann E. MORIN]

Guo, All,

Peter, Thomas, Arnout, question below...

On 2019-07-14 17:18 +0800, Guo Ren spake thusly:
> On Sun, Jul 14, 2019 at 4:41 PM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > On 2019-07-14 07:57 +0800, Guo Ren spake thusly:
> > > On Sun, Jul 14, 2019 at 5:24 AM Arnout Vandecappelle <arnout@mind.be> wrote:
> > > > On 20/06/2019 12:07, Giulio Benetti wrote:
> > > > > openrisc support has been added with gcc 9.1.
> > > > > Keep for now the old gcc 5 fork for ork1.
> > > >  So, when will we remove this?
> > > >  Same for ARC (GCC 8.x fork) and C-SKY (GCC 6.x fork): they are available in
> > > > GCC9, do we need to keep those old forks?
> > > Keep the fork for C-SKY, the upstream of csky backend in gcc9 only
> > > support abiv2.
> > As far as I can see, we have no way to choose the ABI in Buildroot.
> > So, what would we loose by keeping only gcc-9?
> See package/Makefile.in
> 
> # For C-SKY abiv1 & abiv2
> ifeq ($(BR2_csky),y)
> ifeq ($(BR2_ck610),y)
> ABI = abiv1
> else
> ABI = abiv2
> endif
> endif

Ah, thanks for pointing this out. I only had a look at arch/arch.mk.csky
and arch/Config.in.csky.

This makes me wonder: should we move all this out of package/Makefile.in
and into the per-arch .mk files instead?

> gcc-9 don't support 610.

There is currently nothign in Buildroot that prevents selecting gcc9 for
the ck610...

> 
> -- 
> Best Regards
>  Guo Ren
> 
> ML: https://lore.kernel.org/linux-csky/

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1 (openrisc)

[Thomas Petazzoni]

On Sun, 14 Jul 2019 11:39:16 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> > # For C-SKY abiv1 & abiv2
> > ifeq ($(BR2_csky),y)
> > ifeq ($(BR2_ck610),y)
> > ABI = abiv1
> > else
> > ABI = abiv2
> > endif
> > endif  
> 
> Ah, thanks for pointing this out. I only had a look at arch/arch.mk.csky
> and arch/Config.in.csky.
> 
> This makes me wonder: should we move all this out of package/Makefile.in
> and into the per-arch .mk files instead?

Yes, I also thought about that when I merged Guo's patches for C-SKY.
But other architectures already have stuff in package/Makefile.in, so
it required a larger rework, which I didn't want to put as a
pre-requisite to merging Guo's patches.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1 (openrisc)

[Yann E. MORIN]

Thomas, All,

On 2019-07-14 12:00 +0200, Thomas Petazzoni spake thusly:
> On Sun, 14 Jul 2019 11:39:16 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
[--SNIP--]
> > This makes me wonder: should we move all this out of package/Makefile.in
> > and into the per-arch .mk files instead?
> Yes, I also thought about that when I merged Guo's patches for C-SKY.
> But other architectures already have stuff in package/Makefile.in, so
> it required a larger rework, which I didn't want to put as a
> pre-requisite to merging Guo's patches.

Exactly, it's OK that it was merged as-is.

But now that we have seen The Light, should we folow Its path and move
arch-specific stuff into arch/arch.mk.* instead?

Especially with the still-pending mini-series for ARC:
    https://patchwork.ozlabs.org/patch/1108865/
    https://patchwork.ozlabs.org/patch/1108864/

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1 (openrisc)

[Romain Naour]

Hi Arnout, All,

Le 13/07/2019 ? 23:24, Arnout Vandecappelle a ?crit?:
> 
> 
> On 20/06/2019 12:07, Giulio Benetti wrote:
>> openrisc support has been added with gcc 9.1.
>> Keep for now the old gcc 5 fork for ork1.
> 
>  So, when will we remove this?

Adding Waldemar in Cc.

Waldemar, I tested gcc 9.1 ork1 backend using qemu_or1k_defconfig, it's ok to
remove the old gcc 5 fork ?
At least, we can remove this fork while removing gcc 5 for the internal toolchain.

> 
>  Same for ARC (GCC 8.x fork) and C-SKY (GCC 6.x fork): they are available in
> GCC9, do we need to keep those old forks?

For ARC and C-SKY we have architectures maintainer, I'll let them remove these
gcc fork.

Best regards,
Romain

> 
>  Regards,
>  Arnout
> 

[Buildroot] [arc-buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1 (openrisc)

[Alexey Brodkin]

Hi Arnout, all,

> -----Original Message-----
> From: Arnout Vandecappelle <arnout@mind.be>
> Sent: Sunday, July 14, 2019 12:24 AM
> To: Giulio Benetti <giulio.benetti@micronovasrl.com>; buildroot at buildroot.org; arc-
> buildroot at synopsys.com; Guo Ren <ren_guo@c-sky.com>
> Cc: Yann E . MORIN <yann.morin.1998@free.fr>; Thomas Petazzoni <thomas.petazzoni@bootlin.com>; Romain
> Naour <romain.naour@gmail.com>; Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
> Subject: Re: [arc-buildroot] [Buildroot] [PATCH v4 15/15] package/gcc: enable gcc 9.1 for ork1
> (openrisc)
> 
> 
> 
> On 20/06/2019 12:07, Giulio Benetti wrote:
> > openrisc support has been added with gcc 9.1.
> > Keep for now the old gcc 5 fork for ork1.
> 
>  So, when will we remove this?
> 
>  Same for ARC (GCC 8.x fork) and C-SKY (GCC 6.x fork): they are available in
> GCC9, do we need to keep those old forks?

ARC support in GCC 9.x & Binutils 2.32 is very solid so we may even try to use it by default for ARC.

As for arc-xxxx.yy forks I'd like to keep them for a couple of future BR releases
and if we see that vanilla GCC/Binutils work really good then forks may go avay.

Make sense?

-Alexey