linux/poky.git/meta/recipes-devtools/gcc, branch gatesgarth

gcc-sanitizers: Move content from gcclibdir into libdir

2021-03-28T21:31:55+00:00

In e9e5744ba8b0d43c8b874d365f83071ce20bf0a1, Khem Raj wrote: > OE does not use the traditional /usr/lib/gcc prefix to store > gcc-runtime it basically is moved into libdir, however some newer > files were installed by newer versions of gcc especially libgomp ( > omp.h openacc.h ) into gcclibdir, so we have content in both > directories, this confuses other tools which are trying to guess the > gcc installation and its runtime location, since now we have two > directories, the tools either choose one or other and we get > inconsistent behavior, e.g. clang for aarch64 uses /usr/lib but same > clang for riscv64 chose /usr/lib/gcc > This change ensures that OE ends up with single valid location for gcc > runtime files I think that the same thing needs to happen in gcc-sanitizers.inc, otherwise I get errors like: | .../recipe-sysroot/usr/include/gpg-error-64.h:884:11: fatal error: sanitizer/lsan_interface.h: No such file or directory when attempting to compile with sanitizers enabled. FILES_${PN} needs updating to match too. (From OE-Core rev: 6b9e85e48ba43be74d51c7af703ba787f36e3241) Signed-off-by: Mike Crowe Cc: Khem Raj Cc: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 862b4fac3ee7d951758c8c93462331ad52bf0190) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

gcc: Backport patch to resolve i*86 tune configuration overrides

2021-01-27T09:32:45+00:00

Upstream has merged a change to handle detection of target overrides so that they are only applied as required. Backport this patch from upstream and remove the OE specific patch. (From OE-Core rev: ef87c3609ecf93158685f4d4cdc53754a6102330) Signed-off-by: Nathan Rossi Signed-off-by: Richard Purdie (cherry picked from commit d430f425e1a5725e93833a652e5c6988576f7347) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

gcc: Add patch to resolve i*86 tune configuration overrides

2021-01-04T11:45:47+00:00

When compiling gcc-runtime for i686 libatomic, libgomp and libitm are compiled with additional '-march' and '-mtune' overrides. This typically does not cause build errors (e.g. core2-32 tune), and results in less optimally tuned outputs. However with specific TUNE_CCARGS (e.g. has '-mfpmath=sse' but not '-msse*'), the build errors with conflicting '-mfpmath' options. This is caused by gcc-runtime specific configure scripts and Makefile options that override by adding additional '-march'/'-mtune' args. OE builds gcc-runtime differently to other build systems, and provides target specific arch/tune options directly. As such, this change adds a patch for gcc to remove the specific cases where the args are added. (From OE-Core rev: 5ce0102ca75754f0a7c777505678677cdf2a62bc) Signed-off-by: Nathan Rossi Signed-off-by: Richard Purdie (cherry picked from commit d39b686cc5fcc89405ffeb560ea64b5d305b0608) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

gcc10: Don't default back to -fcommon

2020-08-26T13:33:57+00:00

It has been almost 3 months since the upgrade to gcc 10. Switch back to relying on gcc default configuration (-fno-common). This reverts OE-Core commit 951e859b1e8297970278c539e989b8a6d06a9cb3. (From OE-Core rev: 4ee733e1551d3960a23a600eb71a01cf7a51fa06) Signed-off-by: Jacob Kroon Signed-off-by: Richard Purdie

gcc-cross-canadian: Install gcc/g++ wrappers for musl

2020-08-22T14:46:55+00:00

