Remove 30k of Itanium demangling from C++ images just to display the
uncaught exception type before aborting. The message is near useless,
and GDB already does this while providing a wealth of information. An
application can still opt-in to the old behavior (including the 30k of
code) at runtime with:
std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
Speaking of GDB, std::terminate calls std::abort, but msvcrt!abort calls
exit() and does not trap. Introduce __gnu_cxx::__trap_terminate_handler
which uses __builtin_trap() instead, and set it as the new default. The
verbose handler also now uses a trap instruction. These changes improve
the debugging experience and better communicate the hard failure.
Closes#215.
Both GMP and MPFR sometimes use the wrong compiler when cross-compiling
unless a compiler is explicitly chosen. GCC now defaults to C23, but the
GMP configure script uses old-style, pre-ANSI function declarations that
were removed in C23.
This extra layer serves no purpose. Removing it flattens out the
directory structure and makes it a little nicer. The mingw32.h patch
will need to be adjusted for GCC 15, as this file was renamed for the
upcoming ARM64 port.
This was supposed to be automatic, but libbacktrace's filetype.awk does
not recognize bigobj COFF (c9c9c07), and the detection failure overrides
--enable-stdcxx-backtrace. To work around it, clobber filetype.awk with
hardcoded output just before cross-compiling GCC.
Note: As of GCC 14.2, <stacktrace> requires linking -lstdc++exp.
Fixes#200.
The build used the host ar instead of the cross ar. With -mbig-obj as
the default (c9c9c073), the host ar cannot understand the PE32 object
files and so doesn't produce a symbol index. Not the first time this
problem has come up.
The ftp.vim.org subdomain is gone, but the server is still up under its
real hostname. No release artifacts prior to 9.0 are hosted at vim.org,
leaving only nluug.nl and its mirrors.
In bfd is a list of known libraries whose symbols are excluded when
exporting all symbols, the default behavior when no exports are chosen,
or with --export-all-symbols. The list is incomplete for w64dk and is
missing 15 additional "standard" libraries.
The result is that Windows-unaware builds using any of these libraries,
including any C++ program due to libpthread, tends to be broken. Instead
of adding each library to the list, blanket-exclude all libraries that
come from the sysroot. Since libpthread is so important, also add it to
the known list. Its absence is essentially a Binutils bug.
This format was introduced in VS 2005, and Binutils began supporting it
for x86-64 in 2013 and i386 in 2020. The format is now 20 years old and
well-established. An increasing amount of software is hitting the old,
meager COFF limitations. Rather than enable bigobj case-by-case, simply
switch to the new format by default.
This reduces compatibility with old linkers, but compatibility between
COFF toolchains has always been iffy. Even ignoring bigobj, Binutils and
MSVC link.exe already have limited object file compatibility for various
reasons.
A significant potential problem with changing the default is that the
Binutils developers didn't have the foresight to also add -mno-big-obj
at the same time, and so any change to the default at the very least
results in a flag day. This change does not introduce -mno-big-obj, so
it is not possible to produce objects in the old format.
An increasing set of llama.cpp build configurations, particularly at
lower optimization levels, go just beyond COFF limitations and require
the "newer" bigobj COFF format in order to build.
It didn't quite work out-of-the-box because it needed server assets and
build-info.cpp. On my system, the generated files were left behind from
an old build, so I didn't notice.
The official llama.cpp CMake build has a bug where build-info.cpp is
generated in the original source tree, not the build directory, and so
concurrent out-of-tree builds race to produce incorrect binaries. This
makefile avoids a conflict by using a unique name.
The original patch, which functioned properly between Bintuils 2.28
(March 2017) and 2.42 (January 2024), was broken by Binutils commit
057a2b4c (June 2024), made just 3 weeks later. Either rotten luck, or
someone's reading over my shoulder!
This GCC bug has had a wide impact since 2008. It affects nearly every
x86 program with a foreign-facing stdcall function, except WinMain and
wWinMain (covered by a CRT special case). That includes callbacks like
WNDPROC and APCs, thread procedures for CreateThread and _beginthreadex,
and entry points like mainCRTStartup and WinMainCRTStartup.
Programs included in w64dk have workarounds as needed, though between
Binutils 2.42 (6bf81ffd) and this patch, they're redundant. But still
needed, of course, when compiled with other Mingw-w64 toolchains.
Some cases are still affected, most commonly _beginthread, whose thread
procedure is _not_ stdcall, but is still called with a stack unsuitably
aligned for GCC. This case is less arguably a GCC bug, though neither
MSVC nor Clang are affected by this issue (due to not assuming 16-byte
stack alignment).
This warning is new in Binutils 2.42, and it regards fixing a long-time,
x86 bfd bug. Previously the fixup did not occur and bfd would fail to
locate decorated symbols. In the case of an entry point, bfd silently
linked the wrong address! It remains silent if the entry point is not
found, but the fixup makes it more likely to find the symbol.
The old, buggy behavior was an accident. It differs from MSVC and nobody
wants it. Theoretically some program might depend on the old behavior,
hence the warning, but it's incredibly unlikely, so silence the warning.
As of 3cacd962, the "known bugs" comment is no longer true for typical
use cases (x64 Windows 10 and later).
The UTF-8 comment came out of abusing GetPrivateProfileStringA. It was
replaced in 568efdcd with a custom parser.
The x86 build supports Windows XP, but the x64 build supports no earlier
than Windows 7 (my personal favorite). Windows XP outright rejects EXEs
with a UTF-8 manifest, but Windows 7 simply ignores it. That permits GCC
to continue operating on Windows 7 with a UTF-8 manifest (as of GCC 13),
which must be disabled entirely in x86 builds for Windows XP. The same
can be done with busybox-w32 by disabling the UTF-8 check and gracefully
degrading to original "ANSI-only" behavior when the manifest is ignored.
UCRT is gradually growing in popularity, and it wasn't obvious from
README.md that w64devkit is a traditional MSVCRT toolchain.
The AVX issue comes up from time to time, just infrequently enough that
I need to rediscover the solution each time. Documentation in README.md
will be easier to find next time, warns those who haven't been bitten
yet, and documents the mitigation offline. Since it is unlikely to be
fixed any time soon, medium term I should figure out a small patch that
makes GCC only emit unaligned AVX moves. The penalty for unaligned moves
is 0% on newer processors and up to 10% on older ones. That's certainly
better than crashing due to a compilier bug.
https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/
