These instructions are for 64-bit load/store. On ARMv5TE, the CPU
requires addresses to be aligned to 64-bit. When misaligned, behavior is
undefined (effectively either loads the same word twice on LDRD, or
corrupts surrounding memory on STRD).
On ARMv6 and newer, unaligned access is safe.
Removing these instructions for ARMv5TE is necessary, because GCC
ignores alignment information in pointers and does unsafe optimizations
that have shown up as bugs in various places.
This patch was originally added more than 11 years ago in commit b050f87d13,
but got lost 6 years ago, when gcc 9.1 was added in 88c07c6552.
This primarily affects the kirkwood and ixp4xx targets
Signed-off-by: Felix Fietkau <nbd@nbd.name>
GCC 14+ fails to build due to libatomic specific -march handling.
This build error triggers only with glibc and not with musl libc
which is default.
It seems that this patch from GCC14 was forgotten when GCC15 support was
being added [1].
[1] 44ef343500
Fixes: 68cb84183e ("toolchain: add support for GCC 15.1")
Signed-off-by: Robert Marko <robimarko@gmail.com>
All patches automatically refreshed.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18600
Signed-off-by: Robert Marko <robimarko@gmail.com>
There is no practical value in keeping GCC11 around, as even OpenWrt 23.05
uses GCC12 as the default one, so drop it.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Remove upstreamed patches:
- 020-MIPS-Include-missing-mips16.S-in-libgcc-lib1funcs.S.patch
- 021-Reuse-scratch-registers-generated-by-LRA.patch
All other patches are automatically refreshed.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/18891
Signed-off-by: Robert Marko <robimarko@gmail.com>
During the build of perl, the following ICE was reported in
https://github.com/openwrt/packages/issues/24565 when targeting PowerPC:
during RTL pass: reload
blocksort.c: In function 'mainSort.isra':
blocksort.c:1011:1: internal compiler error: in patch_jump_insn, at cfgrtl.cc:1303
1011 | }
| ^
0x7d49cee29d8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7d49cee29e3f __libc_start_main_impl
../csu/libc-start.c:392
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <http://bugs.openwrt.org/> for instructions.
The same issue also caused the CI failures in
https://github.com/openwrt/packages/pull/26501.
The issue only occurs with GCC 14.2.0, but not with the head of the
releases/gcc-14 maintenance branch; a bisect found that this patch fixes
it.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Link: https://github.com/openwrt/openwrt/pull/18797
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport patch from upstream GCC 14 branch which fixes linking with
MIPS16 on the pistachio target.
This fixes the following link problem:
```
/builder/shared-workdir/build/staging_dir/toolchain-mipsel_24kc+24kf_gcc-14.2.0_musl/lib/gcc/mipsel-openwrt-linux-musl/14.2.0/../../../../mipsel-openwrt-linux-musl/bin/ld.bfd: ./liblua.so: undefined reference to `__mips16_ledf2'
/builder/shared-workdir/build/staging_dir/toolchain-mipsel_24kc+24kf_gcc-14.2.0_musl/lib/gcc/mipsel-openwrt-linux-musl/14.2.0/../../../../mipsel-openwrt-linux-musl/bin/ld.bfd: ./liblua.so: undefined reference to `__mips16_call_stub_df_2'
/builder/shared-workdir/build/staging_dir/toolchain-mipsel_24kc+24kf_gcc-14.2.0_musl/lib/gcc/mipsel-openwrt-linux-musl/14.2.0/../../../../mipsel-openwrt-linux-musl/bin/ld.bfd: ./liblua.so: undefined reference to `__mips16_muldf3'
```
Link: https://github.com/openwrt/openwrt/pull/18688
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This reverts commit 57841c83d9.
This is completely breaking the inital GCC configuration and most likely
was not even compile tested, so revert until fixed.
Signed-off-by: Robert Marko <robimarko@gmail.com>
I've observed configuration drift for GCC between musl and glibc
(especially it's final stage):
# musl
lt_cv_prog_compiler_static_works=yes
lt_cv_prog_compiler_static_works_CXX=yes
lt_cv_sys_max_cmd_len=1572864
# glibc
lt_cv_prog_compiler_static_works=no
lt_cv_prog_compiler_static_works_CXX=no
lt_cv_sys_max_cmd_len=512
These changes should prevent this issue in future:
export lt_cv_prog_compiler_static_works=yes
export lt_cv_prog_compiler_static_works_CXX=yes
export lt_cv_sys_max_cmd_len=1572864
Also:
- provide custom autotools/libtool variables via properly named
variable ("GCC_CONFIGURE_VARS"),
- move variables from "GCC_MAKE" to "GCC_CONFIGURE_VARS"
(at this moment only "gcc_cv_libc_provides_ssp=yes" for musl),
- propagate it's usage for both "./configure" and "make".
Signed-off-by: Konstantin Demin <rockdrilla@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18646
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Xcode 16.3 defines TARGET_OS_MAC, it was not defined in prior versions.
zutil.h conditionally defines fdopen as NULL when this macro is defined,
resulting in the following build error:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_stdio.h:318:7: e>
318 | FILE *fdopen(int, const char *) __DARWIN_ALIAS_STARTING(__MAC_10_6, __IPHONE_2_0, __DARWIN_ALIAS(fdopen));
| ^
./zutil.h:147:33: note: expanded from macro 'fdopen'
147 | # define fdopen(fd,mode) NULL /* No fdopen() */
In Xcode 16.2 and earlier, TARGET_OS_MAC was not defined so this entire
block was ignored, gcc and gdb used to compile and work fine.
This may have been used for compatibility with older versions of macOS,
but is no longer needed. By pure luck, the build worked fine for a long
time, because it did not properly detect macOS.
Fixed by removing the check for TARGET_OS_MAC.
Note that since Xcode 16.3, an entire set of TARGET_OS macros
are now defined, most of which are set to 0:
TARGET_OS_LINUX 0
TARGET_OS_MAC 1
TARGET_OS_OSX 1
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18467
Signed-off-by: Robert Marko <robimarko@gmail.com>
GCC has changed musl dynamic linker name from
ld-musl-loongarch-lp64d.so.1 to ld-musl-loongarch64.so.1 recently [1].
Meanwhile musl 1.2.5 only supports the new name. So it's better to follow
the new name.
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8bccee51f0deac64b79cd9ad75df599422f4c8ff
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
I noticed that CONFIG_GDB was suddenly appearing in the main menuconfig
menu despite the fact that it should be visible only when TOOLCHAINOPTS
is selected and under a dedicated menu.
After some trial and error, it seems that this was caused by the recent
addition of GCC_USE_DEFAULT_VERSION, and after even more trial and error
it gets fixed as soon GCC_USE_DEFAULT_VERSION is placed after GCC_VERSION.
So, lets simply put GCC_USE_DEFAULT_VERSION after GCC_VERSION.
Fixes: 501ef81040 ("config: select KERNEL_WERROR if building with default GCC version")
Signed-off-by: Robert Marko <robimarko@gmail.com>
At the moment we have to manually follow the default GCC version
also in config/Config-kernel.in. This tends to be forgotten at GCC
version bumps (just happened when switching from version 12 to 13).
Instead, introduce a hidden Kconfig symbol which implies KERNEL_WERROR
in toolchain/gcc/Config.in where it is visible for developers changing
the default version.
Also remove the explicit default on BUILDBOT to avoid a circular
dependency and also because buildbots anyway implicitly always select
the default GCC version.
Reference: https://github.com/openwrt/openwrt/pull/15064
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__locale:550:5: error: '__abi_tag__' attribute only applies to structs, variables, functions, and namespaces
_LIBCPP_INLINE_VISIBILITY
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__config:891:37: note: expanded from macro '_LIBCPP_INLINE_VISIBILITY'
# define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__config:870:26: note: expanded from macro '_LIBCPP_HIDE_FROM_ABI'
__attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_ODR_SIGNATURE))))
Fixed using backport of upstream commits [1-2] as discussed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632#c21
[1] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9970b576b7e4ae337af1268395ff221348c4b34a
[2] libcc1: fix <vector> include
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5213047b1d50af63dfabb5e5649821a6cb157e33
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
Use GCC 13 instead of GCC 12 by default.
All target kernels are building with GCC 13.
Most packages from the feed are building fine.
The root file systems is getting a little bit smaller for MIPS 32 BE
and aarch64.
With GCC 12 I got these sizes for lantiq/xrx200:
7,005,867 openwrt-lantiq-xrx200-tplink_tdw8970-initramfs-kernel.bin
With GCC 13 I got these sizes for lantiq/xrx200:
6,989,754 openwrt-lantiq-xrx200-tplink_tdw8970-initramfs-kernel.bin
With GCC 12 I got these sizes for armsr/armv8:
13,083,836 openwrt-armsr-armv8-generic-ext4-combined.img.gz
4,900,240 openwrt-armsr-armv8-generic-ext4-rootfs.img.gz
20,142,592 openwrt-armsr-armv8-generic-kernel.bin
With GCC 13 I got these sizes for armsr/armv8:
13,068,966 openwrt-armsr-armv8-generic-ext4-combined.img.gz
4,893,078 openwrt-armsr-armv8-generic-ext4-rootfs.img.gz
20,142,592 openwrt-armsr-armv8-generic-kernel.bin
Signed-off-by: Nick Hainke <vincent@systemli.org>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
