Fix an internal compiler error on PPC from building a specific test:
$ $CC -S 7d-02.c
7d-02.c: In function â:
7d-02.c:11:5: internal compiler error: in copy_to_mode_reg, at explow.c:612
vec_st(v, i*16,p);
^~~~~~
The failure appears to happen on all optimizations levels as well.
(From OE-Core rev: b042347ee8cdbd2dfb0c2f616a94c4cca4b0ecd1)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whenever "-mno-sse" is used, "-mfpmath" should be set to 387.
The test case should be modified accordingly as below:
/* { dg-additional-options "-mno-sse -mfpmath=387 " { target { i?86-*-* x86_64-*-* } } } */
Original patch from: RAGHUNATH LOLUR <raghunath.lolur@kpit.com>
(From OE-Core rev: b3d0d7b599d605568abdb45057d3f6fbc80224d9)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch to fix errors such as:
error: aggregate 'sigaltstack handler_stack' has incomplete type and cannot be defined
(From OE-Core rev: 6a3d9e53e3b3340c48af2242c9871bb2e0a763f5)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
| ../../valgrind-3.12.0/VEX/priv/host_ppc_isel.c: In function 'iselInt64Expr':
| ../../valgrind-3.12.0/VEX/priv/host_ppc_isel.c:3270:1: internal compiler error: Segmentation fault
| }
| ^
| Please submit a full bug report,
| with preprocessed source if appropriate.
| See <http://gcc.gnu.org/bugs.html> for instructions.
| rm -f libvexmultiarch-amd64-linux.a
| Makefile:1813: recipe for target 'priv/libvex_amd64_linux_a-host_ppc_isel.o' failed
Remove the patch to gcc causing this until the issue can be figured out.
(From OE-Core rev: 36be209262ee1e0a7598c9437c9f8c4e926c0e35)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The following commit added the FL_LPAE flag to FL_FOR_ARCH7VE, but
neglected to also add it to the armv7ve compatible cores defined in
arm-cores.def.
af2d9b9e58
The result is that gcc 6.4 now refuses to allow -march=armv7ve and
-mcpu=XXX to be used together, even when -mcpu is set to an armv7ve
compatible core:
arm-linux-gnueabi-gcc -march=armv7ve -mcpu=cortex-a7 -Werror ...
error: switch -mcpu=cortex-a7 conflicts with -march=armv7ve switch [-Werror]
Fix by defining flags for armv7ve compatible cores directly from
FL_FOR_ARCH7VE, rather than re-creating the armv7ve flags
independently by combining FL_FOR_ARCH7A with the armv7ve specific
FL_THUMB_DIV and FL_ARM_DIV flags.
(From OE-Core rev: e0d856d64f9e2afd762d6d40bcc6c8dc5e06b430)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The change to link libssp_nonshared.a only for musl was to move
spec file changes to config/linux.h under a conditional when
DEFAULT_LIBC == LIBC_MUSL which worked fine for all but ppc
since gcc for ppc provided its own linux.h overrides which are
used. This patch duplicates the change in those headers too
Cherry-picked from oe-core master 9d39168a6acfa1f289a4448271c0bf9caaea10ec
(From OE-Core rev: 9d265f398a97dccb19811b048b1f4a2dd9d3fdd5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
glibc already provides the content for libssp_nonshared
in libc_nonshared.a therefore we dont need to make it
universal.
This also fixed build issues on glibc when linking statically
and using -fstack-protector
Fixed errors like
/mnt/a/oe/build/tmp/work/i586-bec-linux/aufs-util/3.14+gitAUTOINC+bdfcc0dcfc-r0/recipe-sysroot/usr/lib/../lib/libc.a(stack_chk_fail.o): In function `__stack_chk_fail': /usr/src/debug/glibc/2.26-r0/git/debug/stack_chk_fail.c:27: multiple definition of `__stack_chk_fail_local' /mnt/a/oe/build/tmp/work/i586-bec-linux/aufs-util/3.14+gitAUTOINC+bdfcc0dcfc-r0/recipe-sysroot/usr/lib/../lib/libssp_nonshared.a(libssp_nonshared_la-ssp-local.o):/usr/src/debug/gcc-runtime/7.1.0-r0/gcc-7.1.0/build.i586-bec-linux.i586-bec-linux/i586-bec-linux/libssp/../../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/libssp/ssp-local.c:47: first defined here collect2: error: ld returned 1 exit status
Cherry-picked from oe-core master d71eba26850838b2878efea3f8c392a2eb2ebbfb
(From OE-Core rev: 9ee16f7f57f37e62c1fae3b27d93de2d83b2a804)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The static PIE patch was updated by Juro Bystricky <juro.bystricky@intel.com>
to work with gcc 7.3.
This update from the stable gcc 7 branch includes the retpoline
functionality which is useful to assist with recent security issues.
Two backported patches were dropped as they're included in 7.3.
(From OE-Core rev: 99b1998157ecbd2bc8ac7c24fae859d48b152f58)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch to fix miscompilation on mips64.
We've observed strange behaviour of `systemctl status <xxx> on qemumips64.
The output of the command is like `systemctl show <xxx>', which is incorrect.
The problem is due to the miscompilation of gcc for mips64 platform, thus
backporting patch from upstream to fix this problem.
[YOCTO #12266]
(From OE-Core rev: 6264b4afe6962d37eeb918e062568dee811ef231)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit cfa13e5c756849820644d86d1882602649db6a9c)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use ucontext_t not struct ucontext in linux-unwind.h files.
Current glibc no longer gives the ucontext_t type the tag struct
ucontext, to conform with POSIX namespace rules. This requires
various linux-unwind.h files in libgcc, that were previously using
struct ucontext, to be fixed to use ucontext_t instead. This is
similar to the removal of the struct siginfo tag from siginfo_t some
years ago.
Backport of patches by Joseph Myers, taken from
https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=249957
[YOCTO #12083]
(From OE-Core rev: ec1c18d866c137b1fa523d0fcc29f65a28f59f44)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Under some rare circumstances we may end up with GCC segmentation fault.
This was observed with versions of sysmacros.h, which contain macros
with embedded warning messages :
When trying to actually display the warning, we may end up with a segmentation
fault instead. The reason is the actual warning message gets parsed (the text is
unquoted) and words in the message such as "not", "and" etc. are interpreted as
operators CPP_NOT, CPP_AND. When the time comes to display the warning, the code
uses wrong structure to access the "name" corresponding to the operators.
[YOCTO #11738]
(From OE-Core rev: 6f81fe4f3a1177c0049b26a070e43546bc6fe974)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we used -fuse-ld gcc option, then it does not work
ending in
collect2: fatal error: cannot find 'ld' compilation terminated.
This is because we are not creating proper symlinks for BFD
and Gold linker in gcc installation
Secondly, we end up with dangling fortran compiler symlinks
if fortran is not enabled when confguring gcc, therefore
create these symlinks only when fortran support is enabled
in gcc
(From OE-Core rev: f84614c082406287e608860741a82edd2f3c9bca)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The change to link libssp_nonshared.a only for musl was to move
spec file changes to config/linux.h under a conditional when
DEFAULT_LIBC == LIBC_MUSL which worked fine for all but ppc
since gcc for ppc provided its own linux.h overrides which are
used. This patch duplicates the change in those headers too
(From OE-Core rev: 9d39168a6acfa1f289a4448271c0bf9caaea10ec)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sigaltstack is no more exposed by glibc see (bug 21517)
therefore adjust to use stack_t instead
Use res_state typedef instead of referring to __res_state struct
(From OE-Core rev: c5cb3a582531dd1b9c40df5bcaa6f8bf5b451a54)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
glibc already provides the content for libssp_nonshared
in libc_nonshared.a therefore we dont need to make it
universal.
This also fixed build issues on glibc when linking statically
and using -fstack-protector
Fixed errors like
/mnt/a/oe/build/tmp/work/i586-bec-linux/aufs-util/3.14+gitAUTOINC+bdfcc0dcfc-r0/recipe-sysroot/usr/lib/../lib/libc.a(stack_chk_fail.o): In function `__stack_chk_fail': /usr/src/debug/glibc/2.26-r0/git/debug/stack_chk_fail.c:27: multiple definition of `__stack_chk_fail_local' /mnt/a/oe/build/tmp/work/i586-bec-linux/aufs-util/3.14+gitAUTOINC+bdfcc0dcfc-r0/recipe-sysroot/usr/lib/../lib/libssp_nonshared.a(libssp_nonshared_la-ssp-local.o):/usr/src/debug/gcc-runtime/7.1.0-r0/gcc-7.1.0/build.i586-bec-linux.i586-bec-linux/i586-bec-linux/libssp/../../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/libssp/ssp-local.c:47: first defined here collect2: error: ld returned 1 exit status
(From OE-Core rev: d71eba26850838b2878efea3f8c392a2eb2ebbfb)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GCCPIE flag which is empty by default adds "--enable-default-pie"
configure option for harderned distros
We do not require to add -fpie -pie flag externally anymore
(From OE-Core rev: 1c7e195c94764d680a12a49b870f04cd58860f81)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to the fact that the recipe uses INHIBIT_DEFAULT_DEPS, we need to
manually add the cross compiler as a dependency.
(From OE-Core rev: 00fba52c8a6f6383137cf89fc7aa34cc3e2ff45f)
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds or fixes the Upstream-Status for all remaining patches missing it
in OE-Core.
(From OE-Core rev: 563cab8e823c3fde8ae4785ceaf4d68a5d3e25df)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a variety of spelling and format mistakes to improve the ease of reading the
tags programatically.
(From OE-Core rev: 6e1aaf80b0d951b48cd25cb7161ec19448295094)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some of these are clearly dead, e.g. one binutils patch reverts the effects
of the earlier one.
This also removes the uclibc site files. We now have mechanisms to allow these
to be extended from another layer should someone ever wish to do that.
(From OE-Core rev: e01e7c543a559c8926d72159b5cd55db0c661434)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We now have gcc 6 and gcc 7 recipes, the gcc 5 series can be dropped
as we're no longer going to support it for targets.
(From OE-Core rev: 98183e57dffaa155fc207a28e1c788ff50dc2054)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
uclibc support was removed a while ago and musl works much better. Start to
remove the various overrides and patches related to uclibc which are no longer
needed.
uclibc support in a layer would still be possible. I have strong reasons to
believe nobody is still using uclibc since patches are missing and I doubt
the metadata even parses anymore.
(From OE-Core rev: ec03023d2165b49a52b83bac1ea2f0bfded7b852)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It results in same link errors like armv4t
(From OE-Core rev: 7fb9648f7a055beef9c8a735850b1b51fd23ff1d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta-micro puts headers in /include rather than /usr/include in the
sysroot. ${target_includedir} means that the correct path will be used
automatically.
(From OE-Core rev: 12abcc3791592035d99064262eb3d229fa5ef88c)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Acked-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We only build one gcc-cross per architecture and having target specific
flags means gcc-cross would rebuild. These flags are really for the
on target case, so they should be set in gcc-target only.
(From OE-Core rev: 851937dde81de2a9ef54c5f19a78fb12fb82afd4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The path to where to install and find the sysroot components is used
in many places. This warrants it to get its own variable.
(From OE-Core rev: 70a84b525470f72339568409daf84845904e4cab)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"yocto-compat-layer.py --machines" showed that shared packages like
gcc-cross-powerpc64 have a sstate signature that depends on
TUNEFLAGS. As a result, there are unnecessary rebuilds and potential
conflicts in a multiconfig.
That's due to the way how TARGET_ARCH is set. Richard Purdie suggested
setting TARGET_ARCH[vardepvalue] as fix, which works. It would be
shorter to do that in cross.bbclass instead of repeating the relevant
line in different recipes, but Richard was concerned about potential
side-effects in other usages of cross.bbclass.
TARGET_GOARM as used in go.inc is still causing signature differences
for go-cross-powerpc64 and machines b4420qds-64b and p5020ds-64b. This
needs further investigation.
(From OE-Core rev: 39bfa0dd3237cbca47e7fca1075d521f9d073f25)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Building gcc-cross-initial with GCC7 on the host fails due to the
comparison of a pointer to an integer in ubsan_use_new_style_p, which
is forbidden by ISO C++:
ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and
integer [-fpermissive]
|| xloc.file == '\0' || xloc.file[0] == '\xff'
Backport the fix from upstream GCC to enable the build with GCC 7
(From OE-Core rev: 7a7fcbab0365b9501c737dbc02715be14dda72a3)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've had a lot of users running into RSS issues where -initial recipes
were being installed into sysroots alongside their counterparts and
causing overlapping files issues.
In general this was through do_build dependencies. Such dependencies are
bad in general and I'd encourage people to compare the taskgraphs with
using a more specific dependency like do_populate_sysroot, do_image_complete
or do_deploy as often the more specific dependency will result in a much
cleaner build.
Regardless, we don't want -initial dependencies getting in the way like
this and there are cases a do_build dependency could make sense.
Deleting the do_build task in these cases makes sense since this is not
a build "endpoint" we'd ever want a user to use, its a behind the scenes
piece of bootstrappping.
Unfortunately to make this work, we need a newer bitbake version which
has a bitbake bug fixed.
(From OE-Core rev: 04c053d42ab05f77b2d1ca93a0fabae44073d57e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create symlinks for gcov and gcov-tool and that they can be used trivially
on target.
(From OE-Core rev: 5b5a506a6d81095c967304fe4ec38a4bc3dc1edd)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The file /usr/libexec/gcc/.../cc1 has been installed in package gcc
instead of package cpp, because FILES statements for both packages match
the cc1 binary. Move the file to package cpp and add cpp to RDEPENDS_gcc
to fix the dependency.
Having the cc1 binary in cpp fixes errors such as: "cpp: error trying to
exec 'cc1': execvp: No such file or directory".
(From OE-Core rev: 4bf84edeb6cf4ba82a21bc7ceb1da4f59d839064)
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE-2016-4490 applied to gcc < 6.1.1, our version is 6.3
(From OE-Core rev: d8329861bf6f48f6e541a04062b8d1f373dfcd78)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Intel MPX was recently enabled on x86 (_append_x86) but that didn't
enable it on x86-64. Explicitly enable libmpx on x86-64 too.
(From OE-Core rev: 5111bd5e666408dbca7db0e6d664fe0103744253)
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package:
/usr/lib/libmpxwrappers.la
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
gcc-runtime: 1 installed and not shipped files. [installed-vs-shipped]
(From OE-Core rev: 3658da86e57dc87ac3957b05f853a7f1a56bfab2)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
