Hold back GCC 16 until git.git tolerates it#114
Merged
dscho merged 2 commits intogit-for-windows:mainfrom May 5, 2026
Merged
Conversation
The most recent SDK package update bumped `mingw-w64-{i686,x86_64}-gcc`
and `…-gcc-libs` from 15.2.0-14 to the 16.1.0 series (16.1.0-1 in
commit 188d93d, refined to 16.1.0-2 in commit 2f76f46). GCC 16
made `-Wunused-but-set-variable` more aggressive, and the vendored
nedmalloc allocator under `compat/nedmalloc/` in git.git now trips it
in `add_segment()`, where `int nfences = 0` is only consulted from
inside an `assert()`. Combined with `-Werror` from `DEVELOPER=1`, that
is a hard build failure, which is exactly what the `ci-artifacts`
workflow currently hits when it builds git.git's `master` against the
freshly upgraded SDK; see the failing run at
https://github.com/git-for-windows/git-sdk-64/actions/runs/25359699437
(job `minimal-sdk-artifact`, step "build current `master` of git.git"):
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
make: *** [Makefile:2926: compat/nedmalloc/nedmalloc.o] Error 1
The proper fix lives in git.git, not here: the patch "mingw: stop using
nedmalloc" at
https://lore.kernel.org/git/pull.2104.git.1777811392756.gitgitgadget@gmail.com/
drops the `USE_NED_ALLOCATOR` opt-in on MINGW so the platform allocator
is used instead, mirroring every other build, and verifies that a fresh
build against a GCC 16 SDK then completes cleanly. That patch is still
under review on the Git mailing list, however, and the SDK's CI is red
in the meantime.
Until that patch (or an equivalent) lands in git.git's `master`,
forcefully roll the four affected packages back to 15.2.0-14, the last
GCC 15 release the SDK shipped. The downgrade was performed with
pacman -U \
mingw-w64-x86_64-gcc-libs-15.2.0-14-any.pkg.tar.zst \
mingw-w64-x86_64-gcc-15.2.0-14-any.pkg.tar.zst \
mingw-w64-i686-gcc-libs-15.2.0-14-any.pkg.tar.zst \
mingw-w64-i686-gcc-15.2.0-14-any.pkg.tar.zst
against an otherwise untouched checkout of `main` at 2f76f46,
fetching the `.pkg.tar.zst` archives from `https://repo.msys2.org/`.
A follow-up commit pins these versions in `/etc/pacman.conf` so the
nightly sync workflow does not silently re-introduce the regression.
The whole arrangement is intended to be reverted as soon as the
nedmalloc fix is merged upstream.
Assisted-by: Claude Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The previous commit downgraded `mingw-w64-{i686,x86_64}-gcc{,-libs}`
to 15.2.0-14 because GCC 16's stricter
`-Wunused-but-set-variable` turns the vendored nedmalloc sources in
git.git into an `-Werror` build failure (see that commit's message
and https://github.com/git-for-windows/git-sdk-64/actions/runs/25359699437
for the failing `ci-artifacts` run).
The downgrade alone is not durable: the nightly `sync` workflow runs
`pacman -Suy` against the upstream MSYS2 mirrors, sees that 16.1.0 is
newer than 15.2.0-14, and would happily re-apply the upgrade,
re-breaking CI on the next push. Add an explicit `IgnorePkg` entry for
the four affected packages so `pacman` skips them during sync, and
leave a comment that names the upstream fix at
https://lore.kernel.org/git/pull.2104.git.1777811392756.gitgitgadget@gmail.com/
("mingw: stop using nedmalloc") so whoever revisits this knows the
exact condition under which the hold can be lifted: once that patch
(or an equivalent that removes `USE_NED_ALLOCATOR` on MINGW) has
landed in git.git's `master`, drop the `IgnorePkg` line and let the
next sync run pull GCC 16 in.
Assisted-by: Claude Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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
1 participant
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.
The nightly pacman sync just promoted
mingw-w64-{i686,x86_64}-gccand the matching-gcc-libsfrom 15.2.0-14 to 16.1.0-2, and that broke theci-artifactsworkflow's "build currentmasterof git.git" step. Failing run for reference: https://github.com/git-for-windows/git-sdk-64/actions/runs/25359699437.Root cause is on the git.git side, not in the SDK: GCC 16 tightened
-Wunused-but-set-variableso that a variable read only from inside anassert()no longer counts as used, and withDEVELOPER=1turning warnings into errors,compat/nedmalloc/malloc.c.hfails to compile (theint nfences = 0inadd_segment()is the offender). The proper fix is upstream, where I posted "[PATCH] mingw: stop using nedmalloc" which drops theUSE_NED_ALLOCATORopt-in on MinGW and uses the platform allocator unconditionally; that builds cleanly under a GCC 16 SDK. See https://lore.kernel.org/git/pull.2104.git.1777811392756.gitgitgadget@gmail.com/. It is still in review.In the meantime we need a green CI, hence this SDK-side hold: pin the four packages back to 15.2.0-14 and add them to
IgnorePkgso the next sync does not re-upgrade them. This is explicitly a bridge, not a position on GCC 16, and it should be reverted as soon as the upstream patch lands in git.git'smaster. Anything beyond that (e.g. evaluating other GCC 16 fallout in the SDK, or rebuilding dependents) is deliberately out of scope here.