Depending on the host C++ compiler GCC13 fails on riscv configurations
with the following error
src/gcc/gcc/config/riscv/genrvv-type-indexer.cc:118:30: error: no member named 'log2' in namespace 'std'; did you mean simply 'log2'?
elmul_log2 = lmul_log2 - std::log2 (sew / eew);
^~~~~~~~~
log2
/usr/include/c++/v1/math.h:1463:1: note: 'log2' declared here
log2(_A1 __lcpp_x) _NOEXCEPT {return ::log2((double)__lcpp_x);}
^
Bring in an upstream fix for the build error.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Run the patches through
./maintainer/manage-packages.sh -P -s gcc-12.2.0
to mop up the fact that we'd ended up with two 0005 patches.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
As mentioned in #1908, we should have patches that are experimental
under the CT_EXPERIMENTAL option. This an experimental patch to gcc:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600452.html
And since it may affect production toolchains, we should move this patch
to the experimental bundled patches introduced in the previous commit.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This adds backports of a couple of patches necessary to support macOS
arm64 hosts for gcc. It was ported from
https://github.com/richfelker/musl-cross-make/pull/129 with some small
fixups to make the patches apply cleanly.
Signed-off-by: Steven Fackler <sfackler@gmail.com>
This patch, submitted upstream but not (yet?) accepted, adds a third
parameter to the specs file 'getenv' function that provides a value
for when the environment variable is not set, instead of having gcc
fail.
This seemed like the safest way to provide a mechanism for getting the
installed location of the toolchain from inside a specs file as, when
not installed in the built-in location, gcc already sets the
GCC_EXEC_PREFIX environment variable to a well defined location within
that directory hierarchy, but when installed in the location specified
at compile time, gcc does not. Providing a default value that matches
the compile-time location then allows the specs file to compute paths
relative to the current GCC installation location, whereever it is
installed.
Signed-off-by: Keith Packard <keithp@keithp.com>
https://gcc.gnu.org/pipermail/gcc-announce/2022/000173.html
Add GCC 10.4.0 and regenerate the ct-ng patches. The
powerpc-Fix-asm-machine-directive-for-some-CPUs patch is dropped as the
change was applied upstream (and subsequently refactored).
Closes#1777
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This reverts commit 1b6ad7cd48. As it
turns out libsanitizer isn't supported on mips64 with GCC11 or older
(there is support in GCC12). The bug is actually the fact that ct-ng
allows configuring libsanitizer for architectures that don't support it.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Extend the fix from commit 6b465e15 ("Remove m1 from multilibs for GCC11
on SH arch.") to cover GCC 12 and future releases.
Remove the patch that was added to solve the same problem.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
For some reason GCC 12 ends up hitting the _MIPS_SIM_NABI32 case for
Linux's arch/mips/include/uapi/asm/stat.h when building libsanitizer.
This is basically the opposite of the problem from
commit 1b6ad7cd ("gcc: Bring in fix for libsanitizer on mips64").
Dropping the patch resolves the issue for GCC 12.
Fixes#1741
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add GCC 12.1 https://gcc.gnu.org/gcc-12/
The following patches from GCC 11.3.0 are no longer needed:
- 0005-arc-Update-ZOL-pattern.patch
- 0006-arc-Update-u-maddhisi4-patterns.patch
- 0007-arc-Fix-maddhisi-patterns.patch
- 0008-Darwin-aarch64-Initial-support-for-the-self-host-dri.patch
- 0009-libstdc-Check-for-TLS-support-on-mingw-cross-compile.patch
One new patch is needed to avoid issues building sh-unknown-elf:
- 0006-sh-Avoid-mb-m1-multilib-combination.patch
It is also necessary to build all-build-libcpp. This target exists as
far back as GCC 6 so has been done unconditionally.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The kernel's struct stat is 104 bytes when compiling for
_MIPS_SIM_ABI64. Set struct_kernel_stat_sz to match.
Fixes#1733
Signed-off-by: Chris Packham <judge.packham@gmail.com>
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>
... 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
