mingw: stop using nedmalloc#2104
Open
dscho wants to merge 1 commit intogitgitgadget:masterfrom
Open
Conversation
The vendored nedmalloc allocator under compat/nedmalloc/ has been unmaintained upstream for a very long time: the original repository at https://github.com/ned14/nedmalloc received its last commit on July 5, 2014, and was archived (made read-only) by its owner on March 15, 2019. Our copy has been carried forward unchanged ever since. The Git for Windows commit that introduced mimalloc as a replacement on Windows ("mingw: use mimalloc", 2019-06-24, present in the Git for Windows branch thicket but not upstream) already observed at that time that nedmalloc had ceased to see any updates for several years. This came to a head when the Git for Windows SDK upgraded to GCC 16: the `add_segment()` function in `compat/nedmalloc/malloc.c.h` declares `int nfences = 0` and only references it inside an `assert()`, which GCC 16 now flags as `-Wunused-but-set-variable`. Combined with the `-Werror` enabled by `DEVELOPER=1`, this turns into a hard build failure: compat/nedmalloc/malloc.c.h: In function 'add_segment': compat/nedmalloc/malloc.c.h:3897:7: error: variable 'nfences' set but not used [-Werror=unused-but-set-variable=] 3897 | int nfences = 0; | ^~~~~~~ cc1.exe: all warnings being treated as errors The same source built without complaint under GCC 15.2.0; the regression was bisected to the SDK package update at git-for-windows/git-sdk-64@188d93dd455 (`mingw-w64-x86_64-gcc 15.2.0-14 -> 16.1.0-1`), with the failing CI run captured at https://github.com/git-for-windows/git-sdk-64/actions/runs/25244795074. Rather than patch the unmaintained vendored sources to silence the warning, stop opting into nedmalloc altogether on MINGW. The platform allocator is what every non-MINGW build already uses, and a fresh build of git.git's master against a minimal Git for Windows SDK upgraded to GCC 16, with `USE_NED_ALLOCATOR` removed from the MINGW section, completes successfully. The compat/nedmalloc/ subtree itself is left in place to keep this change minimal; nothing in the build links against it any longer, so it can be removed in a follow-up if desired. Assisted-by: Claude Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Member
Author
|
/submit |
|
Submitted as pull.2104.git.1777811392756.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Patrick Steinhardt wrote on the Git mailing list (how to reply to this email): On Sun, May 03, 2026 at 12:29:52PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> Rather than patch the unmaintained vendored sources to silence the
> warning, stop opting into nedmalloc altogether on MINGW. The platform
> allocator is what every non-MINGW build already uses, and a fresh
> build of git.git's master against a minimal Git for Windows SDK
> upgraded to GCC 16, with `USE_NED_ALLOCATOR` removed from the MINGW
> section, completes successfully.
>
> The compat/nedmalloc/ subtree itself is left in place to keep this
> change minimal; nothing in the build links against it any longer, so
> it can be removed in a follow-up if desired.
I guess this is fair as an intermediate step. But seeing that this
removes the last user per our "config.mak.uname" I do wonder whether we
want to maybe drop nedmalloc completely. Not necessarily in this patch,
but maybe in a subsequent step?
Thanks!
Patrick |
|
User |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Git for Windows' SDK wants to update GCC to v16. Since it is used in the CI builds also of the git/git repository, it is crucial that GCC can compile even the latter all right, but currently it does not, see https://github.com/git-for-windows/git-sdk-64/actions/runs/25244795074.
Git for Windows switched away from nedmalloc to mimalloc a long time ago, anyway. I plan on upstreaming this soon-ish, after this here patch lands.
Note that with this patch, I reverse the order I indicated in https://lore.kernel.org/git/00fd3145-b3d2-ddab-466d-d06fd27298ec@gmx.de/: I first disable nedmalloc for
MINGWbuilds (and possibly drop the vendored-in nedmalloc from Git's source code). The reason is that I am still trying to figure out the best way to integratemimalloc: git-for-windows@d67535b61dd (Import the source code of mimalloc v2.2.7, 2026-01-16) in patch form would weigh some ~700kB, which would not only be rejected by the Git mailing list, but which I myself would reject if I was the Git maintainer merely on the basis of the sheer size of the patch. Probably the best course of action is to add support for a non-vendored-inmimallocfirst, then keep the vendored-in copy in Git for Windows (where no mailing list stands in the way of large patches). Whatever it will be, it's best to fast-track this here patch to disable nedmalloc for Windows builds, so that the CI builds can switch to using GCC 16 (and the current Git for Windows SDK) on Windows.cc: Patrick Steinhardt ps@pks.im