summaryrefslogtreecommitdiff
path: root/packages/gcc
AgeCommit message (Collapse)AuthorFilesLines
2022-02-28gcc: powerpc: Fix asm machine directive for some CPUsHEADcrosstool-ng-1.25.0-rc1masterChris Packham2-0/+118
Bring in upstream fix for gcc outputting an incorrect .machine directive. Signed-off-by: Chris Packham <judge.packham@gmail.com>
2022-02-28Fix MinGW libstdc++ TLS functionalityivanka20121-0/+251
Backport of https://github.com/gcc-mirror/gcc/commit/cc1e28878a228b6c4a0872e56d97ac88971b7725 Signed-off-by: Kittenberger Iván <ivanka2012@gmail.com>
2022-02-11Run patches thru `manage-packages -P`Alexey Neyman43-279/+190
This refreshes the line numbers, removes any fuzz (which would make any future forward ports easier) and standardizes the patch/file headers (which makes them easier to read). Signed-off-by: Alexey Neyman <stilor@att.net>
2022-02-11Run packages through `manage-packages -D`Alexey Neyman1-4/+4
This fixed some typos in the checksum files (please don't edit them manually, this is error-prone!) Signed-off-by: Alexey Neyman <stilor@att.net>
2022-02-11Retire obsoleted milestonesAlexey Neyman1-1/+1
... and the code dependent on them, after the latest wave of obsolete package removals. This concludes the glorious history of the original uClibc (non-NG) with lots of kludges removed. There was a choice here, whether to call the resulting libc "uClibc" or "uClibc-ng". I opted in favor of giving uClibc-ng the recognition it deserves, although it had some ripple effect in the ct-ng code. Signed-off-by: Alexey Neyman <stilor@att.net>
2022-02-11Remove gcc-oracle-4.8-44.0.5Alexey Neyman2-0/+38
GCC 4.8 and its prerequisites have been removed by 04dce680, 41d4583a and e4221734; as a result, 4.8-based version of gcc-oracle became unbuildable (no valid versions for the prerequisites). Update the samples to use 4.9.4; which however fails to build on a modern host GCC. Build fix backported to gcc-4.9 and gcc-5 versions. Fix binutils-oracle build with host GCC11. Signed-off-by: Alexey Neyman <stilor@att.net>
2022-01-13gcc: Use upstream fix for cross-canadian buildsChris Packham2-47/+78
Replace the patch from #1600 with the change that landed upstream. Signed-off-by: Chris Packham <judge.packham@gmail.com>
2021-12-13gcc: Fix 11.2.0 build failure on MacOS with Apple M1Kairui Song1-0/+99
With latest aarch64-unknown-linux-gnu, ct-ng build failed with: [INFO ] Installing pass-1 core C gcc compiler [EXTRA] Configuring core C gcc compiler [EXTRA] Building gcc [ERROR] clang: error: linker command failed with exit code 1 (use -v to see invocation) [ERROR] make[2]: *** [Makefile:2148: xgcc] Error 1 [ERROR] make[2]: *** Waiting for unfinished jobs.... [ERROR] clang: error: linker command failed with exit code 1 (use -v to see invocation) [ERROR] make[2]: *** [Makefile:2157: cpp] Error 1 [ERROR] make[1]: *** [Makefile:4444: all-gcc] Error 2 And in build log: Undefined symbols for architecture arm64: "host_detect_local_cpu(int, char const**)", referenced from: static_spec_functions in gcc.o Just backport a upstream gcc fix. Signed-off-by: Kairui Song <ryncsn@gmail.com>
2021-10-10gcc11: Fixes for ARCAlexey Brodkin3-0/+285
See more details here: 1. https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/398 2. https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/427 3. https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/429 Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2021-09-21gcc: Remove obsolete versionsChris Packham30-2575/+0
The following versions were marked obsolete in crosstool-ng-1.24.0, remove them. - gcc-linaro-4.8-2015.06 - gcc-4.8.5 Signed-off-by: Chris Packham <judge.packham@gmail.com>
2021-09-15gcc: Fix cross-canadian builds wih GCC11Alexey Brodkin1-0/+47
With this we may finally build Windows and "native" toolchains if host tools are also GCC11 based. For example: 1. You build cross toolchain with all the recent components by CT-NG 2. You build cross-canadian toolchain for Windows or ARC, ARMm whatever board See upstream bug report [1] for more details. Basically when we do cross-canadian build with use of the same GCC11 as a "host" compiler we're seeing an error like that: ------------------->8------------------- mingw-w64-cross/gcc/x86_64-w64-mingw32/libstdc++-v3/include/fenv.h:58:11: error: 'fenv_t' has not been declared in '::' 58 | using ::fenv_t; ------------------->8------------------- This is a solution proposed by Yujie Yang in [2] Note, though it's not the final fix merged upstream, that's just an attempt to fix this by casual GCC users. There's a hope it will be fixed anyways a bit later, maybe by the time of GCC 11.3... [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017#c20 Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2021-09-15gcc: Refresh patches of GCC 11.2.0Alexey Brodkin5-69/+24
As simple as: ./maintainer/manage-packages.sh --update-patches --select gcc-11.2.0 Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2021-07-28gcc: bump to 11.2graysky8-8/+8
Signed-off-by: John Audia <graysky@archlinux.us>
2021-07-05gcc: Bump maintenance versionsChris Packham48-16/+16
8.4.0 -> 8.5.0 9.3.0 -> 9.4.0 Signed-off-by: Chris Packham <judge.packham@gmail.com>
2021-06-17packages/gcc/libstdc++: #include_next → #includeKeith Packard2-0/+614
Some of the installed libstdc++ header files use '#include_next' to work around toolchain oddities that might cause loops in the compiler. However, these also cause mistakes in locating header files when there are multiple C libraries installed as '#include_next' often ends up finding default C library header files. It doesn't seem like this patch could be accepted upstream; there's a long discussion about the use of include_next in these headers which I cannot fully understand. Signed-off-by: Keith Packard <keithp@keithp.com>
2021-06-07packages: gcc: Add missing milestonesStephanos Ioannidis1-1/+1
This commit adds the missing gcc milestones 9 and 10, so that the helper symbols `GCC_9_or_later` and `GCC_10_or_later` can be used. Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
2021-05-05Disable -Werror for GLIBC for all ARCH for GCC11.spaun20021-1/+1
This change replicates what GLIBC 2.23 has in the string/rawmemchr.c: // #if __GNUC_PREREQ (11, 0) // /* Likewise GCC 11, with a different warning option. */ // DIAG_IGNORE_NEEDS_COMMENT (11, "-Wstringop-overread"); // #endif With -Werror multiple platforms failing on the string/rawmemchr.c:40 line. Signed-off-by: Nik Konyuchenko <spaun2002mobile@gmail.com>
2021-05-05Pull patch for macOS from GCC 10.3.0 package.spaun20021-0/+18
This should fix linkage error on MacOS. Signed-off-by: Nik Konyuchenko <spaun2002mobile@gmail.com>
2021-04-28Initial commit for gcc11spaun20025-0/+70
Signed-off-by: Nik Konyuchenko <spaun2002mobile@gmail.com>
2021-04-08Update to gcc release 10.3.0Kumar Gala29-172/+8
Drop patches already in 10.3.0 that had been backported Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2021-04-06Fix depends generation under windowsIvan Kukhta1-0/+29
Signed-off-by: Ivan Kukhta <Ivan.Kukhta@acronis.com>
2021-03-24Merge branches 'gcc10_shift_numbering' and 'gcc10_fno-rtti'Chris Packham1-0/+67
2021-03-23gcc: just shift numbering in patch namesAnton Maklakov4-0/+0
2021-03-23gcc: Fix bootstrap with -fno-rttiAnton Maklakov1-0/+67
2021-01-12gcc: Add support for building libstdc++ with alternate libcKeith Packard1-0/+275
This adds another mode to do_gcc_core_backend that builds libstdc++ against an alternate libc implementation. Signed-off-by: Keith Packard <keithp@keithp.com>
2020-12-08gcc: Additional build fix for building arm64 toolchain on M1 Mac'sKumar Gala1-0/+33
If we are targetting an aarch64-none-elf toolchain we end up running into a build issue in gcc/config/aarch64/driver-aarch64.c. This is fixed in upstream gcc so just backport the patch to gcc-10.2.0 Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-12-04gcc: Add some patches to get gcc 10.2 building on ARM based MacKumar Gala2-0/+132
Pull in a change from upstream GCC and one from the gcc-darwin-arm64 repo that gets an initial cross compiler building on ARM based Mac. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-11-11gcc: add build fix for aarch64 toolchain on MacOS XKumar Gala1-0/+34
When building aarch64-unknown-linux-gnu on MacOS X, aarch64-builtins.c files doesn't build by default with clang on MacOS X. We need to pass -std=gnu++11 when building the file for things to work with clang. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-11-10Merge pull request #1342 from DspHack/feature/add_support_for_ti_c6xChris Packham1-0/+48
Experimental: Add support for the Texas Instruments C6X (TMS320C6000 …
2020-08-27Add support for GCC 10.2.0Hans-Christian Noren Egtvedt21-0/+1392
Forward ported patches from GCC 9.x, refreshed to match current sources. Patch 0010-crystax.patch did not apply clean and had minor adjustments to fit new GCC 10.2.0 release. Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
2020-08-27Update to GCC 9.x to latest release 9.3.0Hans-Christian Noren Egtvedt22-23/+25
Forward ported patches from GCC 9.2.0 to 9.3.0, refreshed to match current sources. Patch 0010-crystax.patch did not apply clean and had minor adjustments to fit new GCC 9.3.0 release. Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
2020-05-21Experimental: Add support for the Texas Instruments C6X (TMS320C6000 series) ↵Dan Tejada1-0/+48
DSPs -- c6x: Add support for c6x product families to pass on to uClibC-ng -- c6x: Fix multilib support -- c6x: Add patch fix internal instruction error (GCC 57295) Signed-off-by: Dan Tejada <dan.tejada@cantada.com>
2020-05-01gcc: Remove nested 8.3.0 directoryChris Packham23-0/+0
When GCC was updated to 8.4.0 the patches were moved incorrectly. Fix this now so that they will be picked up. Fixes: commit 31ca84ac ("Update to gcc 8.4.0") Signed-off-by: Chris Packham <judge.packham@gmail.com>
2020-03-18Update to gcc 8.4.0Chris Packham26-8/+8
https://gcc.gnu.org/legacy-ml/gcc/2020-03/msg00042.html Signed-off-by: Chris Packham <judge.packham@gmail.com>
2020-03-04Disallow PPS SPE ABIAlexey Neyman1-1/+1
with GCC 9+ and GLIBC 2.30+, they no longer support it. Signed-off-by: Alexey Neyman <stilor@att.net>
2019-12-26Version updatesAlexey Neyman24-14/+14
bison, elf2flt, gcc, isl, linux, mingw-w64, strace. Adjust checksum ordering in uclibc-ng so that it matches what the script generates. Signed-off-by: Alexey Neyman <stilor@att.net>
2019-08-15Update to gcc 9.2.0Hans-Christian Noren Egtvedt21-0/+1390
Forward ported patches from GCC 8.3.0 to 9.2.0, refreshed to match current sources. In patch 0012-crystax.patch, removed changing sysv4.h header file for rs6000, since it no longer defines LINK_EH_SPEC. Removed the following patches because they are part of upstream: - 0018-ARC-Add-multilib-support-for-linux-targets.patch - 0020-ARM-fix-cmse.patch - 0021-arm-Make-arm_cmse.h-C99-compatible.patch - 0022-ARC-Update-fma-expansions.patch Renamed 0019-isl-0.20.patch => 0018-isl-0.20.patch. Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
2019-04-17package/gcc: Fix Glibc compilation for ARC with -mcpu= hs38_linuxAlexey Brodkin1-0/+71
Back-port of upstream fix: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5664ecf49828edb20f53937ab2e417ba173fc903 Fixes: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90103 Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2019-02-25Run GCC 8.3.0 patches through manage-packages.sh -PAlexey Neyman6-110/+55
Signed-off-by: Alexey Neyman <stilor@att.net>
2019-02-23Update to gcc 8.3.0Kumar Gala26-62/+112
Had to update the following patches so they'd apply: 0006-libgfortran-missing-include.patch 0010-crystax.patch Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-01-30Config v2: select relevant parts of each package versionAlexey Neyman1-1/+2
Also, remove a couple of config options that dealt with package versions that have been since retired. Signed-off-by: Alexey Neyman <stilor@att.net>
2018-12-07Import GCC 7.4.0Alexey Neyman27-247/+25
Signed-off-by: Alexey Neyman <stilor@att.net>
2018-11-08Import gcc 6.5.0Alexey Neyman37-319/+31
Signed-off-by: Alexey Neyman <stilor@att.net>
2018-09-27Pull in fixes for ARM v8m support in gcc 8.2.0Kumar Gala2-0/+109
There are some fixes to the cmse code in mainline gcc that we need to build an embedded toolchain targetting Cortex-M cpus that support the v8m extensions. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2018-09-26Fix build with ISL 0.20Alexey Neyman6-18/+81
Signed-off-by: Alexey Neyman <stilor@att.net>
2018-09-25Upgrades. Lots of 'em.Alexey Neyman26-612/+14
Signed-off-by: Alexey Neyman <stilor@att.net>
2018-06-24package/gcc: fix xtensa PR target/65416Max Filippov4-0/+404
gcc-8.1 for xtensa miscompiles uClibc dynamic linker due to gcc PR target/65416. The build completes successfully, but the binary is non-functional because the following fragment in the _dl_get_ready_to_run in ld-uClibc.so overwrites register spill area on stack causing register corruption in the previous call frame and a subsequent crash: 419f: f0c1b2 addi a11, a1, -16 41a2: 1ba9 s32i.n a10, a11, 4 41a4: 0bc9 s32i.n a12, a11, 0 41a6: 5127f2 l32i a15, a7, 0x144 41a9: 1765b2 s32i a11, a5, 92 41ac: 4e2782 l32i a8, a7, 0x138 41af: 146af2 s32i a15, a10, 80 41b2: 001b10 movsp a1, a11 The crash terminates the init process and causes kernel panic. The fix prevents reordering of movsp opcode and any access to the stack frame memory and is applicable to all existing gcc versions. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2018-06-05Add upstream patch fixing XScale buildAlexey Neyman1-0/+52
Signed-off-by: Alexey Neyman <stilor@att.net>
2018-05-21ARC: Add multilib support for Linux in GCCAlexey Brodkin1-0/+76
We never bothered to build multilibbed Linux toolchains for ARC and so we ended-up with no support of multilib for arc*-*-linux-* targets in GCC. That is now fixed in upstream by the following commit: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0eacfbcb2bf1834294f468a2bb41fe5d5e8d3883 Once the fix mentioned above is applied on top of GCC 8.1.0 we may easily build multilibbed uClibc toolchain for ARC. Note sice Glibc port for ARC is still in review process we cannot build any Glibc toolchains for ARC with pure upstream components, for that we eiter need Glibc sources from our Github repo or apply a set of patches on top of Glibc 2.27 - we'll try to address this later though. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2018-05-16Merge pull request #971 from abrodkin/topic-elf32-multilibAlexey Neyman1-0/+35
ARC: Add support and sample for baremetal/elf32 multilib toolchain
generated by cgit v0.10.2-6-g49f6 at 2024-05-02 12:05:38 (GMT)