fixes github issue #194 - failure of cowpatch causes 0001-musl.diff
to be applied to a shadow copy of the tree, instead of where gcc
looks for the files.
fix analoguous to 91bdb320f1
closes github issue #189 (gcc 11.4.0 fails to build)
and #190 with a backported fix that's now integrated.
fixes build with a host gcc14's more restrictive default
settings.
building any of i?86, x86_64, and x32 targets on a *musl* host with a
recent gcc host version (in my testing gcc 11), fails due to attempt
to convert a pointer type (nullptr_t) implicitly to bool.
the issue affects the 3 supported gcc versions 5.3.0, 6.5.0 and 7.5.0.
these were added when arm fdpic support was upstreamed in gcc. one patch
was just entirely wrong (broke arm init/fini arrays, gcc pr#114158) and
the other put arm-specific unwind logic in place for all fdpic targets
and broke building of the unwinder code.
this directory uses relative pathnames to access libgcc unwind
headers, but with cowpatch, those are relative to the libstdc++-v3
directory in the unpatched tree unless libstdc++-v3 has been
cow-split.
this calls for a general solution at some point, but for now, just add
an explicit dummy patch to trigger cow splitting.
this is a critical wrong-codegen bug in gcc 9 and 10 that can have
security impact, and oddly the fix still does not seem to have been
backported, so just disable builtin memcmp expansion entirely until
there's a known-good fix.
the 60840 fpu and later, and coldfire fpus, have precision-specific
sqrt instructions that get used and do the right thing. only when
targeting baseline (or near-baseline) ISA does the ld80-only
instruction get used, and that's all that needs to be suppressed.
gcc pr 95921. the m68k sqrt rtl handles excess precision wrong. I
couldn't figure out how to make gcc generate the insn only for long
double, but since long double usage is rare anyway, just remove it.
this can be replaced with a proper fix later if there's ever one
upstream.
reportedly the vdso version of clock_gettime64 produces erratic
results on arm with linux 5.6, and earlier versions did not have the
vdso function at all. it's not clear what the eventual upstream
solution will be, but something needs to be done so as not to be
producing binaries that seem to work now but will break fantastically
when moving to newer kernels.
previously this was missed because there's target-specific spec magic
for a few targets to do it, but many including arm don't have it.
without this, use of -static-pie produces broken binaries which lack
an interpreter but link to shared libraries on the targets affected.
use of -static -pie (preferred form) is not affected. gcc versions
prior to 8.x did not have -static-pie (because there was no upstream
static pie support) so this patch is only needed for 8+, and only to
prevent breakage if someone uses the -static-pie option instead of
-static with -pie.
these are needed for time64 compatibility, and are backported from the
y2038-endgame kernel branch and squashed with non-uapi changes
removed.
with just these patches applied the kernel will not build since
changes at the source level are also needed. but it is not practical
to backport source changes to an old kernel, and even if it were, it
would not make sense to include irrelevant changes that need rebasing
in a patchset intended only for the purpose of uapi header
installation.
forward-ported from the now-removed 4.4.10 patch, needed to fix#8,
spurious dependency on host elf.h header. I checked x86 and mips which
seem to be the only archs with archscripts rules, and these rules have
nothing to do with building headers, so omitting them should still be
safe.
this is binutils issue 23825, but it's caused by gcc using local-exec
model rather than initial-exec model with the intent of making
binutils generate copy relocations. this is harmful, unnecessary, and
not presently supported by musl (and probably should never be). patch
taken from https://github.com/riscv/riscv-gcc/pull/118.
new patch: 0017-c++-abi-break.diff fixes a C++ ABI break regression.
0010-static-pie-support.diff was removed as it doesn't apply anymore,
and forward-porting it requires arcane knowledge of GCC details.
the patches 0018 and 0019 have been copied from GCC 7.3.0. the static
pie patch from GCC 6.4.0, renumbered 0020, depends on the reversions
they make.