summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Backport fix to #23184 to 9.4wip/23184-9.4Matthew Pickering2023-03-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This backports the fix suggested in #23184 to GHC-9.4 It is from the larger patch (!7861): ``` commit 6656f0165a30fc2a22208532ba384fc8e2f11b46 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Fri Jul 23 23:57:01 2021 +0100 A bunch of changes related to eta reduction This is a large collection of changes all relating to eta reduction, originally triggered by #18993, but there followed a long saga. Specifics: ...lots of lines omitted... Other incidental changes * Fix a fairly long-standing outright bug in the ApplyToVal case of GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the tail of 'dmds' in the recursive call, which meant the demands were All Wrong. I have no idea why this has not caused problems before now. ```
* Add test for T23184Matthew Pickering2023-03-293-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was an outright bug, which Simon fixed in July 2021, as a little side-fix on a complicated patch: ``` commit 6656f0165a30fc2a22208532ba384fc8e2f11b46 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Fri Jul 23 23:57:01 2021 +0100 A bunch of changes related to eta reduction This is a large collection of changes all relating to eta reduction, originally triggered by #18993, but there followed a long saga. Specifics: ...lots of lines omitted... Other incidental changes * Fix a fairly long-standing outright bug in the ApplyToVal case of GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the tail of 'dmds' in the recursive call, which meant the demands were All Wrong. I have no idea why this has not caused problems before now. ``` Note this "Fix a fairly longstanding outright bug". This is the specific fix ``` @@ -3552,8 +3556,8 @@ mkDupableContWithDmds env dmds -- let a = ...arg... -- in [...hole...] a -- NB: sc_dup /= OkToDup; that is caught earlier by contIsDupable - do { let (dmd:_) = dmds -- Never fails - ; (floats1, cont') <- mkDupableContWithDmds env dmds cont + do { let (dmd:cont_dmds) = dmds -- Never fails + ; (floats1, cont') <- mkDupableContWithDmds env cont_dmds cont ; let env' = env `setInScopeFromF` floats1 ; (_, se', arg') <- simplArg env' dup se arg ; (let_floats2, arg'') <- makeTrivial env NotTopLevel dmd (fsLit "karg") arg' ``` Ticket #23184 is a report of the bug that this diff fixes.
* configure: Set RELEASE=NOwip/az/ghc-9.4-epa-backports-2Ben Gamari2022-12-241-1/+1
|
* docs/relnotes: Mention #22561ghc-9.4.4-releasewip/backports-9.4Ben Gamari2022-12-231-0/+1
|
* compiler: Ensure that GHC toolchain is first in search pathBen Gamari2022-12-232-9/+9
| | | | | | | | | As noted in #22561, it is important that GHC's toolchain look first for its own headers and libraries to ensure that the system's are not found instead. If this happens things can break in surprising ways (e.g. see #22561). (cherry picked from commit 8071efc307ba2df7362ff3b96c898afc61addc21)
* gitlab: Reintroduce Fedora 27 jobBen Gamari2022-12-222-1/+195
|
* llvmGen: Fix relaxed orderingBen Gamari2022-12-211-1/+1
| | | | | | | Previously I used LLVM's `unordered` ordering for the C11 `relaxed` ordering. However, this is wrong and should rather use the LLVM `monotonic` ordering. Fixes #22640
* Add 9.4.4 release notesMatthew Pickering2022-12-152-0/+70
|
* Bump version to 9.4.4Matthew Pickering2022-12-151-1/+1
|
* DmdAnal: Don't panic in addCaseBndrDmd (#22039)Sebastian Graf2022-12-153-17/+118
| | | | | | | | | | | | Rather conservatively return Top. See Note [Untyped demand on case-alternative binders]. I also factored `addCaseBndrDmd` into two separate functions `scrutSubDmd` and `fieldBndrDmds`. Fixes #22039. (cherry picked from commit d2be80fd9b222963e8dd09a30f78c106e00da7f9)
* DmdAnal: Reflect the `seq` of strict fields of a DataCon worker (#22475)Sebastian Graf2022-12-159-32/+167
| | | | | | | | | See the updated `Note [Data-con worker strictness]` and the new `Note [Demand transformer for data constructors]`. Fixes #22475. (cherry picked from commit b4cfa8e235715d8c73b2ba0ba05ed8ef92629218)
* rts: Ensure that global regs are never passed as fun call argsBen Gamari2022-12-151-3/+3
| | | | | | | This is in general unsafe as they may be clobbered if they are mapped to caller-saved machine registers. See Note [Register parameter passing]. (cherry picked from commit 9372329008143104b0ae5e8e792e957090dfa743)
* cmm/Parser: Atomic load syntaxBen Gamari2022-12-151-3/+23
| | | | | | | | | Originally I had thought I would just use the `prim` call syntax instead of introducing new syntax for atomic loads. However, it turns out that `prim` call syntax tends to make things quite unreadable. This new syntax seems quite natural. (cherry picked from commit 748490d2ff51d6c6fa44aad587908b271c801fa9)
* cmm/Parser: Add syntax for ordered loads and storesBen Gamari2022-12-153-6/+55
| | | | (cherry picked from commit 6c9862c4fee395345dbbcd8ad58ae3f08753219e)
* cmm/Parser: Reduce some repetitionBen Gamari2022-12-151-29/+20
| | | | (cherry picked from commit 6cc3944a06cc5be302bb023a43c0537838b50861)
* Codegen/x86: Eliminate barrier for relaxed accessesBen Gamari2022-12-151-7/+12
| | | | (cherry picked from commit 8faf74fcbd9d9da81ce8a901d694711c5d7ad406)
* llvm: Respect memory specified orderingsBen Gamari2022-12-151-7/+15
| | | | (cherry picked from commit 43beaa7baf02d75946c37974fbe46d2857920a53)
* cmm: Introduce MemoryOrderingsBen Gamari2022-12-157-22/+34
| | | | (cherry picked from commit 34f6b09c8e985017c4b18896aeac0c20baf4433d)
* cmm: Introduce blockConcatBen Gamari2022-12-152-1/+4
| | | | (cherry picked from commit da7b51d8598400ed8073afe1b311c73a04e2230d)
* Do not strictify a DFun's parameter dictionaries (#22549)Sebastian Graf2022-12-155-44/+113
| | | | | | | | | | | ... thus fixing #22549. The details are in the refurbished and no longer dead `Note [Do not strictify a DFun's parameter dictionaries]`. There's a regression test in T22549. (cherry picked from commit 26e71562072f6740d52fcd38298340c287a641b8)
* Bump Win32 submodule to v2.12.0.1Ben Gamari2022-12-151-0/+0
| | | | | | Addresses #20017 for 9.4.4. (cherry picked from commit 0f63c830abf0778c5b6c073d36dc6377844aa087)
* compiler: Ensure that MutVar operations have necessary barriersBen Gamari2022-12-151-4/+5
| | | | | | | | | Here we add acquire and release barriers in readMutVar# and writeMutVar#, which are necessary for soundness. Fixes #22468. (cherry picked from commit a9834736a90aefdd32cfc15be507e22b57eedc07)
* Package Imports: Get candidate packages also from re-exported modulesMatthew Pickering2022-12-1416-3/+147
| | | | | | | | | | Previously we were just looking at the direct imports to try and work out what a package qualifier could apply to but #22333 pointed out we also needed to look for reexported modules. Fixes #22333 (cherry picked from commit 58a138d0f62c057333e4fd15fe20df64492b1dac)
* Serialize builds of `rts` and `system-cxx-std-lib`wip/mp-9.4-backportsGabriella Gonzalez2022-12-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes https://gitlab.haskell.org/ghc/ghc/-/issues/22099 I cannot say for sure that this will fix the linked issue, but I explained why I believe this fixes the root problem in: https://gitlab.haskell.org/ghc/ghc/-/issues/22099#note_461386 … and when we applied this patch internally the problem appeared to disappear for a few builds in a row with a large number of cores. The short summary of the above comment is that the `Makefile` serializes the package registrations using `ghc-pkgs`, with the exception of two packages (`rts` and `system-cxx-std-lib`) and we expect that this one instance of parallelism that was still left in the `Makefile` was the root cause of the flaky build failure. This fix would be consistent with two known things about the failure: - The build failure only occurs for parallel `Make` builds … and these are the only two `ghc-pkg` calls that run concurrently - The error first appeared in the GHC 9.4 branch and was absent in GHC 9.2 … and GHC 9.4 was the first release that included `system-cxx-std-lib` (as far as I know), which would explain why this problem didn't happen before. The change here forces the two packages to be registered in sequence. This problem will of course go away in GHC 9.6 by virtue of dropping the `make`-based build, but since the GHC 9.4 branch is supported and active we wanted to upstream this patch to the 9.4 development branch.
* Fix a trivial typo in dataConNonlinearTypeSimon Peyton Jones2022-12-136-8/+53
| | | | | | Fixes #22416 (cherry picked from commit 294f907370fadd3313f8c5e6aa87a93c8b86f139)
* Improve stg lint for unboxed sums.Andreas Klebinger2022-12-131-12/+40
| | | | | | | | | It now properly lints cases where sums end up distributed over multiple args after unarise. Fixes #22026. (cherry picked from commit 8d2dbe2db4cc7c8b6d39b1ea64b0508304a3273c)
* Disable some SIMD tests on non-X86 architecturessheaf2022-12-132-2/+4
| | | | (cherry picked from commit f7b7a3122185222d5059e37315991afcf319e43c)
* Cmm Lint: relax SIMD register assignment checksheaf2022-12-132-5/+18
| | | | | | | | | | | | As noted in #22297, SIMD vector registers can be used to store different kinds of values, e.g. xmm1 can be used both to store integer and floating point values. The Cmm type system doesn't properly account for this, so we weaken the Cmm register assignment lint check to only compare widths when comparing a vector type with its allocated vector register. (cherry picked from commit 3be48877e204fca8e5d5ab984186e0d20d81f262)
* Remove SIMD conversionssheaf2022-12-136-72/+76
| | | | | | | | | | | | | This patch makes it so that packing/unpacking SIMD vectors always uses the right sized types, e.g. unpacking a Word16X4# will give a tuple of Word16#s. As a result, we can get rid of the conversion instructions that were previously required. Fixes #22296 (cherry picked from commit 6d7d91817795d7ee7f45557411368a1738daa488)
* Add VecSlot for unboxed sums of SIMD vectorsDai2022-12-138-7/+76
| | | | | | | | | | | This patch adds the missing `VecRep` case to `primRepSlot` function and all the necessary machinery to carry this new `VecSlot` through code generation. This allows programs involving unboxed sums of SIMD vectors to be written and compiled. Fixes #22187 (cherry picked from commit 5b3a992f5d166007c3c5a22f120ed08e0a27f01a)
* Properly cast values when writing/reading unboxed sums.Andreas Klebinger2022-12-1316-80/+790
| | | | | | | | | Unboxed sums might store a Int8# value as Int64#. This patch makes sure we keep track of the actual value type. See Note [Casting slot arguments] for the details. (cherry picked from commit 31462d98c31e3ef48af2f6c6f2d379d74ccc63f5)
* Write response files in UTF-8 on WindowsBen Gamari2022-12-131-4/+0
| | | | | | | | | | This reverts the workaround introduced in f63c8ef33ec9666688163abe4ccf2d6c0428a7e7, which taught our response file logic to write response files with the `latin1` encoding to workaround `gcc`'s lacking Unicode support. This is now no longer necessary (and in fact actively unhelpful) since we rather use Clang. (cherry picked from commit 30f0d9a9ded55a822e094847d5ac8087262fb8da)
* Fix manifest filename when writing Windows .rc filesBen Gamari2022-12-131-3/+1
| | | | | | | As noted in #12971, we previously used `show` which resulted in inappropriate escaping of non-ASCII characters. (cherry picked from commit a4dbd102af1989526ca87f4dd949f72231284e68)
* driver: Fix -fdefer-diagnostics flagMatthew Pickering2022-12-139-6/+131
| | | | | | | | | | | The `withDeferredDiagnostics` wrapper wasn't doing anything because the session it was modifying wasn't used in hsc_env. Therefore the fix is simple, just push the `getSession` call into the scope of `withDeferredDiagnostics`. Fixes #22391 (cherry picked from commit 6dab0046b575e102bf3245fd63d5ac6bc6f4204d)
* eventlog: Ensure that IPE output contains actual info table pointersBen Gamari2022-12-132-1/+5
| | | | | | | | | | | The refactoring in 866c736e introduced a rather subtle change in the semantics of the IPE eventlog output, changing the eventlog field from encoding info table pointers to "TNTC pointers" (which point to entry code when tables-next-to-code is enabled). Fix this. Fixes #22452. (cherry picked from commit 268a3ce952f6be00a1dd164dc4d7acb346045e90)
* Fix @since annotations on WithDict and Coerciblesheaf2022-12-134-5/+18
| | | | | | Fixes #22453 (cherry picked from commit 68c966cd3c9d581bac4573807e433fe8d063445f)
* Add a missing varToCoreExpr in etaBodyForJoinPointSimon Peyton Jones2022-12-133-1/+324
| | | | | | | | | | | | | This subtle bug showed up when compiling a library with 9.4. See #22491. The bug is present in master, but it is hard to trigger; the new regression test T22491 fails in 9.4. The fix was easy: just add a missing varToCoreExpr in etaBodyForJoinPoint. The fix is definitely right though! (cherry picked from commit afc2540daf6ca6baa09ab147b792da08d66d878c)
* Truncate eventlog event for large payload (#20221)Ian-Woo Kim2022-12-131-1/+11
| | | | | | | | | | | | | | | | RTS eventlog events for postCapsetVecEvent are truncated if payload is larger than EVENT_PAYLOAD_SIZE_MAX Previously, postCapsetVecEvent records eventlog event with payload of variable size larger than EVENT_PAYLOAD_SIZE_MAX (2^16) without any validation, resulting in corrupted data. For example, this happens when a Haskell binary is invoked with very long command line arguments exceeding 2^16 bytes (see #20221). Now we check the size of accumulated payload messages incrementally, and truncate the message just before the payload size exceeds EVENT_PAYLOAD_SIZE_MAX. RTS will warn the user with a message showing how many arguments are truncated. (cherry picked from commit 2057c77d08cb8422857d182a3691f98dccd0c7d6)
* Typeable: Fix module locations of some definitions in GHC.TypesMatthew Pickering2022-12-134-4/+68
| | | | | | | | | | | | | | | There was some confusion in Data.Typeable about which module certain wired-in things were defined in. Just because something is wired-in doesn't mean it comes from GHC.Prim, in particular things like LiftedRep and RuntimeRep are defined in GHC.Types and that's the end of the story. Things like Int#, Float# etc are defined in GHC.Prim as they have no Haskell definition site at all so we need to generate type representations for them (which live in GHC.Types). Fixes #22510 (cherry picked from commit 1d3a8b8ec98e6eedf8943e19780ec374c2491e7f)
* ApplicativeDo: Set pattern location before running exhaustiveness checkerMatthew Pickering2022-12-134-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This improves the error messages of the exhaustiveness checker when checking statements which have been moved around with ApplicativeDo. Before: Test.hs:2:3: warning: [GHC-62161] [-Wincomplete-uni-patterns] Pattern match(es) are non-exhaustive In a pattern binding: Patterns of type ‘Maybe ()’ not matched: Nothing | 2 | let x = () | ^^^^^^^^^^ After: Test.hs:4:3: warning: [GHC-62161] [-Wincomplete-uni-patterns] Pattern match(es) are non-exhaustive In a pattern binding: Patterns of type ‘Maybe ()’ not matched: Nothing | 4 | ~(Just res1) <- seq x (pure $ Nothing @()) | Fixes #22483 (cherry picked from commit 74c767df770766d8d52e87b9ff7da10f94620a91)
* Fix #22425 - Broken eta-expansion over expensive work.wip/andreask/94-dlistAndreas Klebinger2022-11-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Through a mistake in the latest backport we started eta-expanding over expensive work by mistake. E.g. over <expensive> in code like: case x of A -> id B -> <expensive> We fix this by only eta-expanding over <expensive> if all other branches are headed by an oneShot lambda. In the long story of broken eta-expansion on 9.2/9.4 this is hopefully the last chapter. ------------------------- Metric Increase: CoOpt_Read T1969 parsing001 TcPlugin_RewritePerf LargeRecord -------------------------
* Add -dsuppress-coercion-types to make coercions even smaller.Andreas Klebinger2022-11-106-13/+23
| | | | | Instead of `` `cast` <Co:11> :: (Some -> Really -> Large Type)`` simply print `` `cast` <Co:11> :: ... ``
* Bump hadrian index state to allow 9.4 as boot compilerwip/andreask/bump-94-indexAndreas Klebinger2022-11-101-1/+1
|
* Revert "base: Move CString, CStringLen to GHC.Foreign"ghc-9.4.3-releaseBen Gamari2022-11-022-6/+11
| | | | This reverts commit 5ec22f0135483ea8a8a543c53dcc7f9d7f6a8dea.
* Bump process submodule to v1.6.16.0Ben Gamari2022-11-011-0/+0
|
* Fix arityType: -fpedantic-bottoms, join points, etcSimon Peyton Jones2022-11-0113-116/+462
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This MR fixes #21694 and #21755 * For #21694 the underlying problem was that we were calling arityType on an expression that had free join points. This is a Bad Bad Idea. See Note [No free join points in arityType]. * I also made andArityType work correctly with -fpedantic-bottoms; see Note [Combining case branches: andWithTail]. * I realised that, now we have ae_sigs giving the ArityType for let-bound Ids, we don't need the (pre-dating) special code in arityType for join points. But instead we need to extend the env for Rec bindings, which weren't doing before. More uniform now. See Note [arityType for let-bindings]. This meant we could get rid of ae_joins, and in fact get rid of EtaExpandArity altogether. Simpler. And finally, it was the strange treatment of join-point Ids (involving a fake ABot type) that led to a serious bug: #21755. Fixed by this refactoring * Rewrote Note [Combining case branches: optimistic one-shot-ness] Compile time improves slightly on average: Metrics: compile_time/bytes allocated --------------------------------------------------------------------------------------- CoOpt_Read(normal) ghc/alloc 803,788,056 747,832,680 -7.1% GOOD T18223(normal) ghc/alloc 928,207,320 959,424,016 +3.1% BAD geo. mean -0.3% minimum -7.1% maximum +3.1% On Windows it's a bit better: geo mean is -0.6%, and three more benchmarks trip their compile-time bytes-allocated threshold (they were all close on the other build): T18698b(normal) ghc/alloc 235,619,776 233,219,008 -1.0% GOOD T6048(optasm) ghc/alloc 112,208,192 109,704,936 -2.2% GOOD T18140(normal) ghc/alloc 85,064,192 83,168,360 -2.2% GOOD I had a quick look at T18223 but it is knee deep in coercions and the size of everything looks similar before and after. I decided to accept that 3.4% increase in exchange for goodness elsewhere. Metric Decrease: CoOpt_Read LargeRecord ManyAlternatives ManyConstructors MultiComponentModules MultiComponentModulesRecomp T10421 T12425 T12707 T13035 T13253 T13379 T14683 T15703 T18698a T1969 T3064 T3294 T4801 T5321FD T5321Fun T5631 T783 T9020 T9198 T9233 T9872b T9872c T9961 parsing001 Metric Increase: T18223 (cherry picked from commit 5e282da37e19a1ab24ae167daf32276a64ed2842)
* EPA: DotFieldOcc does not have exact print annotationsAlan Zimmerman2022-11-018-8/+34
| | | | | | | | | | | | | | | | | For the code {-# LANGUAGE OverloadedRecordUpdate #-} operatorUpdate f = f{(+) = 1} There are no exact print annotations for the parens around the + symbol, nor does normal ppr print them. This MR fixes that. Closes #21805 (cherry picked from commit 792ef44d455c6e987f342fb61515464322a9fa77)
* Fix nested type splices in hie filesMatthew Pickering2022-11-019-5/+83
| | | | | | | | | | | | | | | | | | | | | | | The issue is that when we compile a typed bracket we replace the splice with HsSpliced (unTypeCode ...). Then when computing types for > [|| T $$(...) ||] GHC is asked to compute the type of `T $$(..)`, which panics because of the bogus type of T applied to `HsSpliced`, which is not type correct. The fix is to not attempt to compute the type for `HsSpliceE` constructors if we come across them as they should have either been already evaluated or lifted into a splice environment. As part of the patch I made hie files traverse into the splice environments so now we also get type information for things used inside nested splices. Fixes #21619
* Accept perf shiftsBen Gamari2022-10-240-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Metric Decrease: T18923 Metric Increase: ManyAlternatives ManyConstructors MultiComponentModules MultiComponentModulesRecomp T18282 T5642 T10421 T12150 T12234 T12425 T12707 T13035 T13056 T13379 T13719 T14697 T15703 T16577 T16875 T18140 T18698a T18698b T1969 T20049 T3064 T3294 T4801 T4978 T5321FD T5321Fun T7257 T783 T9020 T9198 T9233 T9961 WWRec
* Add release notes for 9.4.3Ben Gamari2022-10-232-0/+67
|
View Lorry Controller Status