Memory references to DI mode objects could incorrectly be created at
offsets that are not supported by instructions l32i/s32i, resulting in
ICE at a stage when access to the object is split into access to its
subwords:
drivers/staging/rtl8188eu/core/rtw_ap.c:445:1:
internal compiler error: in change_address_1, at emit-rtl.c:2126
Fixes: https://lkml.org/lkml/2017/9/10/151
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
- Glibc configure args and tuple need adjustment on SuperH
- Only allow "both endian" and "with CPU" for unspecified arch
variant. May reconsider endianness (was breaking things before
adjusting glibc tuple)
- Retire non-multilib sample, it should be a subset of the
multilib one now.
Signed-off-by: Alexey Neyman <stilor@att.net>
1. On SuperH, configuring GCC with explicit variant of the CPU
(like "sh4") limits the default set of multilibs to just that CPU
and requires --with-multilib-list to change. Allow for "unspecified"
variant, so that we can defer to GCC to determine the list.
2. Support toolchains with both endiannesses at the same time.
3. Add a SuperH/newlib sample
4. Add more flags processing for uClibc
Signed-off-by: Alexey Neyman <stilor@att.net>
This was previously available in 6c62da4803 but was then removed
in cb7fcbe1ef. Add it back since it will be helpful if the user
wants to hide the crosstool-NG version in the pkgversion.
To get the new version, a defconfig from "ct-ng savedefconfig" or
"ct-ng oldconfig" must be used in combination with "ct-ng menuconfig"
or "ct-ng nconfig".
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Some users (like myself) may want to omit the crosstool-NG version
from the binaries' versioning output, as it can be incredibly long
and not too helpful. Add a config option to disable it. The possible
combinations are as follows:
- crosstool-NG version (default)
- crosstool-NG version - custom toolchain ID
- Custom toolchain ID
- No crosstool-NG version OR custom toolchain ID
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
These were added by GCC in July but these branches are from May. I
suspect that they will be added to at least the 6.x and 7.x branches
but 5.x is EOL from Linaro it seems (as the base GCC version hasn't
been updated in a year and a half). For right now, these are needed.
This was testing on an arm64 build but the patches have fixes for all
supported architectures.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
While here, also consider patched by anything other than "bundled patches"
as per-target sources. Add scary warnings in case of a failure.
Signed-off-by: Alexey Neyman <stilor@att.net>
Binutils 2.29 are more picky about versioning of common symbols.
Fix two offenders in glibc versions as applicable.
Signed-off-by: Alexey Neyman <stilor@att.net>
