| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
Resolves #21455
(cherry picked from commit 3e1e5ee3307fe7ea47e70a07a385b56536413f64)
(cherry picked from commit babfd40ded288d4758ca9ac505385b1ac6cb1187)
|
|
|
|
|
| |
(cherry picked from commit 26e16e611ccfdbe8450f4b3ffac3182e698e1351)
(cherry picked from commit 3a3c3bfd2abed133f5c3281d8b185906b5712fdd)
|
|
|
|
|
| |
(cherry picked from commit 376088dd91123b64947eb376f9c3db23117f293d)
(cherry picked from commit 8bc4b57fe328f7828a7d69c55aa151079359e06c)
|
|
|
|
|
| |
(cherry picked from commit 89a413182c9709b239106b40b1d6c8b20a214a21)
(cherry picked from commit 4b9af020ffa0077983c7952fd27114e47253a6ea)
|
|
|
|
|
|
|
| |
The code path was failing to check if the errors had been turned into
fatal errors.
(cherry picked from commit 6edf34e41bffcd0bed61629f8c215465d866fdcc)
|
|
|
|
|
|
| |
Ensuring that mulIntMayOflo# behaves as expected.
(cherry picked from commit 26745006bdecc2d269fd8252b189650d6bd7ac10)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
| |
(cherry picked from commit 31c214cc9d3873b7d1bf4751700cc6c7da09e11d)
|
|
|
|
| |
(cherry picked from commit c006ac0d1454119f0b456a00ff2416831c955e99)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
Previously there were very long, hard to parse lines. Fix this.
(cherry picked from commit 70f0c1f84213f7a09bc31e0eeefb5b089708f04b)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
Downstream bug for reference: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261798
Relevant upstream issue: #15718
(cherry picked from commit c7f9f6b547f502a20602ea33fdef893367efe476)
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
Fixes #21506.
(cherry picked from commit aa9d9381e5c5d7b96966d817372085897585ecdd)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
Fixes #21682
(cherry picked from commit f1d5aaa8888f21ed5351929af36cab3770397115)
|
|
|
|
|
|
|
|
|
|
| |
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 a1e1d8eecceaa2fa64668376d5ea44990d94a3ea)
|
|
|
|
|
|
| |
Previously this produced invalid assembly containing a redundant comma.
(cherry picked from commit d05d90d26d0820d4d24c461888bcd1993ebef36c)
|
|
|
|
|
|
| |
These will be needed to fix #21624.
(cherry picked from commit 711cb417606e351ea525d7a322b591b3b0e23bdd)
|
|
|
|
| |
(cherry picked from commit e128b7b8a139a1b952aa409811f181572f5b607b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to process the rhs of non-recursive bindings and their body
using the same env. If we had something like
let x = ... x ...
this caused trouble because the two xs refer to different binders
but we would substitute both for a new binder x2 causing out of scope
errors.
We now simply use two different envs for the rhs and body in cse_bind.
It's all explained in the Note [Separate envs for let rhs and body]
Fixes #21685
(cherry picked from commit 56ebf9a5bfc8791c1fa609b960f3c161882540e3)
|
|
|
|
|
|
| |
Fixes #20272
(cherry picked from commit fb1e0a5da67f075ae4f487e111fcf69d1dfcd42f)
|
|
|
|
| |
Workaround for #19624
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
(cherry picked from commit ecf5f3634c9971de4ae21870f0d6f3d5a35634a1)
|
|
|
|
|
|
|
|
|
|
| |
Previously Hadrian's installation makefile would assume that the string
`xxx` did not appear in the installation path. This would of course
break for some users.
Fixes #21402.
(cherry picked from commit dd5fecb0e2990b192d92f4dfd7519ecb33164fad)
|
|
|
|
| |
(cherry picked from commit a36d12ee19afa949da27ab73f082428830f3dba3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This firstly caused spurious output to be emitted (as evidenced by
#21555) but even worse caused a massive coercion to be attempted to be
printed (> 200k terms) which would invariably eats up all the memory of
your computer.
The good news is that removing this trace allows the program to compile
to completion, the bad news is that the program exhibits a core lint
error (on 9.0.2) but not any other releases it seems.
Fixes #21577 and #21555
(cherry picked from commit c1e24e610ae572b77bc1507674431a84563af759)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
See new Note [Use only the best local instance] in
GHC.Tc.Solver.Interact.
This commit also refactors the InstSC/OtherSC mechanism
slightly.
Close #20582.
(cherry picked from commit ca90ffa321a31842a32be1b5b6e26743cd677ec5)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we reported things wrong with
f :: (Eq a, Ord a) => a -> Bool
f x = x == x
saying that Eq a was redundant. This is fixed now, along with
some simplification in Note [Replacement vs keeping]. There's
a tiny bit of extra complexity in setImplicationStatus, but
it's explained in Note [Tracking redundant constraints].
Close #20602
(cherry picked from commit 265ead8a7401e20d75ed4e476805508ea695f37f)
|
|
|
|
|
|
|
|
| |
Both #20878 and #21196 were caused by unwanted dynamic dependencies
being introduced by boot libraries. Ensure that we catch this in CI by
attempting to run GHC in an environment with a minimal PATH.
(cherry picked from commit fcc7dc4c2848d46439bcbfae3f9eaf0a1f400ab4)
|
|
|
|
|
|
|
|
|
|
| |
When passed `--use-system-libffi` then we shouldn't copy and install the
headers from the system package. Instead the headers are expected to be
available as a runtime dependency on the users system.
Fixes #21485 #21487
(cherry picked from commit fec3e7aa72bee69ef3a3f363709377990650a5d3)
|
|
|
|
| |
(cherry picked from commit f2c08124b30eb87482dc0ed1d7199aa58950e309)
|
|
|
|
| |
(cherry picked from commit c3105be4bbfeb5005d8c585b5a3f91a4c3ee5b4b)
|
|
|
|
|
|
|
|
| |
This is now fixed on master and 9.2 branch.
Closes #21558
(cherry picked from commit 0e2d16eb76037152c96226f0f65a5ebdee64f7b6)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating an SRT for a recursive group, GHC.Cmm.Info.Build.oneSRT
filters out recursive references, as described in Note [recursive SRTs].
However, doing so for static functions would be unsound, for the reason
described in Note [Invalid optimisation: shortcutting].
However, the same argument applies to static data constructor
applications, as we discovered in #20959. Fix this by ensuring that
static data constructor applications are included in recursive SRTs.
The approach here is not entirely satisfactory, but it is a starting
point.
Fixes #20959.
(cherry picked from commit b048a9f4e28186d2245427d2d83f08418573fae5)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function breakTyVarCycle_maybe has been installed
in a dark corner of GHC to catch some gremlins (a.k.a.
occurs-check failures) who lurk
there. But it previously only caught gremlins of the
form (a ~ ... F a ...), where some of our intrepid users
have spawned gremlins of the form (G a ~ ... F (G a) ...).
This commit improves breakTyVarCycle_maybe (and renames
it to breakTyEqCycle_maybe) to catch the new gremlins.
Happily, the change is remarkably small.
The gory details are in Note [Type equality cycles].
Test cases: typecheck/should_compile/{T21515,T21473}.# Please enter the commit message for your changes. Lines starting
|
|
|
|
| |
(cherry picked from commit 81a8f7a7daeb87db53d598ced4b303f8f320442f)
|
|
|
|
|
|
| |
for better disambiguation (#17420)
(cherry picked from commit 5f6527e05beb628c5015ab9f8a7f4012ee8d14a1)
|
|
|
|
|
|
| |
This missing guard gave rise to #21519.
(cherry picked from commit 32cdf62dc1537f572f2d044851e316ca37d8e012)
|