gcc needs -mmusl option to be passed in SDK since we ship crossdk compiler configured for glibc by default, this helps in creating correct compiler defaults for musl based SDK compilers [YOCTO #13459] (From OE-Core rev: e6fbac7aeabe00d8fb734992012dd629a8527b25) Signed-off-by: Khem Raj Cc: Leon Woestenberg Signed-off-by: Richard Purdie

gcc-cross-canadian: Correct the regexp to delete versioned gcc binary

2020-08-21T13:29:10+00:00

After gcc 10 this expression needed to be adjusted, its better to use a bitbake variable which we do have readily available (From OE-Core rev: ee2beaff701d02736c8244ebc76f6d6ca96a04f4) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc: Upgrade to 10.2.0

2020-08-18T10:44:55+00:00

Drop 0036-Enable-CET-in-cross-compiler-if-possible.patch and pr96130.patch they are already in 10.2 (From OE-Core rev: 35eda14fbdc38ae5e686c2d30a2c1d5569bd3088) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-runtime.inc: fix m32 compile fail with x86-64 compiler

2020-08-15T10:44:20+00:00

configuration: MACHINE ??= "qemux86-64" require conf/multilib.conf MULTILIBS ?= "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 ?= "core2-32" IMAGE_INSTALL_append = " packagegroup-core-buildessential lib32-libstdc++ lib32-libstdc++-dev" m32 compile failed on target: cmd: gcc -m32 -v test.cpp -o test output: GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=29590 ignoring nonexistent directory "/usr/lib64/gcc/x86_64-poky-linux/10.1.0/../../../../include/c++/10.1.0/x86_64-poky-linux/32" ignoring nonexistent directory "/usr/lib64/x86_64-poky-linux/10.1.0/include" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib64/gcc/x86_64-poky-linux/10.1.0/../../../../x86_64-poky-linux/include" /usr/lib64/gcc/x86_64-poky-linux/10.1.0/../../../../include/c++/10.1.0 /usr/lib64/gcc/x86_64-poky-linux/10.1.0/../../../../include/c++/10.1.0/backward /usr/lib64/gcc/x86_64-poky-linux/10.1.0/include /usr/lib64/gcc/x86_64-poky-linux/10.1.0/include-fixed /usr/include End of search list. GNU C++14 (GCC) version 10.1.0 (x86_64-poky-linux) compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=29590 Compiler executable checksum: bc3b2f3a33dad80e30112cf1235bf631 In file included from test.cpp:1: /usr/include/c++/10.1.0/iostream:38:10: fatal error: bits/c++config.h: No such file or directory 38 | #include | ^~~~~~~~~~~~~~~~~~ cannot find header since /usr/lib64/gcc/x86_64-poky-linux/10.1.0/x86_64-poky-linux/32 is missing fixed by link it to ../i686-poky-linux (From OE-Core rev: 509022ea8db314dd9d010a478fd84d0234905c6b) Signed-off-by: Changqing Li Signed-off-by: Richard Purdie

gcc: backport a fix for out-of-line atomics on aarch64

2020-08-12T09:51:46+00:00

(From OE-Core rev: ce99eb6b042cb36f5c07461fff7f49719550a955) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

gcc: Fix mangled patch

2020-07-28T11:39:54+00:00

To quote Zhuang : """ A few days ago, I tried to compile a gcc plugin with the toolchain from poky sdk. It failed with errors about missing header files such as backend.h etc. After investigation, I found that the problem was brought by a gcc patch: 0012-gcc-Fix-argument-list-too-long-error.patch (which is considered derived from the original patch) - headers=`echo $(PLUGIN_HEADERS) $$(cd $(srcdir); echo *.h *.def) | tr ' ' '\012' | sort -u`; \ + headers="$(sort $(PLUGIN_HEADERS) $$(cd $(srcdir); echo *.h *.def))"; \ It changes the commands of install-plugin, making the sorting taken effect before the shell globs. Thus results in the header files under gcc $(srcdir) being not installed. By checking log.do_install, we can find that the `headers=' statement to run is incorrect and will not work as expected: headers="$(cd *.def) *.h ../../../../../../../work-shared/gcc-10.1.0-r0/gcc-10.1.0/gcc/../include/ansidecl.h ... As the patch says, "The PLUGIN_HEADERS is too long before sort, so the "echo" can't handle it, ..." my suggestion is that we can simply take care of PLUGIN_HEADERS using the original proposed sort. """ This fixes the gcc patch as proposed as it does appear its been broken over time. (From OE-Core rev: dce28d8ac7fbae487cb6674b91fe2b574036b26d) Signed-off-by: Richard Purdie