linux/poky.git/meta/recipes-devtools/gcc/gcc-target.inc, branch hardknott

gcc: Package new module mapper tool

2021-03-14T16:33:59+00:00

This is new tool in GCC 11 [1] [1] https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Module-Mapper.html (From OE-Core rev: 91e1b8f84471fda3d5173a5ab2fe9458f9233007) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc10: Update to GCC 10.1 Release

2020-05-14T13:15:11+00:00

* Package new gomp header acc_prof.h * Package lto-dump which is a new tool in gcc10 * All Changes are here [1] * Porting apps to gcc 10 help is here [2] * Backport a patch to fix CET errors on cross builds * Add patch to fix mingw libstdc++ [1] https://gcc.gnu.org/gcc-10/changes.html [2] https://gcc.gnu.org/gcc-10/porting_to.html (From OE-Core rev: 44c3881b18f74eb64379818fc150f94398fb8a49) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-target: Ensure buildtools-extended-tarball doesn't use arch=native

2020-05-02T08:08:52+00:00

A nativesdk BBCLASSEXTEND was added to gcc-target without realising this would pass arch=native through to it for x86-64. This heavily optimises gcc output for the host its running on meaning it can't be reused via sstate on other machines. Add class-target overrides here to get the desired behaviour. All targets have been covered for completeness. (From OE-Core rev: d0d4853dd773f7bbe0f72e50144559b80e80d67a) Signed-off-by: Richard Purdie

gcc: Configure all gccs with --disable-install-libiberty

2020-04-26T13:00:50+00:00

OE uses libiberty from binutils, since its properly compiled as pic archive and applications and other libraries needing libiberty can properly link with it. With this option applied, explicit delete of libiberty headers and libraries is not required in install step, since they wont get installed in first place. (From OE-Core rev: fa8a205c69770d23323c9a06373db958af4b34d3) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-target: Use --with-arch=native for target gcc

2020-03-21T22:39:01+00:00

This should help gcc detect and use target ISA on x86_64 machines when -march is not used on cmdline [YOCTO #139] (From OE-Core rev: f9e410521c92e2458ba7e2ca63d28434618b9f25) Signed-off-by: Khem Raj Cc: Ross Burton Signed-off-by: Richard Purdie

gcc: don't ship build host information in the target gcc-plugins package

2020-03-11T13:44:02+00:00

The build host configuration isn't reproducible as it varies depending on the gcc version of the build host. This information isn't useful on the target anyway so remove it. (From OE-Core rev: f9154b2c3eff8434914710ab453e13cf338597ec) Signed-off-by: Richard Purdie

gcc: Improve build reproduciblity

2019-12-06T14:41:28+00:00

Prevent the gcc embedded checksum from containing a checksum that was computed with build specific paths. The checksum-options file included the value of LINKER/LDFLAGS which contains DEBUG_PREFIX_MAP and STAGING_DIR_TARGET. (From OE-Core rev: 0ead8cbdfb96c4fcbefd24c6647d0f50599f45b3) Signed-off-by: Nathan Rossi Signed-off-by: Richard Purdie

gcc-target.inc: Prevent sysroot from leaking into configargs.h

2019-12-06T14:41:28+00:00

Prevent the full recipe-sysroot path from leaking into configargs.h. The configargs.h header is intended to be static and unchanged as the content is used as a means of determining that a gcc plugin is built for the same gcc. This also effects the output of 'gcc -v'. Due to per recipe sysroots and staging, the sysroot path would be replaced with the sysroot local to the recipe thus changing the content of configargs.h. This change also improves gcc binary reproducibility. The sysroot path is replaced with the base target root "/". (From OE-Core rev: b8d6e2ab68ee5e341fe970b191bfd334e6d2c40b) Signed-off-by: Nathan Rossi Signed-off-by: Richard Purdie

gcc-target: Do not set --with-sysroot and gxx-include-dir paths

2019-05-08T11:15:17+00:00

These options are not needed on target infact since the defaults would be good enough for compiler to find the relevant headers and libraries from compiler runtime with gcc9 it starts to strip the sysroot from gxx-include-dir which means it tries to look for gxx headers in localdir ignoring nonexistent directory "usr/include/c++/9.0.1" ignoring nonexistent directory "usr/include/c++/9.0.1/arm-yoe-linux-gnueabi" ignoring nonexistent directory "usr/include/c++/9.0.1/backward" instead of sysroot Removing these options make it behave normal (From OE-Core rev: 2996640fb3577a3c28a22f1e25eae15e8e3d46b1) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc: Select proper ARC CPU when build for target

2018-11-23T23:35:18+00:00

By default GCC for ARC is configured with ARC700 CPU. This means when we don't pass "-mcpu=xxx": a) Code will be compiled for ARC700 b) Libs will used for ARC700 And if we happen to run on ARCv2 core like ARC HSxx we won't be able to use target gcc w/o "-mcpu=xxx" which is not very convenient as we want to build "target" toolchain but not canadian-cross. Note the trick here is we set TUNE_PKGARCH in just 2 values, it is either "arc700" for all ARCompact cores (ARC750 & ARC770) and "archs" for all ARCv2 cores (ARC HS38 & HS48), see [1]. This gives us usable defaults. For cross-compilation we use TUNE_CCARGS for fine-tuning depending on which HW features we have on the current target so that we may have HW feature A & B or B & C or A & B & C, see [2]. [1] https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/master/conf/machine/include/tune-arcv2.inc#L4 [2] https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/master/conf/machine/include/tune-arcv2.inc#L34 (From OE-Core rev: 6d2e44db7ebada41ad1cfc1c98ce9012242ced11) Signed-off-by: Alexey Brodkin Signed-off-by: Richard Purdie