summaryrefslogtreecommitdiff
path: root/meta/recipes-devtools/gcc/gcc-4.9.inc
AgeCommit message (Collapse)AuthorFiles
2015-05-09gcc-4.9, gcc-5: Use variable SYSTEMLIBS_DIR instead of hardcoding it for aarch64Khem Raj1
Change-Id: I54dc82a569f02d489137d88f16d6b768c4ab779b Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-24gcc-4.9: backport from gcc trunk r212178Stefan Müller-Klieser1
When compiling meta-toolchain-qt5 on cortexa8, the compiler throws an internal compiler error: ... qttools-opensource-src-5.3.2/src/linguist/shared/po.cpp: In function 'bool loadPO(Translator&, QIODevice&, ConversionData&)': qttools-opensource-src-5.3.2/src/linguist/shared/po.cpp:717:1: internal compiler error: in add_stores, at var-tracking.c:6000 ... Tracking this down led to https://bugs.linaro.org/show_bug.cgi?id=534 It seems the bug is well know and fixed upstream. So backporting from trunk seems to be the right solution. This fixes the compiler problem on cortexa8 and does not seem to be very invasive. The original commit can be found at: git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212178 138bc75d-0d04-0410-961f-82ee72b054a4 Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-15gcc: Upgrade 4.9.1 -> 4.9.2Khem Raj1
Delete backported patch which are present in 4.9.2 backport patched from upstream gcc trunk to fix [YOCTO #6824] Change-Id: Ia0067940471d4c5d9d62089bf6f18f3a9c2bfedd Signed-off-by: Khem Raj <raj.khem@gmail.com>
2015-01-28gcc: ensure target gcc headers can be includedPaul Eggleton1
There are a few headers installed as part of gcc-runtime (omp.h, ssp/*.h). Being installed from a recipe built for the target architecture, these are within the target sysroot and not cross/nativesdk; thus they weren't able to be found by gcc with the existing search paths. Add support for picking up these headers under the sysroot supplied on the gcc command line in order to resolve this. Thanks to Richard Purdie for giving me a number of pointers during fixing this issue. Fixes [YOCTO #7141]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-12-22gcc: Disable aarch64 multilib optionsMark Hatle1
We want to revert to default gcc behavior to support oe-core's ability to change the libdir. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-06gcc: backport two patches to fix ICE in dwarf2out_var_locationJackie Huang1
The first patch fixes the ICE in dwarf2out_var_location, at dwarf2out.c. r212171: * except.c (emit_note_eh_region_end): New helper function. (convert_to_eh_region_ranges): Use emit_note_eh_region_end to emit EH_REGION_END note. * jump.c (cleanup_barriers): Do not split a call and its corresponding CALL_ARG_LOCATION note. But it introduced a regression issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 so backport the fix for the regression as well: r215613: PR rtl-optimization/63348 * emit-rtl.c (try_split): Do not emit extra barrier. Signed-off-by: Jackie Huang <jackie.huang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-10-24gcc: poison default sysroot pathRichard Purdie1
Various pieces of the code assume that the --sysroot option gets passed into the compiler tools. By having a "sane" default, we don't always spot when this occurs and this can later show up as breakage in sstate, or in usage of the external toolchain. We've long since talked about poisoning the default such that it will break unless the correct option is specified. This patch does just that. If this patch causes something to fail to build, it most likely means the various compiler flags and commands are not correctly being passed through to the underlying piece of software and that there is a real problem that needs fixing, its not the fault of this patch. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-11gcc: backport patch for gcc bug 61144Saul Wold1
This fixes gcc bug 6144, which in my case exhibited itself as a kernel module that failed to load. This was because static platform_data structures were being corrupted with the optimiser being set to any value other than -O0. Originally-submitted-by: Peter Urbanec <openembedded-devel@urbanec.net> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: backport patch affecting Linux kernel buildsPeter A. Bigot1
A long-standing bug in gcc turns out to cause problems with unpatched Linux versions due to improved optimization enabled by gcc 4.9. The upstream fix missed the gcc-4.9.1 cut-off. It's also been applied upstream to the 4.8 branch so is being added for OE's 4.8 as well. Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc-4.9: Ensure c++ includes are in /usr/include/c++/${BINV}Peter A. Bigot1
Apply to gcc 4.9 the recent fix to the --with-gxx-include-dir override. Original OE-Core rev: 5a2ff3e8f7cd7a47a5ab4e581847ecc4df87fca Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: remove inappropriate patchPeter A. Bigot1
0037-gcc-4.8-PR56797.patch was originally added as an OE backport during 4.8.0. Upstream merged it in 4.8.1, and it was present in 4.9.0. The original patch still applies to 4.9.1 (and presumably 4.8.2), but now is modifying store_multiple_sequence instead of load_multiple_sequence (the two functions are nearly identical). It may or may not be necessary in store_multiple_sequence, but absent a bug report upstream supporting its application in this case, or a least an updated comment and upstream status in the patch, I think this patch should be dropped. Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: recipe whitespace changesPeter A. Bigot1
Consistent use of whitespace in multi-line assignment, with special focus on OECONF modifications. Quotes on separate lines, four-space indentation, one value per line. Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-02gcc: Upgrade 4.9.0 -> 4.9.1Khem Raj1
Drop patches which are already available in 4.9.1 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2014-07-25gcc-4.9.inc: fix parallel building failureHongxu Jia1
In subdir 'gcc', Most C source files included config.h which was generated by a rule. But no related prerequisites was added to the C source compiling rule. There was potential building failure while makefile enabled parallel. The C source compiling rule used suffix rule '.c.o', but the suffix rule doesn't support prerequisites. https://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html We used the pattern rule '%.o : %.c' to instead, and add the config.h as its prerequisite We also moved the '%.o : %.c' rule down to the 'build/%.o :' rule, which makes '%.o : %.c' rule doesn't override 'build/%.o :'. [YOCTO #6568] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-29recipes-devtools: fix segfault in lib32-gcc with "." multilib_dirPaul Gortmaker1
When enabling a lib32-gcc in a 64 bit build, without doing any other configuration, the mutilib dir is unspecified, which is represented internally in gcc as "." and as such uncovers an invalid free on a non-malloc'd pointer. As suggested by the gcc folks, simply make sure the "." case is also stored in a malloc'd pointer, so that the intended runtime behaviour of the code remains unchanged. Patch has been accepted by upstream maintainers of gcc. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-01gcc: Clean up configure_prepend and fix for mingwRichard Purdie1
The do_configure_prepend was duplicated in gcc-4.X.inc and gcc-configure-common.inc leading to confusion when reading the resulting do_configure task where the file was processed twice. The only difference was the removal of the include line for gcc 4.8/4.9. On mingw were were seeing two issues, firstly that the if statements meant the values we wanted weren't being set, the second that the include paths were still wrong as there was no header path set. To fix the first issue, the #ifdef conditionals were removed, we want to set these things unconditionally. The second issue is addressed by setting the NATIVE_SYSTEM_HEADER_DIR variable here (it was already set in t-oe). Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29gcc: add patch to fix errors with Decimal64 typeAlexandru-Cezar Sardan1
[OE-core bug #6270] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=6270 Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan-KZfg59tc24xl57MIdRCFDg@public.gmane.org> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-13gcc: remove usage of FILESPATHPetter Mabäcker1
Fixes [YOCTO #4497] Usage of FILESPATH is discouraged, since it can make recipes harder to bbappend. Instead FILESEXTRAPATHS should be used to extend the path. Signed-off-by: Petter Mabäcker <petter@technux.se> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-05gcc: Add 4.9 recipesKhem Raj1
(From OE-Core rev: f051216ea373f166016b15bbd2a2a6f136430372) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>