- Apr 03, 2024
-
-
Moves it into the IOManager.c where we can follow the new pattern of switching on the selected I/O manager. Uses a new IOManager API: syncDelay, following the naming convention of sync* for thread-synchronous I/O & timer/delay operations. As part of porting from cmm to C, we maintain the rule that the why_blocked gets accessed using load acquire and store release atomic memory operations. There was one exception to this rule: in the delay# primop cmm code on posix (not win32), the why_blocked was being updated using a store relaxed, not a store release. I've no idea why. In this convesion I'm playing it safe here and using store release consistently.
-
Moves it into the IOManager.c where we can follow the new pattern of switching on the selected I/O manager.
-
-
Using the new IOMGR_ENABLED_<name> CPP defines.
-
Rather than ad-hoc cpp conitionals on THREADED_RTS and mingw32_HOST_OS, we use a style where we switch on the I/O manager impl, with cases for each I/O manager impl.
-
Now instead of it being just used on Windows to select between the WinIO vs the MIO or Win32-legacy I/O managers, it is now used on all platforms for selecting the I/O manager to use. Right now it remains the case that there is only an actual choice on Windows, but that will change later. Document the --io-manager flag in the user guide. This change is also reflected in the RTS flags types in the base library. Deprecate the export of IoSubSystem from GHC.RTS.Flags with a message to import it from GHC.IO.Subsystem. The way the 'IoSubSystem' is detected also changes. Instead of looking at the RTS flag, there is now a C bool global var in the RTS which gets set on startup when the I/O manager is selected. This bool var says whether the selected I/O manager classifies as "native" on Windows, which in practice means the WinIO I/O manager has been selected. Similarly, the is_io_mng_native_p RTS helper function is re-implemented in terms of the selected I/O manager, rather than based on the RTS flags. We do however remove the ./configure --native-io-manager flag because we're bringing the WinIO/MIO/Win32-legacy choice under the new general scheme for selecting I/O managers, and that new scheme involves no ./configure time user choices, just runtime RTS flag choices.
-
In this patch we just define new CPP vars, but don't yet use them or replace the existing approach. That will follow. The intention here is that every I/O manager can be enabled/disabled at GHC build time (subject to some constraints). More than one I/O manager can be enabled to be built. At least one I/O manager supporting the non-threaded RTS must be enabled as well as at least one supporting the non-threaded RTS. The I/O managers enabled here will become the choices available at runtime at RTS startup (in later patches). The choice can be made with RTS flags. There are separate sets of choices for the threaded and non-threaded RTS ways, because most I/O managers are specific to these ways. Furthermore we must establish a default I/O manager for the threaded and non-threaded RTS. Most I/O managers are platform-specific so there are checks to ensure each one can be enabled on the platform. Such checks are also where (in future) any system dependencies (e.g. libraries) can be checked. The output is a set of CPP flags (in the mk/config.h file), with one flag per named I/O manager: * IOMGR_BUILD_<name> : which ones should be built (some) * IOMGR_DEFAULT_NON_THREADED_<name> : which one is default (exactly one) * IOMGR_DEFAULT_THREADED_<name> : which one is default (exactly one) and a set of derived flags in IOManager.h * IOMGR_ENABLED_<name> : enabled for the current RTS way Note that IOMGR_BUILD_<name> just says that an I/O manager will be built for _some_ RTS way (i.e. threaded or non-threaded). The derived flags IOMGR_ENABLED_<name> in IOManager.h say if each I/O manager is enabled in the "current" RTS way. These are the ones that can be used for conditional compilation of the I/O manager code. Co-authored-by:Pi Delport <pi@well-typed.com>
-
This is just a simple refactor that makes exprIsConApp_maybe a little bit more direct, simple, and efficient. Metrics: compile_time/bytes allocated geo. mean -0.1% minimum -2.0% maximum -0.0% Not a big gain, but worthwhile given that the code is, if anything, easier to grok. -
GHC was outright crashing before this fix: #24604
-
h$appendToHsString needs to wrap its argument in an updatable thunk to behave like unpackAppendCString#. Otherwise if a SingleEntry thunk is passed, it is stored as-is in a CONS cell, making the resulting list impossible to deepseq (forcing the thunk doesn't update the contents of the CONS cell)! The added test checks that the optimization kicks in and that h$appendToHsString works as intended. Fix #24495
-
The optimization introducing h$appendToHsString wasn't kicking in anymore (while it did in 9.8.1) because of the changes introduced in #23270 (7e0c8b3b). This patch reenables the optimization by matching on case-expression, as done in Cmm for unpackCString# standard thunks. The test is also T24495 added in the next commits (two commits for ease of backporting to 9.8).
-
Fixes #24562
-
- Apr 02, 2024
-
-
This patch implements refactoring which is a prerequisite to updating kind checking of type patterns. This is a huge simplification of the main worker that checks kind of HsType. It also fixes the issues caused by previous code duplication, e.g. that we didn't add module finalizers from splices in inference mode.
-
- Run TSAN jobs with +thread_sanitizer_cmm which enables Cmm instrumentation as well. - Run TSAN jobs in deb12 which ships gcc-12, a reasonably recent gcc that @bgamari confirms he's using in #GHC:matrix.org. Ideally we should be using latest clang release for latest improvements in sanitizers, though that's left as future work. - Mark TSAN jobs as manual+allow_failure in validate pipelines. The purpose is to demonstrate that we have indeed at least fixed building of TSAN mode in CI without blocking the patch to land, and once merged other people can begin playing with TSAN using their own dev setups and feature branches.
-
-
This commit fixes clang-specific rts compilation errors when compiling with TSAN: - clang doesn't have -Wtsan flag - Fix prototype of ghc_tsan_* helper functions - __tsan_atomic_* functions aren't clang built-ins and sanitizer/tsan_interface_atomic.h needs to be included - On macOS, TSAN runtime library is libclang_rt.tsan_osx_dynamic.dylib, not libtsan. -fsanitize-thread as a link-time flag will take care of linking the TSAN runtime library anyway so remove tsan as an rts extra library
-
This commit fixes rts compilation errors when compiling with TSAN: - xxx_FENCE macros are redefined and trigger CPP warnings. - Use SIZEOF_W. WORD_SIZE_IN_BITS is provided by MachDeps.h which Cmm.h doesn't include by default.
-
This should be `#if defined(TSAN_ENABLED)`, not `#if TSAN_ENABLED`, lest we suffer warnings.
-
- Apr 01, 2024
-
-
- Mar 29, 2024
-
-
Alan Zimmerman authored
This goes slightly against the exact printing philosophy where trailing decorations should be in an annotation, but the practicalities of adding it to the WarningTxt environment, and the problems caused by deviating do not make a more principles approach worthwhile.
-
Fixes #24601.
-
- Mar 27, 2024
-
-
Alan Zimmerman authored
The span was incorrect if opt_datafam_kind_sig was empty
-
The lexer inserts virtual semicolons having zero width. Do not use them to extend the list span of items in a list.
-
`rts/js/config.js`
-
-
For issue #21506, we started cleaning the extended attributes of binaries and libraries from the bindist *after* they were installed to workaround notarisation (#17418), as part of `make install`. However, the `ghc-toolchain` binary that is now shipped with the bindist must be run at `./configure` time. Since we only cleaned the xattributes of the binaries and libs after they were installed, in some situations users would be unable to run `ghc-toolchain` from the bindist, failing at configure time (#24554). In this commit we move the xattr cleaning logic to the configure script. Fixes #24554
-
A user may configure `LDFLAGS` but not `LD`. When choosing a linker, we will prefer `ldd`, then `ld.gold`, then `ld.bfd` -- however, we have to check for a working linker. If either of these fail, we try the next in line. However, we were not considering the `$LDFLAGS` when checking if these linkers worked. So we would pick a linker that does not support the current $LDFLAGS and fail further down the line when we used that linker with those flags. Fixes #24565, where `LDFLAGS=-Wl,-z,pack-relative-relocs` is not supported by `ld.gold` but that was being picked still.
-
- Mar 26, 2024
-
-
-
This commit bumps the libffi-tarballs submodule to libffi 3.4.6, which includes numerous upstream libffi fixes, especially https://github.com/libffi/libffi/issues/760.
-
- Mar 25, 2024
-
-
-
This patch fixes function prototypes in ARMOutlineAtomicsSymbols.h which causes "error: address argument to atomic operation must be a pointer to _Atomic type" when compiling with clang on aarch64.
-
- Mar 23, 2024
-
-
-
When checking if a jump has more than one destination account for the possibility of some jumps not being representable by a BlockId. We do so by having isJumpishInstr return a `Maybe BlockId` where Nothing represents non-BlockId jump destinations. Fixes #24507
-
This hint is outdated, ``Complex Float`` are now specialised, and the heap space suggestion needs more nuance so it should be explained in the unboxed/storable array documentation.
-
This fixes #24553, where GHC unhelpfully said error: [GHC-83865] • Expected kind ‘* -> * -> *’, but ‘Foo’ has kind ‘* -> * -> *’ See Note [Showing invisible bits of types in error messages]
-
Fixes for a bug in desugaring pattern synonyms matches, introduced while working on on expanding `do`-blocks in #18324 The `matchWrapper` unecessarily (and incorrectly) filtered out the default wild patterns in a match. Now the wild pattern alternative is simply ignored by the pm check as its origin is `Generated`. The current code now matches the expected semantics according to the language spec.
-
On 64-bit platforms, every Word32 fits in an Int, so we can convert to Int# without having to perform the overflow check integerFromWord# uses internally.
-
- Mar 22, 2024
-
-
In #24551, we abstracted a string literal binding over a type variable, triggering a CoreLint error when that binding floated to top-level. The solution implemented in this patch fixes this by re-doing dependency analysis on a simplified recursive let binding that is about to be type abstracted, in order to find the minimal set of type variables to abstract over. See wrinkle (AB5) of Note [Floating and type abstraction] for more details. Fixes #24551
-
-
- Use unsafeChr because we know our values to be valid - Remove some unnecessary use of `ord` (return Word8 values directly)
-
