summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* rts: Don't clear cards of zero-length arrayswip/T21962Ben Gamari2022-08-063-1/+16
| | | | | Fix #21962, where attempting to clear the card table of a zero-length array resulted in an integer underflow.
* Allow stat increases for GHC 9.2ghc-9.2.4-releasewip/9.2.4-backports-2Zubin Duggal2022-07-270-0/+0
| | | | | | Metric Increase: T13701 T14697
* Add release notes for 9.2.4Zubin Duggal2022-07-272-0/+142
|
* exprIsDeadEnd: Use isDeadEndAppSig to check if a function appliction is ↵Andreas Klebinger2022-07-273-7/+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 edb81f4ed82e6317b03a0c540e1adca194da38d7)
* 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)
* 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)
* Add test for #21865 to ensure that -Wunicode-bidirectional-format-characters ↵Zubin Duggal2022-07-264-1/+12
| | | | is on by default
* Fix #21865 by adding -Wunicode-bidirectional-format-characters to default ↵Zubin Duggal2022-07-261-1/+2
| | | | | | | warnings. The previous backport in 0255ef38b1bb0d4f3608bf92ebc8a93955ccb30a was flawed because it left this out.
* Make keepAlive# out-of-lineBen Gamari2022-07-267-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 (cherry picked from commit d75c540d439510491b45f64c1113762dcb251ae1) (cherry picked from commit 45a5ce96ccb1f4931205d5aba0733a2ef7efbaf5)
* testsuite: Skip a few tests as in the nonmoving collectorBen Gamari2022-07-263-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)
* rts/nonmoving: Don't scavenge objects which weren't evacuatedBen Gamari2022-07-263-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)
* rts/nonmoving: Track segment stateBen Gamari2022-07-262-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)
* testsuite: introduce nonmoving_thread_sanity wayBen Gamari2022-07-261-0/+4
| | | | (cherry picked from commit 19f8fce3659de3d72046bea9c61d1a82904bc4ae)
* Bump haddock submoduleZubin Duggal2022-07-261-0/+0
|
* Add record-dot-syntax testColten Webb2022-07-264-2/+94
| | | | (cherry picked from commit 89d169ec0c4e9c1e6cf4a6373a1992dad7474d55)
* Compute record-dot-syntax typesColten Webb2022-07-261-1/+1
| | | | | | | Ensures type information for record-dot-syntax is included in HieASTs. See #21797 (cherry picked from commit 5434d1a355e127d44c6f116b4b7f8a1d254815d4)
* Bump base to 4.16.3.0 and add changelogZubin Duggal2022-07-2615-18/+26
|
* Bump version to GHC 9.2.4Zubin Duggal2022-07-261-1/+1
|
* configure: Don't attempt to override linker on DarwinBen Gamari2022-07-261-1/+8
| | | | | | | | | | | | | | | | | | Configure's --enable-ld-override functionality is intended to ensure that we don't rely on ld.bfd, which tends to be slow and buggy, on Linux and Windows. However, on Darwin the lack of sensible package management makes it extremely easy for users to have awkward mixtures of toolchain components from, e.g., XCode, the Apple Command-Line Tools package, and homebrew. This leads to extremely confusing problems like #21712. Here we avoid this by simply giving up on linker selection on Darwin altogether. This isn't so bad since the Apple ld64 linker has decent performance and AFAICT fairly reliable. Closes #21712. (cherry picked from commit bde65ea90ed61696eefc93c83efddf7af68d413e)
* winio: make consoleReadNonBlocking not wait for any events at all.Tamar Christina2022-07-261-9/+30
| | | | (cherry picked from commit fa59223b05e24d6e477e3ab0ab296e32b2b65a8b)
* Fix potential space leak that arise from ModuleGraphs retaining referencesZubin Duggal2022-07-261-2/+2
| | | | | | | | to previous ModuleGraphs. This manifests in particular in `extendMG`. This patch is a backport of !8579 (cherry picked from commit 68e1e1842140c783542bcfdcd49cef538c6ab13d)
* Allow CApi FFI calls in GHCiMatthew Pickering2022-07-265-1/+12
| | | | | | | | | | At some point in the past this started working. I noticed this when working on multiple home units and couldn't load GHC's dependencies into the interpreter. Fixes #7388 (cherry picked from commit be3750a5a3cbc59a7b84f1f7603f308aee1cc80b)
* Add DeepSubsumption09Zubin Duggal2022-07-262-0/+11
| | | | (cherry picked from commit 918620d9e2f9e4a0122c57d7fdddbe34626f34b0)
* Fix the interaction of operator sections and deep subsumptionSimon Peyton Jones2022-07-263-8/+53
| | | | | | Fixes DeepSubsumption08 (cherry picked from commit 5e93a9521fc2220ee6f4f150c6681f84f33a2134)
* Add DeepSubsumption08Matthew Pickering2022-07-262-0/+17
| | | | (cherry picked from commit 671899858585376dcbbbdc3740dad4b8ec7b6a70)
* Add tests that -XHaskell98 and -XHaskell2010 enable DeepSubsumptionMatthew Pickering2022-07-264-1/+29
| | | | (cherry picked from commit 5c4fbaf53f258d64aeb66a8172e13dc559eb8d8b)
* Accept testsuite output for DeepSubsumptionZubin Duggal2022-07-2619-7/+71
|
* Fix tcSplitNestedSigmaTysMatthew Pickering2022-07-264-26/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When I did the shallow-subusmptuion patch commit 2b792facab46f7cdd09d12e79499f4e0dcd4293f Date: Sun Feb 2 18:23:11 2020 +0000 Simple subsumption I changed tcSplitNestedSigmaTys to not look through function arrows any more. But that was actually an un-forced change. This function is used only in * Improving error messages in GHC.Tc.Gen.Head.addFunResCtxt * Validity checking for default methods: GHC.Tc.TyCl.checkValidClass * A couple of calls in the GHCi debugger: GHC.Runtime.Heap.Inspect all to do with validity checking and error messages. Acutally its fine to look under function arrows here, and quite useful a test DeepSubsumption05 (a test motivated by a build failure in the `lens` package) shows. The fix is easy. I added Note [tcSplitNestedSigmaTys]. (cherry picked from commit 936fe7435d9da63f78c032b027179e1f1f22a482) (cherry picked from commit 58ad696d42316b1a89a3ce8324218a0ad7257b8e) (cherry picked from commit dc27e15a76486b1ebd27a77f8515044c2671e22d)
* Implement DeepSubsumptionSimon Peyton Jones2022-07-2630-191/+788
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This MR adds the language extension -XDeepSubsumption, implementing GHC proposal #511. This change mitigates the impact of GHC proposal The changes are highly localised, by design. See Note [Deep subsumption] in GHC.Tc.Utils.Unify. The main changes are: * Add -XDeepSubsumption, which is on by default in Haskell98 and Haskell2010, but off in Haskell2021. -XDeepSubsumption largely restores the behaviour before the "simple subsumption" change. -XDeepSubsumpition has a similar flavour as -XNoMonoLocalBinds: it makes type inference more complicated and less predictable, but it may be convenient in practice. * The main changes are in: * GHC.Tc.Utils.Unify.tcSubType, which does deep susumption and eta-expanansion * GHC.Tc.Utils.Unify.tcSkolemiseET, which does deep skolemisation * In GHC.Tc.Gen.App.tcApp we call tcSubTypeNC to match the result type. Without deep subsumption, unifyExpectedType would be sufficent. See Note [Deep subsumption] in GHC.Tc.Utils.Unify. * There are no changes to Quick Look at all. * The type of `withDict` becomes ambiguous; so add -XAllowAmbiguousTypes to GHC.Magic.Dict * I fixed a small but egregious bug in GHC.Core.FVs.varTypeTyCoFVs, where we'd forgotten to take the free vars of the multiplicity of an Id. (cherry picked from commit 7b9be6c8b94b3c2eb3441febb4a8005a03fa34a5) (cherry picked from commit 71f740097af92b0ba441154736a21484fce5d0bb) (cherry picked from commit dc27e15a76486b1ebd27a77f8515044c2671e22d)
* Allow metric increases for 9.2.3wip/9.2.4-backportsZubin Duggal2022-07-140-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Minor metric increases because baseline commit is from a release pipeline ------------------------- Metric Decrease: haddock.Cabal haddock.base haddock.compiler Metric Increase: ManyAlternatives ManyConstructors Naperian parsing001 T10421 T12150 T12227 T12234 T12545 T12707 T13035 T13056 T13253 T13379 T13719 T14683 T14697 T15164 T16577 T18140 T18223 T18282 T18304 T18698a T18698b T18923 T1969 T20049 T3294 T4801 T5030 T5321FD T5321Fun T5631 T5642 T6048 T783 T9203 T9630 T9675 T9872a T9872b T9872c T9872d T9961 WWRec
* Fix combination of ArityType in andArityTypeMatthew Pickering2022-07-143-22/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When combining the ArityType of two case branches we need to make the conservative decision to Before this patch `\1. T` when combined with `T` would result in `\1. T`, the result being that we would then eta-expand the branch of type `T` (even though we concluded it wasn't necessarily safe to do so). In particular, this goes wrong when the branch contains a call to a join point, if we decide to eta-expand it anyway then the join-point gets oversatured. This is a bit of latent bug which was only triggered quite indirectly by inserting cost-centres but seems like it could have happened in other scenarios. Therefore the correct result of combining `\1. T` and `T` is the conservative `T`. This patch corrects the logic in `andArityType` to produce that result. Fixes #21694 ------------------------- Metric Increase: ManyAlternatives ManyConstructors MultiComponentModules MultiComponentModulesRecomp MultiLayerModules MultiLayerModulesRecomp T10421 T12425 T12707 T13035 T13379 T13701 T14683 T15703 T16875 T1969 T3064 T3294 T4801 T5321FD T5321Fun T5631 T783 T9020 T9198 T9233 T9961 ------------------------- (cherry picked from commit 07e7d0fd84662074ce73ed0d5e19ffe849a7aa36)
* Allow passing -po outside profiling wayTeo Camarasu2022-07-141-0/+17
| | | | | | | Resolves #21455 (cherry picked from commit 3e1e5ee3307fe7ea47e70a07a385b56536413f64) (cherry picked from commit babfd40ded288d4758ca9ac505385b1ac6cb1187)
* Add test for T21455Teo Camarasu2022-07-142-0/+6
| | | | | (cherry picked from commit 26e16e611ccfdbe8450f4b3ffac3182e698e1351) (cherry picked from commit 3a3c3bfd2abed133f5c3281d8b185906b5712fdd)
* add test case for #21446Teo Camarasu2022-07-143-0/+12
| | | | | (cherry picked from commit 376088dd91123b64947eb376f9c3db23117f293d) (cherry picked from commit 8bc4b57fe328f7828a7d69c55aa151079359e06c)
* Respect -po when heap profiling (#21446)Teo Camarasu2022-07-141-15/+21
| | | | | (cherry picked from commit 89a413182c9709b239106b40b1d6c8b20a214a21) (cherry picked from commit 4b9af020ffa0077983c7952fd27114e47253a6ea)
* 9.2: Fix -Werror=unrecognised-warning-flagsMatthew Pickering2022-07-1441-76/+82
| | | | | | | The code path was failing to check if the errors had been turned into fatal errors. (cherry picked from commit 6edf34e41bffcd0bed61629f8c215465d866fdcc)
* testsuite: Add test for #21624Ben Gamari2022-07-143-0/+14
| | | | | | Ensuring that mulIntMayOflo# behaves as expected. (cherry picked from commit 26745006bdecc2d269fd8252b189650d6bd7ac10)
* replace quadratic nub to fight byte code gen perf explosionTorsten Schmits2022-07-141-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Despite this code having been present in the core-to-bytecode implementation, I have observed it in the wild starting with 9.2, causing enormous slowdown in certain situations. My test case produces the following profiles: Before: ``` total time = 559.77 secs (559766 ticks @ 1000 us, 1 processor) total alloc = 513,985,665,640 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc ticks bytes elem_by Data.OldList libraries/base/Data/OldList.hs:429:1-7 67.6 92.9 378282 477447404296 eqInt GHC.Classes libraries/ghc-prim/GHC/Classes.hs:275:8-14 12.4 0.0 69333 32 $c>>= GHC.Data.IOEnv <no location info> 6.9 0.6 38475 3020371232 ``` After: ``` total time = 89.83 secs (89833 ticks @ 1000 us, 1 processor) total alloc = 39,365,306,360 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc ticks bytes $c>>= GHC.Data.IOEnv <no location info> 43.6 7.7 39156 3020403424 doCase GHC.StgToByteCode compiler/GHC/StgToByteCode.hs:(805,1)-(1054,53) 2.5 7.4 2246 2920777088 ``` (cherry picked from commit 25b510c3ffdb6f43695c31c0740a5cbe1b7f3898)
* winio: Add support to console handles to handleToHANDLETamar Christina2022-07-141-3/+5
| | | | (cherry picked from commit 31c214cc9d3873b7d1bf4751700cc6c7da09e11d)
* testsuite: Add test for #20735Ben Gamari2022-07-144-0/+64
| | | | (cherry picked from commit c006ac0d1454119f0b456a00ff2416831c955e99)
* CmmToAsm/AArch64: Sign-extend narrow C argumentsBen Gamari2022-07-141-2/+14
| | | | | | | | | | The AArch64/Darwin ABI requires that function arguments narrower than 32-bits must be sign-extended by the caller. We neglected to do this, resulting in #20735. Fixes #20735. (cherry picked from commit 696d64c347364ce75e23d37884ec0bd2543b0a6a)
* CmmToAsm/AArch64: Re-format argument handling logicBen Gamari2022-07-141-5/+19
| | | | | | Previously there were very long, hard to parse lines. Fix this. (cherry picked from commit 70f0c1f84213f7a09bc31e0eeefb5b089708f04b)
* -ddump-llvm shouldn't imply -fllvmBen Gamari2022-07-144-3/+7
| | | | | | | | | | Previously -ddump-llvm would change the backend used, which contrasts with all other dump flags. This is quite surprising and cost me quite a bit of time. Dump flags should not change compiler behavior. Fixes #21776. (cherry picked from commit df762ae9e2d5263fb71f6df38323ac3ca400cc47)
* Mark AArch64/Darwin as requiring sign-extensionBen Gamari2022-07-111-0/+5
| | | | | | | | | Apple's AArch64 ABI requires that the caller sign-extend small integer arguments. Set platformCConvNeedsExtension to reflect this fact. Fixes #21773. (cherry picked from commit 57a5f88cf70ec6dd65ff4a2df0c11805ec1db018)
* Use correct arch for the FreeBSD triple in gen-data-layout.shGleb Popov2022-07-111-1/+1
| | | | | | | Downstream bug for reference: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261798 Relevant upstream issue: #15718 (cherry picked from commit c7f9f6b547f502a20602ea33fdef893367efe476)
* configure: Hide spurious warning from ldBen Gamari2022-07-111-1/+1
| | | | | | | | Previously the check_for_gold_t22266 configure check could result in spurious warnings coming from the linker being blurted to stderr. Suppress these by piping stderr to /dev/null. (cherry picked from commit cdc75a1fedfa3c0f6b3fb365247e7fbc53b9147b)
* hadrian: Run xattr -rc . on bindist tarballBen Gamari2022-07-111-0/+9
| | | | | | Fixes #21506. (cherry picked from commit aa9d9381e5c5d7b96966d817372085897585ecdd)
* hadrian: Fix race involving empty package databasesMatthew Pickering2022-07-113-5/+18
| | | | | | | | | | | | | | | | | | There was a small chance of a race occuring between the small window of 1. The first package (.conf) file get written into the database 2. hadrian calling "ghc-pkg recache" to refresh the package.conf file In this window the package database would contain rts.conf but not a package.cache file, and therefore if ghc was invoked it would error because it was missing. To solve this we call "ghc-pkg recache" at when the database is created by shake by writing the stamp file into the database folder. This also creates the package.cache file and so avoids the possibility of this race. (cherry picked from commit 8ca7ab81b4f2344116646f849843e8b0fc6fd4b7)
* rts: gc stats: account properly for copied bytes in sequential collectionsDouglas Wilson2022-07-111-0/+7
| | | | | | | | | | | | | We were not updating the [copied,any_work,scav_find_work, max_n_todo_overflow] counters during sequential collections. As well, we were double counting for parallel collections. To fix this we add an `else` clause to the `if (is_par_gc())`. The par_* counters do not need to be updated in the sequential case because they must be 0. (cherry picked from commit eb0431489144effd6931c248801af3fe65227368)
* Add test for T21682Matthew Pickering2022-07-112-0/+4
| | | | | | Fixes #21682 (cherry picked from commit f1d5aaa8888f21ed5351929af36cab3770397115)
View Lorry Controller Status