Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC Commits: 1ac1a541 by Julian Ospald at 2026-01-09T02:48:53-05:00 Support statically linking executables properly Fixes #26434 In detail, this does a number of things: * Makes GHC aware of 'extra-libraries-static' (this changes the package database format). * Adds a switch '-static-external' that will honour 'extra-libraries-static' to link external system dependencies statically. * Adds a new field to settings/targets: "ld supports verbatim namespace". This field is used by '-static-external' to conditionally use '-l:foo.a' syntax during linking, which is more robust than trying to find the absolute path to an archive on our own. * Adds a switch '-fully-static' that is meant as a high-level interface for e.g. cabal. This also honours 'extra-libraries-static'. This also attempts to clean up the confusion around library search directories. At the moment, we have 3 types of directories in the package database format: * library-dirs * library-dirs-static * dynamic-library-dirs However, we only have two types of linking: dynamic or static. Given the existing logic in 'mungeDynLibFields', this patch assumes that 'library-dirs' is really just nothing but a fallback and always prefers the more specific variants if they exist and are non-empty. Conceptually, we should be ok with even just one search dirs variant. Haskell libraries are named differently depending on whether they're static or dynamic, so GHC can conveniently pick the right one depending on the linking needs. That means we don't really need to play tricks with search paths to convince the compiler to do linking as we want it. For system C libraries, the convention has been anyway to place static and dynamic libs next to each other, so we need to deal with that issue anyway and it is outside of our control. But this is out of the scope of this patch. This patch is backwards compatible with cabal. Cabal should however be patched to use the new '-fully-static' switch. - - - - - ad3c808d by Julian Ospald at 2026-01-09T02:48:53-05:00 Warn when "-dynamic" is mixed with "-staticlib" - - - - - 322dd672 by Matthew Pickering at 2026-01-09T02:49:35-05:00 rts: Use INFO_TABLE_CONSTR for stg_dummy_ret_closure Since the closure type is CONSTR_NOCAF, we need to use INFO_TABLE_CONSTR to populate the constructor description field (this crashes ghc-debug when decoding AP_STACK frames sometimes) Fixes #26745 - - - - - b4e68be0 by Cheng Shao at 2026-01-09T03:22:43-05:00 compiler: make getPrim eagerly evaluate its result This commit makes `GHC.Utils.Binary.getPrim` eagerly evaluate its result, to avoid accidental laziness when future patches build other binary parsers using `getPrim`. - - - - - 775b6d01 by Cheng Shao at 2026-01-09T03:22:43-05:00 compiler: implement fast get/put for Word16/Word32/Word64 Previously, `GHC.Utils.Binary` contains `get`/`put` functions for `Word16`/`Word32`/`Word64` which always loads and stores them as big-endian words at a potentially unaligned address. The previous implementation is based on loads/stores of individual bytes and concatenating bytes with bitwise operations, which currently cannot be fused to a single load/store operation by GHC. This patch implements fast `get`/`put` functions for `Word16`/`Word32`/`Word64` based on a single memory load/store, with an additional `byteSwap` operation on little-endian hosts. It is based on unaligned load/store primops added since GHC 9.10, and we already require booting with at least 9.10, so it's about time to switch to this faster path. - - - - - 533f0210 by Simon Peyton Jones at 2026-01-09T03:22:43-05:00 Fix scoping errors in specialisation Using -fspecialise-aggressively in #26682 showed up a couple of subtle errors in the type-class specialiser. * dumpBindUDs failed to call `deleteCallsMentioning`, resulting in a call that mentioned a dictionary that was not in scope. This call has been missing since 2009! commit c43c981705ec33da92a9ce91eb90f2ecf00be9fe Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Fri Oct 23 16:15:51 2009 +0000 Fixed by re-combining `dumpBindUDs` and `dumpUDs`. * I think there was another bug involving the quantified type variables in polymorphic specialisation. In any case I refactored `specHeader` and `spec_call` so that the former looks for the extra quantified type variables rather than the latter. This is quite a worthwhile simplification: less code, easier to grok. Test case in simplCore/should_compile/T26682, brilliantly minimised by @sheaf. - - - - - 99721d45 by Matthew Craven at 2026-01-09T03:22:44-05:00 Account for "stupid theta" in demand sig for DataCon wrappers Fixes #26748. - - - - - 61 changed files: - compiler/GHC/Core/Opt/Specialise.hs - compiler/GHC/Driver/Backpack.hs - compiler/GHC/Driver/Config/Interpreter.hs - compiler/GHC/Driver/Downsweep.hs - compiler/GHC/Driver/DynFlags.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Driver/Session.hs - compiler/GHC/Linker/Dynamic.hs - compiler/GHC/Linker/Executable.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Linker/Unit.hs - compiler/GHC/Settings.hs - compiler/GHC/Settings/IO.hs - compiler/GHC/StgToJS/Linker/Utils.hs - compiler/GHC/Types/Id/Make.hs - compiler/GHC/Unit/Info.hs - compiler/GHC/Unit/State.hs - compiler/GHC/Utils/Binary.hs - configure.ac - distrib/configure.ac.in - docs/users_guide/phases.rst - ghc/Main.hs - hadrian/cfg/default.host.target.in - hadrian/cfg/default.target.in - hadrian/src/Settings/Builders/Cabal.hs - libraries/ghc-boot/GHC/Unit/Database.hs - libraries/ghc-internal/ghc-internal.buildinfo.in - libraries/ghc-internal/ghc-internal.cabal.in - + m4/fp_linker_supports_verbatim.m4 - m4/prep_target_file.m4 - mk/system-cxx-std-lib-1.0.conf.in - rts/StgMiscClosures.cmm - rts/configure.ac - rts/rts.buildinfo.in - rts/rts.cabal - + testsuite/driver/_elffile.py - testsuite/driver/testglobals.py - testsuite/driver/testlib.py - testsuite/ghc-config/ghc-config.hs - + testsuite/tests/dmdanal/should_run/T26748.hs - + testsuite/tests/dmdanal/should_run/T26748.stdout - testsuite/tests/dmdanal/should_run/all.T - + testsuite/tests/driver/fully-static/Hello.hs - + testsuite/tests/driver/fully-static/Makefile - + testsuite/tests/driver/fully-static/all.T - + testsuite/tests/driver/fully-static/fully-static.stdout - + testsuite/tests/driver/fully-static/test/Test.hs - + testsuite/tests/driver/fully-static/test/test.pkg - + testsuite/tests/driver/mostly-static/Hello.hs - + testsuite/tests/driver/mostly-static/Makefile - + testsuite/tests/driver/mostly-static/all.T - + testsuite/tests/driver/mostly-static/mostly-static.stdout - + testsuite/tests/driver/mostly-static/test/test.c - + testsuite/tests/driver/mostly-static/test/test.h - + testsuite/tests/driver/mostly-static/test/test.pkg - + testsuite/tests/simplCore/should_compile/T26682.hs - + testsuite/tests/simplCore/should_compile/T26682a.hs - testsuite/tests/simplCore/should_compile/all.T - utils/ghc-pkg/Main.hs - utils/ghc-toolchain/exe/Main.hs - utils/ghc-toolchain/src/GHC/Toolchain/Tools/Link.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/48c01fd1f261f3f27a7548dfa0015fb... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/48c01fd1f261f3f27a7548dfa0015fb... You're receiving this email because of your account on gitlab.haskell.org.