summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Bump containers submodule to 0.6.6wip/dougwilson/ghc-9.4/bump-containers-0.6.6wip/bump-containersDouglas Wilson2022-08-023-2/+3
|
* Update submodule Cabal to tag Cabal-v3.8.1.0Douglas Wilson2022-07-284-3/+3
|
* hadrian: also include boot-generated files only needed for makesternenseemann2022-07-281-0/+40
| | | | | | | | | | | | | | | | For some libraries the `boot` script generates a `ghc.mk` and `GNUmakefile` which is required for the make build system. We also should include these files in the source-dist to save make users from having to run the `./boot.source` script in the tarball (which confusingly has a different name to previous GHC releases, thanks to hadrian). With this change, the source-dist should be on parity with GHC 9.2.2 and earlier releases again after the regression in GHC 9.2.3. Closes #21626. (cherry picked from commit 90ccdb9c84fe7133244d661766f1aa7a29a94a72)
* Fix since annotations in GHC.Stack.CloneStackMatthew Pickering2022-07-281-5/+5
| | | | | | Fixes #21894 (cherry picked from commit abd62256ea2fb78990ee83464abc7e2a291a7731)
* Update 9.4 release notes regarding withDictKrzysztof Gogolewski2022-07-282-15/+18
| | | | | | The type was changed in !8249 and this was backported to 9.4. (cherry picked from commit b0d98619a3bc01246bd5b23e6d4afb340df46150)
* rts/ProfHeap: Ensure new Censuses are zeroedBen Gamari2022-07-271-0/+1
| | | | | | | | | | When growing the Census array ProfHeap previously neglected to zero the new part of the array. Consequently `freeEra` would attempt to free random words that often looked suspiciously like pointers. Fixes #21880. (cherry picked from commit e2f0094c315746ff15b8d9650cf318f81d8416d7)
* testsuite: Skip a few tests as in the nonmoving collectorBen Gamari2022-07-273-4/+18
| | | | | | | | | | Residency monitoring under the non-moving collector is quite conservative (e.g. the reported value is larger than reality) since otherwise we would need to block on concurrent collection. Skip a few tests that are sensitive to residency. (cherry picked from commit 6880e4fbf728c04e8ce83e725bfc028fcb18cd70) (cherry picked from commit 25c24535ad51aa22b9cae425c6ac4ad9a8f1e1e9)
* rts/nonmoving: Don't scavenge objects which weren't evacuatedBen Gamari2022-07-273-5/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a rather subtle bug in the logic responsible for scavenging objects evacuated to the non-moving generation. In particular, objects can be allocated into the non-moving generation by two ways: a. evacuation out of from-space by the garbage collector b. direct allocation by the mutator Like all evacuation, objects moved by (a) must be scavenged, since they may contain references to other objects located in from-space. To accomplish this we have the following scheme: * each nonmoving segment's block descriptor has a scan pointer which points to the first object which has yet to be scavenged * the GC tracks a set of "todo" segments which have pending scavenging work * to scavenge a segment, we scavenge each of the unmarked blocks between the scan pointer and segment's `next_free` pointer. We skip marked blocks since we know the allocator wouldn't have allocated into marked blocks (since they contain presumably live data). We can stop at `next_free` since, by definition, the GC could not have evacuated any objects to blocks above `next_free` (otherwise `next_free wouldn't be the first free block). However, this neglected to consider objects allocated by path (b). In short, the problem is that objects directly allocated by the mutator may become unreachable (but not swept, since the containing segment is not yet full), at which point they may contain references to swept objects. Specifically, we observed this in #21885 in the following way: 1. the mutator (specifically in #21885, a `lockCAF`) allocates an object (specifically a blackhole, which here we will call `blkh`; see Note [Static objects under the nonmoving collector] for the reason why) on the non-moving heap. The bitmap of the allocated block remains 0 (since allocation doesn't affect the bitmap) and the containing segment's (which we will call `blkh_seg`) `next_free` is advanced. 2. We enter the blackhole, evaluating the blackhole to produce a result (specificaly a cons cell) in the nursery 3. The blackhole gets updated into an indirection pointing to the cons cell; it is pushed to the generational remembered set 4. we perform a GC, the cons cell is evacuated into the nonmoving heap (into segment `cons_seg`) 5. the cons cell is marked 6. the GC concludes 7. the CAF and blackhole become unreachable 8. `cons_seg` is filled 9. we start another GC; the cons cell is swept 10. we start a new GC 11. something is evacuated into `blkh_seg`, adding it to the "todo" list 12. we attempt to scavenge `blkh_seg` (namely, all unmarked blocks between `scan` and `next_free`, which includes `blkh`). We attempt to evacuate `blkh`'s indirectee, which is the previously-swept cons cell. This is unsafe, since the indirectee is no longer a valid heap object. The problem here was that the scavenging logic *assumed* that (a) was the only source of allocations into the non-moving heap and therefore *all* unmarked blocks between `scan` and `next_free` were evacuated. However, due to (b) this is not true. The solution is to ensure that that the scanned region only encompasses the region of objects allocated during evacuation. We do this by updating `scan` as we push the segment to the todo-segment list to point to the block which was evacuated into. Doing this required changing the nonmoving scavenging implementation's update of the `scan` pointer to bump it *once*, instead of after scavenging each block as was done previously. This is because we may end up evacuating into the segment being scavenged as we scavenge it. This was quite tricky to discover but the result is quite simple, demonstrating yet again that global mutable state should be used exceedingly sparingly. Fixes #21885 (cherry picked from commit 0b27ea23efcb08639309293faf13fdfef03f1060) (cherry picked from commit 54a5c32d9d0792d8f3f80728edf6f39db5321fe5)
* rts/nonmoving: Track segment stateBen Gamari2022-07-272-1/+28
| | | | | | | | | It can often be useful during debugging to be able to determine the state of a nonmoving segment. Introduce some state, enabled by DEBUG, to track this. (cherry picked from commit 40e797ef591ae3122ccc98ab0cc3cfcf9d17bd7f) (cherry picked from commit 4b08797380a0a0a789844c17c6ed1570b62dc119)
* testsuite: introduce nonmoving_thread_sanity wayBen Gamari2022-07-271-0/+4
| | | | | (cherry picked from commit 19f8fce3659de3d72046bea9c61d1a82904bc4ae) (cherry picked from commit 82a0991a73130f2cb70bd8ccaaff30cffd1dd2b0)
* Fix #21889, GHCi misbehaves with Ctrl-C on WindowsZubin Duggal2022-07-274-7/+34
| | | | | | | | | | | | | | | | | | | | | | | | On Windows, we create multiple levels of wrappers for GHCi which ultimately execute ghc --interactive. In order to handle console events properly, each of these wrappers must call FreeConsole() in order to hand off event processing to the child process. See #14150. In addition to this, FreeConsole must only be called from interactive processes (#13411). This commit makes two changes to fix this situation: 1. The hadrian wrappers generated using `hadrian/bindist/cwrappers/version-wrapper.c` call `FreeConsole` if the CPP flag INTERACTIVE_PROCESS is set, which is set when we are generating a wrapper for GHCi. 2. The GHCi wrapper in `driver/ghci/` calls the `ghc-$VER.exe` executable which is not wrapped rather than calling `ghc.exe` is is wrapped on windows (and usually non-interactive, so can't call `FreeConsole`: Before: ghci-$VER.exe calls ghci.exe which calls ghc.exe which calls ghc-$VER.exe After: ghci-$VER.exe calls ghci.exe which calls ghc-$VER.exe (cherry picked from commit 3bbde95769aa2986adb8bef7d718aa0e8731f9fd)
* ghc-cabal: allow Cabal 3.8 to unbreak make buildsternenseemann2022-07-271-2/+2
| | | | | | | | | | | When bootstrapping GHC 9.4.*, the build will fail when configuring ghc-cabal as part of the make based build system due to this upper bound, as Cabal has been updated to a 3.8 release. Reference #21914, see especially https://gitlab.haskell.org/ghc/ghc/-/issues/21914#note_444699 (cherry picked from commit e4bf95920a9bbcb5b6ac3715282c69f612137156)
* hadrian: add flag disabling selftest rules which require QuickChecksternenseemann2022-07-272-3/+18
| | | | | | | | | | | | | | | | | | The hadrian executable depends on QuickCheck for building, meaning this library (and its dependencies) will need to be built for bootstrapping GHC in the future. Building QuickCheck, however, can require TemplateHaskell. When building a statically linking GHC toolchain, TemplateHaskell can be tricky to get to work, and cross-compiling TemplateHaskell doesn't work at all without -fexternal-interpreter, so QuickCheck introduces an element of fragility to GHC's bootstrap. Since the selftest rules are the only part of hadrian that need QuickCheck, we can easily eliminate this bootstrap dependency when required by introducing a `selftest` flag guarding the rules' inclusion. Closes #8699. (cherry picked from commit 42147534320f9ac22f16ffc226148ae553337d2e)
* docs: Fix documentation of \casesSimon Jakobi2022-07-271-3/+3
| | | | | | Fixes #21902. (cherry picked from commit 79f1b0219f5c00f5c8eb7884bd33993bd98680a0)
* user guide: Mention DeepSubsumpion in the release notesBen Gamari2022-07-271-0/+7
|
* bump text submodule to 2.0.1Douglas Wilson2022-07-271-0/+0
|
* Bump directory submodule to 1.3.7.1Ben Gamari2022-07-271-0/+0
|
* Release notes and changelog wibblesBen Gamari2022-07-232-16/+39
|
* exprIsDeadEnd: Use isDeadEndAppSig to check if a function appliction is ↵ghc-9.4.1-rc1Andreas Klebinger2022-07-203-8/+8
| | | | | | | | | | | | | | bottoming. We used to check the divergence and that the number of arguments > arity. But arity zero represents unknown arity so this was subtly broken for a long time! We would check if the saturated function diverges, and if we applied >=arity arguments. But for unknown arity functions any number of arguments is >=idArity. This fixes #21440. (cherry picked from commit 2b2e30203a125dc5bfe70f3df7b39787aaf62b1e)
* driver: Fix implementation of -SMatthew Pickering2022-07-204-14/+27
| | | | | | | | | We were failing to stop before running the assembler so the object file was also created. Fixes #21869 (cherry picked from commit e8c07aa91f0f05816b455457e3781c247b7399ca)
* base: Drop changelog entry for traceWith, et al.Ben Gamari2022-07-201-4/+0
| | | | This won't be introduced until 9.6. Closes #21542.
* rts: Remove explicit timescale for deprecating -h flagMatthew Pickering2022-07-201-2/+2
| | | | | | | | | | We originally planned to remove the flag in 9.4 but there's actually no great rush to do so and it's probably less confusing (forever) to keep the message around suggesting an explicit profiling option. Fixes #21545 (cherry picked from commit 18326ad29b315ed9f086672c38b2c8f611bc7d19)
* testsuite: Add test for #21624Ben Gamari2022-07-203-0/+14
| | | | | | Ensuring that mulIntMayOflo# behaves as expected. (cherry picked from commit 83e0efe12874108cf957ab5cdd49b7da217d3bb8)
* ncg/aarch64: Fix implementation of IntMulMayOfloBen Gamari2022-07-201-1/+41
| | | | | | | | | | The code generated for IntMulMayOflo was previously wrong as it depended upon the overflow flag, which the AArch64 MUL instruction does not set. Fix this. Fixes #21624. (cherry picked from commit 5dcc2c84409c2c3f97198b4116c47e861aafd1fb)
* CmmToAsm/AArch64: Fix syntax of OpRegShift operandsBen Gamari2022-07-201-1/+1
| | | | | | Previously this produced invalid assembly containing a redundant comma. (cherry picked from commit 07c75704f014f62f9ea332319da2e14803263216)
* CmmToAsm/AArch64: Add SMUL[LH] instructionsBen Gamari2022-07-202-2/+8
| | | | | | These will be needed to fix #21624. (cherry picked from commit 70895c3782ecf7dfe12e4534777084344ba2968f)
* cmm: Add surface syntax for MO_MulMayOfloBen Gamari2022-07-201-0/+2
| | | | (cherry picked from commit 6dd8a3ca1d96a662d9a0c19c5b769536fa6472b8)
* Bump deepseq submodule to 1.4.8.0Ben Gamari2022-07-201-0/+0
|
* Bump text submoduleBen Gamari2022-07-201-0/+0
|
* Bump unix submodule to 2.7.3Ben Gamari2022-07-201-0/+0
|
* testsuite: Normalise versions in UnusedPackagesBen Gamari2022-07-202-3/+5
|
* Add dates to base, ghc-prim changelogsBen Gamari2022-07-202-2/+2
|
* Update autoconf scriptsBen Gamari2022-07-202-607/+775
| | | | Scripts taken from autoconf 02ba26b218d3d3db6c56e014655faf463cefa983
* Bump bytestring submodule to 0.11.3.1Ben Gamari2022-07-201-0/+0
|
* testsuite: Fix T11829 on Centos 7Ben Gamari2022-07-201-1/+1
| | | | | | | | It appears that Centos 7 has a more strict C++ compiler than most distributions since std::runtime_error is defined in <stdexcept> rather than <exception>. In T11829 we mistakenly imported the latter. (cherry picked from commit 028f081e4e748794d7a0e6359987ec799c3dc404)
* upload_ghc_libs: Fix path to documentationBen Gamari2022-07-201-1/+1
|
* Add tests that -XHaskell98 and -XHaskell2010 enable DeepSubsumptionMatthew Pickering2022-07-205-1/+30
| | | | (cherry picked from commit 5c4fbaf53f258d64aeb66a8172e13dc559eb8d8b)
* gitlab-ci: Fix hadrian bootstrapping of release pipelinesBen Gamari2022-07-202-3/+11
| | | | | | | | | | | Previously we would attempt to test hadrian bootstrapping in the `validate` build flavour. However, `ci.sh` refuses to run validation builds during release pipelines, resulting in job failures. Fix this by testing bootstrapping in the `release` flavour during release pipelines. We also attempted to record perf notes for these builds, which is redundant work and undesirable now since we no longer build in a consistent flavour.
* Add record-dot-syntax testColten Webb2022-07-194-0/+90
| | | | (cherry picked from commit 89d169ec0c4e9c1e6cf4a6373a1992dad7474d55)
* Compute record-dot-syntax typesColten Webb2022-07-191-0/+1
| | | | | | | Ensures type information for record-dot-syntax is included in HieASTs. See #21797 (cherry picked from commit 5434d1a355e127d44c6f116b4b7f8a1d254815d4)
* Make withDict noinlinesheaf2022-07-165-14/+115
| | | | | | | | | | | | | | | | | | As pointed out in #21575, it is not sufficient to set withDict to inline after the typeclass specialiser, because we might inline withDict in one module and then import it in another, and we run into the same problem. This means we could still end up with incorrect runtime results because the typeclass specialiser would assume that distinct typeclass evidence terms at the same type are equal, when this is not necessarily the case when using withDict. Instead, this patch gives withDict a NOINLINE pragma, to circumvent this issue. This is not entirely satisfactory, as it causes a performance penalty. Hopefully in the future a better fix can be implemented. Fixes #21575 (cherry picked from commit 1bbbbab816a5beda01bf97deb50651263db58ca0)
* Document RuntimeRep polymorphism limitations of catch#, et alBen Gamari2022-07-162-7/+14
| | | | | | | | | As noted in #21868, several primops accepting continuations producing RuntimeRep-polymorphic results aren't nearly as polymorphic as their types suggest. Document this limitation and adapt the `UnliftedWeakPtr` test to avoid breaking this limitation in `keepAlive#`. (cherry picked from commit 3d5f9ba19fea5455d778d2ee9c3fdcaad77d1db7)
* configure: Don't override Windows CXXFLAGSBen Gamari2022-07-161-1/+1
| | | | | | | | | | | | | | | | At some point we used the clang distribution from msys2's `MINGW64` environment for our Windows toolchain. This defaulted to using libgcc and libstdc++ for its runtime library. However, we found for a variety of reasons that compiler-rt, libunwind, and libc++ were more reliable, consequently we explicitly overrode the CXXFLAGS to use these. However, since then we have switched to use the `CLANG64` packaging, which default to these already. Consequently we can drop these arguments, silencing some redundant argument warnings from clang. Fixes #21669. (cherry picked from commit 582bde433879042a42ad8a1862b1c46d6832b00b)
* Make keepAlive# out-of-lineBen Gamari2022-07-167-36/+31
| | | | | | | | | | | | | | | | | | This is a naive approach to fixing the unsoundness noticed in #21708. Specifically, we remove the lowering of `keepAlive#` via CorePrep and instead turn it into an out-of-line primop. This is simple, inefficient (since the continuation must now be heap allocated), but good enough for 9.4.1. We will revisit this (particiularly via #16098) in a future release. Metric Increase: T4978 T7257 T9203 T13701 T14697 (cherry picked from commit d75c540d439510491b45f64c1113762dcb251ae1)
* hadrian: Rename documentation directories for consistency with makeBen Gamari2022-07-156-16/+11
| | | | | | | * Rename `docs` to `doc` * Place pdf documentation in `doc/` instead of `doc/pdfs/` Fixes #21164.
* ghc.mk: fix 'make install' (`mk/system-cxx-std-lib-1.0.conf.install` does ↵Sergei Trofimovich2022-07-151-1/+1
| | | | | | | | | | | | | | | | | | | not exist) before the change `make install` was failing as: ``` "mv" "/<<NIX>>/ghc-9.3.20220406/lib/ghc-9.5.20220625/bin/ghc-stage2" "/<<NIX>>/ghc-9.3.20220406/lib/ghc-9.5.20220625/bin/ghc" make[1]: *** No rule to make target 'mk/system-cxx-std-lib-1.0.conf.install', needed by 'install_packages'. Stop. ``` I think it's a recent regression caused by 0ef249aa where `system-cxx-std-lib-1.0.conf` is created (somewhat manually), but not the .install varianlt of it. The fix is to consistently use `mk/system-cxx-std-lib-1.0.conf` everywhere. Closes: https://gitlab.haskell.org/ghc/ghc/-/issues/21784 (cherry picked from commit 03cc5d0258294fc83f65479e78dbe937622cfc88)
* Change GHCi bytecode return convention for unlifted datatypes.Luite Stegeman2022-07-154-33/+53
| | | | | | | | | | | This changes the bytecode return convention for unlifted algebraic datatypes to be the same as for lifted types, i.e. ENTER/PUSH_ALTS instead of RETURN_UNLIFTED/PUSH_ALTS_UNLIFTED Fixes #20849 (cherry picked from commit fcc964ad5cf7141449ad487102b7c19f0798e73f)
* Suppress extra output from configure check for c++ librariesGreg Steuck2022-07-151-2/+2
| | | | (cherry picked from commit ac6a1a1366d6b9c045b3837c832f7e0fa312d42b)
* Make -fcompact-unwind the defaultMatthew Pickering2022-07-142-8/+11
| | | | | | | | | | This is a follow-up to !7247 (closed) making the inclusion of compact unwinding sections the default. Also a slight refactoring/simplification of the flag handling to add -fno-compact-unwind. (cherry picked from commit 468f919b1bd27d8a58a789a6bb1be4295097388c)
* rts/linker: Ensure that __cxa_finalize is called on code unloadBen Gamari2022-07-142-0/+25
| | | | (cherry picked from commit 443df82ea3e5095b7d25b03c1e8b7dbdb16e3874)
View Lorry Controller Status