Simon Peyton Jones pushed to branch wip/T26457 at Glasgow Haskell Compiler / GHC Commits: a4d664c7 by Cheng Shao at 2025-09-29T17:29:22+02:00 compiler/ghci: replace the LoadDLL message with LoadDLLs As a part of #25407, this commit changes the LoadDLL message to LoadDLLs, which takes a list of DLL paths to load and returns the list of remote pointer handles. The wasm dyld is refactored to take advantage of LoadDLLs and harvest background parallelism. On other platforms, LoadDLLs is based on a fallback codepath that does sequential loading. The driver is not actually emitting singular LoadDLLs message with multiple DLLs yet, this is left in subsequent commits. Co-authored-by: Codex <codex@openai.com> - - - - - c7fc4bae by Cheng Shao at 2025-09-29T17:29:22+02:00 driver: separate downsweep/upsweep phase in loadPackages' This commit refactors GHC.Linker.Loader.loadPackages' to be separated into downsweep/upsweep phases: - The downsweep phase performs dependency analysis and generates a list of topologically sorted packages to load - The upsweep phase sequentially loads these packages by calling loadPackage This is a necessary refactoring to make it possible to make loading of DLLs concurrent. - - - - - ab180104 by Cheng Shao at 2025-09-29T17:57:19+02:00 driver: emit single LoadDLLs message to load multiple DLLs This commit refactors the driver so that it emits a single LoadDLLs message to load multiple DLLs in GHC.Linker.Loader.loadPackages'. Closes #25407. ------------------------- Metric Increase: MultiLayerModulesTH_OneShot TcPlugin_RewritePerf ------------------------- Co-authored-by: Codex <codex@openai.com> - - - - - 9c304ec0 by Sean D. Gillespie at 2025-09-29T19:57:07-04:00 Fix SIZED_BIN_OP_TY_INT casts in RTS interpreter Correct `SIZED_BIN_OP_TY_INT` cast to integer. Previously, it cast its second operand as its parameter `ty`. This does not currently cause any issues, since we are only using it for bit shifts. Fixes #26287 - - - - - a1de535f by Luite Stegeman at 2025-09-30T18:40:28-04:00 rts: Fix lost wakeups in threadPaused for threads blocked on black holes The lazy blackholing code in threadPaused could overwrite closures that were already eagerly blackholed, and as such wouldn't have a marked update frame. If the black hole was overwritten by its original owner, this would lead to an undetected collision, and the contents of any existing blocking queue being lost. This adds a check for eagerly blackholed closures and avoids overwriting their contents. Fixes #26324 - - - - - b7e21e49 by Luite Stegeman at 2025-09-30T18:40:28-04:00 rts: push the correct update frame in stg_AP_STACK The frame contains an eager black hole (__stg_EAGER_BLACKHOLE_info) so we should push an stg_bh_upd_frame_info instead of an stg_upd_frame_info. - - - - - 02a7c18a by Cheng Shao at 2025-09-30T18:41:27-04:00 ghci: fix lookupSymbolInDLL behavior on wasm This patch fixes lookupSymbolInDLL behavior on wasm to return Nothing instead of throwing. On wasm, we only have lookupSymbol, and the driver would attempt to call lookupSymbolInDLL first before falling back to lookupSymbol, so lookupSymbolInDLL needs to return Nothing gracefully for the fallback behavior to work. - - - - - aa0ca5e3 by Cheng Shao at 2025-09-30T18:41:27-04:00 hadrian/compiler: enable internal-interpreter for ghc library in wasm stage1 This commit enables the internal-interpreter flag for ghc library in wasm stage1, as well as other minor adjustments to make it actually possible to launch a ghc api session that makes use of the internal interpreter. Closes #26431 #25400. - - - - - 69503668 by Cheng Shao at 2025-09-30T18:41:27-04:00 testsuite: add T26431 test case This commit adds T26431 to testsuite/tests/ghci-wasm which goes through the complete bytecode compilation/linking/running pipeline in wasm, so to witness that the ghc shared library in wasm have full support for internal-interpreter. - - - - - e9445c01 by Matthew Pickering at 2025-09-30T18:42:23-04:00 driver: Load bytecode static pointer entries during linking Previously the entries were loaded too eagerly, during upsweep, but we should delay loading them until we know that the relevant bytecode object is demanded. Towards #25230 - - - - - b8307eab by Cheng Shao at 2025-09-30T18:43:14-04:00 autoconf/ghc-toolchain: remove obsolete C99 check This patch removes obsolete c99 check from autoconf/ghc-toolchain. For all toolchain & platform combination we support, gnu11 or above is already supported without any -std flag required, and our RTS already required C11 quite a few years ago, so the C99 check is completely pointless. - - - - - 9c293544 by Simon Peyton Jones at 2025-10-01T09:36:10+01:00 Fix buglet in GHC.Core.Unify.uVarOrFam We were failing to match two totally-equal types! This led to #26457. - - - - - 33 changed files: - compiler/GHC.hs - compiler/GHC/Cmm/Parser.y - compiler/GHC/Core/Unify.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Make.hs - compiler/GHC/Driver/Plugins.hs - compiler/GHC/Driver/Session.hs - compiler/GHC/Iface/Tidy/StaticPtrTable.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Linker/MacOS.hs - compiler/GHC/Linker/Types.hs - compiler/GHC/Runtime/Interpreter.hs - compiler/GHC/Runtime/Interpreter/Types.hs - configure.ac - distrib/configure.ac.in - hadrian/src/Settings/Packages.hs - libraries/ghci/GHCi/Message.hs - libraries/ghci/GHCi/ObjLink.hs - libraries/ghci/GHCi/Run.hs - m4/fp_cmm_cpp_cmd_with_args.m4 - − m4/fp_set_cflags_c99.m4 - rts/Apply.cmm - rts/Interpreter.c - rts/ThreadPaused.c - + testsuite/tests/ghci-wasm/T26431.hs - + testsuite/tests/ghci-wasm/T26431.stdout - testsuite/tests/ghci-wasm/all.T - testsuite/tests/rts/linker/T2615.hs - + testsuite/tests/typecheck/should_compile/T26457.hs - testsuite/tests/typecheck/should_compile/all.T - utils/ghc-toolchain/src/GHC/Toolchain/Tools/Cc.hs - utils/ghc-toolchain/src/GHC/Toolchain/Tools/Cpp.hs - utils/jsffi/dyld.mjs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/771aaa748c4e0118baa8dd1af46a9ed... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/771aaa748c4e0118baa8dd1af46a9ed... You're receiving this email because of your account on gitlab.haskell.org.