GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-09-08T16:43:13Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15364Replace the atomicModifyMutVar# primop2021-09-08T16:43:13ZDavid FeuerReplace the atomicModifyMutVar# primopThis was [accepted proposal \#27](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0027-atomicModifyMutVar.rst). Specifically:
1. Replace `atomicModifyMutVar#` with `atomicModifyMutVar2#`.
1. Add `atomicModifyMutVar_...This was [accepted proposal \#27](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0027-atomicModifyMutVar.rst). Specifically:
1. Replace `atomicModifyMutVar#` with `atomicModifyMutVar2#`.
1. Add `atomicModifyMutVar_#` and `atomicSwapMutVar#`.
1. Add a function imitating `atomicModifyMutVar#` to `GHC.Exts` for backwards compatibility.
1. Use the new primops where appropriate throughout `base`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Replace the atomicModifyMutVar# primop","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"FeatureRequest","description":"This was [https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0027-atomicModifyMutVar.rst accepted proposal #27]. Specifically:\r\n\r\n1. Replace `atomicModifyMutVar#` with `atomicModifyMutVar2#`.\r\n2. Add `atomicModifyMutVar_#` and `atomicSwapMutVar#`.\r\n3. Add a function imitating `atomicModifyMutVar#` to `GHC.Exts` for backwards compatibility.\r\n4. Use the new primops where appropriate throughout `base`.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/15256GHCi check .ghci permission on WSL(Linux on Windows)2019-07-07T18:13:36ZyongjoonGHCi check .ghci permission on WSL(Linux on Windows)GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.
You can reproduce this problem from 8.2.2.\~8.4.3 of GHC-WSL(https://launchpad.net/\~hvr/+archive/ubuntu/ghc-wsl).
I think GHCi of WSL would ...GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.
You can reproduce this problem from 8.2.2.\~8.4.3 of GHC-WSL(https://launchpad.net/\~hvr/+archive/ubuntu/ghc-wsl).
I think GHCi of WSL would skip .ghci permission check.
I used GHCi(WSL) on some Haskell project synced by cloud storage which is placed on Windows filesystem.
However, when I try to load GHCi with .ghci config file, GHCI says it can't pass .ghci permission check.
As you know, chmod on WSL may ignore your command about many of file on NTFS filesystem in WSL. WSL shows permission of some files on Windows filesystems like 777.
Therefore, I think GHCi(WSL) may have an exceptional code not to check .ghci file as like as ghci warning message for MinTTY console.
P.S.
Is there any bug-report place only for GHC-WSL? I couldn't find it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi check .ghci permission on WSL(Linux on Windows)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.\r\nYou can reproduce this problem from 8.2.2.~8.4.3 of GHC-WSL(https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl).\r\n\r\nI think GHCi of WSL would skip .ghci permission check.\r\n\r\nI used GHCi(WSL) on some Haskell project synced by cloud storage which is placed on Windows filesystem.\r\n\r\nHowever, when I try to load GHCi with .ghci config file, GHCI says it can't pass .ghci permission check.\r\nAs you know, chmod on WSL may ignore your command about many of file on NTFS filesystem in WSL. WSL shows permission of some files on Windows filesystems like 777.\r\n\r\nTherefore, I think GHCi(WSL) may have an exceptional code not to check .ghci file as like as ghci warning message for MinTTY console.\r\n\r\nP.S.\r\nIs there any bug-report place only for GHC-WSL? I couldn't find it.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/15176Superclass `Monad m =>` makes program run 100 times slower2019-11-16T10:52:51Zdanilo2Superclass `Monad m =>` makes program run 100 times slowerHi! I've just encountered a very bizarre error.
### General description
The code:
```
class LayersFoldableBuilder__ t (layers :: [Type]) m where
buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t)
instance Mona...Hi! I've just encountered a very bizarre error.
### General description
The code:
```
class LayersFoldableBuilder__ t (layers :: [Type]) m where
buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t)
instance Monad m => LayersFoldableBuilder__ t '[] m where
buildLayersFold__ = \_ a -> a
{-# INLINE buildLayersFold__ #-}
instance ( MonadIO m
, Storable.Storable (Layer.Cons l ())
, Layer.StorableLayer l m
, LayerFoldableBuilder__ (EnabledLayer t l) t m l
, LayersFoldableBuilder__ t ls m )
=> LayersFoldableBuilder__ t (l ': ls) m where
buildLayersFold__ = \ptr mr -> do
let fs = buildLayersFold__ @t @ls ptr'
ptr' = Ptr.plusPtr ptr $ Layer.byteSize @l
layerBuild__ @(EnabledLayer t l) @t @m @l ptr $! fs mr
{-# INLINE buildLayersFold__ #-}
```
This is a typeclass `LayersFoldableBuilder__` and ALL of its instances. Please note, that every instance has a `Monad m` or `MonadIO m` constraint. The program which uses this code heavily runs in 40ms. If we only add constraint `Monad m =>` to the class definition:
```
class Monad m => LayersFoldableBuilder__ t (layers :: [Type]) m where
buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t)
```
The program runs in 3.5s , which is almost 100 times slower.
Unfortunatelly I do not have minimal example, but it is reproducible. It is a part of the Luna Language codebase: https://github.com/luna/luna-core/blob/60bf6130691c23e52b97b067b52becb8fdb0c72e/core/src/Data/Graph/Traversal/Scoped.hs\#L102
it was introduced in the commit 60bf6130691c23e52b97b067b52becb8fdb0c72e on branch static-layers . However, building this is simple: stack bench luna-core . After invoking it we see the described results.
### Why its important and what should we do to fix it ===
1. I am writing this because I care about Haskell community. I want GHC and Haskell to be widely used. Right now, the only thing I hear from all companies around our company is that impredicative performance, even when following rules "how to write efficient code" is the biggest pain people have. Haskell is gathering attention - pure functional programming, immutability etc - are great. But it will not become a popular choice unless we care about predictive performance.
1. Such performance changes are unacceptable when thinking about Haskell and GHC as production ready systems. We need a clear way how to write high performance Haskell without the need to benchmark every part of our programs even when refactoring things. GHC has enough information to discover that we want high performance here and there (even by looking at INLINE pragmas) and should warn us about lack of optimization. We should also have a way to force GHC to apply optimizations in particular places - for example by explicit marking code to be always specialized during compilation, so GHC would never fall back to dict-passing in such places. Such possibility would solve MANY related problems and user fears.
1. The point 2 also applies to strictness. In my opinion, having more clear strictness resolution rules / tools is important. Right now the only way to know if strictness analysis did a good job and we are not constantly boxing / unboxing things is to read core, which is tedious and 99% of Haskell users do not even know how to do it (We've got 10 really, really good Haskellers here, 2 of them are capable of reading core, but not very fluently). I would love to chat more about these topics, because they are crucial for growing Haskell community and making Haskell more popular choice, which is waht we want, right? We don't want Haskell to be just a research project with "all its users being its authors" at the same time, am I
### What happens in core ===
I inspected core and have found that indeed, after adding the constraint, GHC does not apply all optimizations to the definitions. To be honest, I completely don't understand it, because the code uses everywhere explicit `INLINE` pragma to be sure everything is optimized away in the compilation stage:
```
--------------------------------------------------------------------------------
SLOW, with Monad m =>
--------------------------------------------------------------------------------
-- RHS size: {terms: 5, types: 12, coercions: 4, joins: 0/0}
buildLayersFold__ [InlPrag=INLINE]
:: forall t (layers :: [*]) (m :: * -> *).
LayersFoldableBuilder__ t layers m =>
SomePtr -> m (Fold.Result t) -> m (Fold.Result t)
[GblId[ClassOp],
Arity=1,
Caf=NoCafRefs,
Str=<S,U>,
Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True,
WorkFree=True, Expandable=True,
Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=True)
Tmpl= \ (@ t_ao0O)
(@ (layers_ao0P :: [*]))
(@ (m_ao0Q :: * -> *))
(v_B1 [Occ=Once]
:: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) ->
v_B1
`cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0]
<t_ao0O>_N <layers_ao0P>_N <m_ao0Q>_N
:: (LayersFoldableBuilder__
t_ao0O layers_ao0P m_ao0Q :: Constraint)
~R# (SomePtr
-> m_ao0Q (Fold.Result t_ao0O)
-> m_ao0Q (Fold.Result t_ao0O) :: *))}]
buildLayersFold__
= \ (@ t_ao0O)
(@ (layers_ao0P :: [*]))
(@ (m_ao0Q :: * -> *))
(v_B1 :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) ->
v_B1
`cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0]
<t_ao0O>_N <layers_ao0P>_N <m_ao0Q>_N
:: (LayersFoldableBuilder__
t_ao0O layers_ao0P m_ao0Q :: Constraint)
~R# (SomePtr
-> m_ao0Q (Fold.Result t_ao0O)
-> m_ao0Q (Fold.Result t_ao0O) :: *))
--------------------------------------------------------------------------------
FAST, without Monad m =>
--------------------------------------------------------------------------------
-- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0}
Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__
:: forall t (layers :: [*]) (m :: * -> *).
LayersFoldableBuilder__ t layers m =>
Monad m
[GblId[ClassOp],
Arity=1,
Caf=NoCafRefs,
Str=<S(SL),U(U,A)>,
RULES: Built in rule for Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__: "Class op $p1LayersFoldableBuilder__"]
Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__
= \ (@ t_ao0P)
(@ (layers_ao0Q :: [*]))
(@ (m_ao0R :: * -> *))
(v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) ->
case v_B1 of v_B1
{ Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2
v_B3 ->
v_B2
}
-- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0}
buildLayersFold__
:: forall t (layers :: [*]) (m :: * -> *).
LayersFoldableBuilder__ t layers m =>
SomePtr -> m (Fold.Result t) -> m (Fold.Result t)
[GblId[ClassOp],
Arity=1,
Caf=NoCafRefs,
Str=<S(LS),U(A,U)>,
RULES: Built in rule for buildLayersFold__: "Class op buildLayersFold__"]
buildLayersFold__
= \ (@ t_ao0P)
(@ (layers_ao0Q :: [*]))
(@ (m_ao0R :: * -> *))
(v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) ->
case v_B1 of v_B1
{ Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2
v_B3 ->
v_B3
}
```⊥https://gitlab.haskell.org/ghc/ghc/-/issues/15151Better Interaction Between Specialization and GND2019-07-07T18:14:02ZAndrew MartinBetter Interaction Between Specialization and GNDLet us consider the following code:
```
-- Sort.hs
sort :: (Prim a, Ord a) => MutablePrimArray s a -> ST s ()
sort mutArr = ...
{-# SPECIALIZE sort :: MutablePrimArray s Int -> ST s () -#}
{-# SPECIALIZE sort :: MutablePrimArray s Int8 ...Let us consider the following code:
```
-- Sort.hs
sort :: (Prim a, Ord a) => MutablePrimArray s a -> ST s ()
sort mutArr = ...
{-# SPECIALIZE sort :: MutablePrimArray s Int -> ST s () -#}
{-# SPECIALIZE sort :: MutablePrimArray s Int8 -> ST s () -#}
{-# SPECIALIZE sort :: MutablePrimArray s Word8 -> ST s () -#}
...
```
For reference, a `MutablePrimArray` is a `MutableByteArray` with a phantom type variable to tag the element type. This sorting algorithm may be implemented in any number of ways, and the implementation is unimportant here. The specialize pragmas are intended to capture a number of common use cases. Here's where a problem arises:
```
-- Example.hs
newtype PersonId = PersonId Int
deriving (Eq,Ord,Prim)
sortPeople :: MutablePrimArray s PersonId -> MutablePrimArray s PersonId
sortPeople x = sort x
```
There isn't a rewrite rule that specializes the `sort` function when we are dealing with `PersonId`. So, we end up with a slower version of the code that explicitly passes all the dictionaries. One solution would be to just use `INLINABLE` instead. Then we don't have to try to list every type, and we just let the specialization be generate at the call site. But this isn't totally satisfying. There are a lot of types that are just newtype wrappers around `Int`. Why should we have an extra copy of the same code for each of them? (Even without newtypes, `INLINABLE` can still result in duplication if neither of the modules that needs a specialization transitively imports the other).
What I'm suggesting is that rewrite rules (like those generated by `SPECIALIZE`) could target not just the given type but also any newtype around it, provided that all typeclass instances required by the function were the result of GND. The only situations where this is unsound are situations where the user was already doing something unsound with rewrite rules. There are several implementation difficulties:
- In core, there is no good way to tell that a typeclass instance dictionary was the result of GND. I'm not sure how to work around this.
- `Eq` and `Ord` usually aren't handled by the `newtype` deriving strategy. They are handled by the `stock` strategy, which produces code with equivalent behavior but is nevertheless different code.
- The rewrite rule would need to look at additional arguments beyond the type arguments.
I suspect that these difficulties would make such this feature difficult to implement, but this feature would help me with some of my libraries and applications.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Better Interaction Specialization and GND","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Let us consider the following code:\r\n\r\n{{{\r\n-- Sort.hs\r\nsort :: (Prim a, Ord a) => MutablePrimArray s a -> ST s ()\r\nsort mutArr = ...\r\n{-# SPECIALIZE sort :: MutablePrimArray s Int -> ST s () -#}\r\n{-# SPECIALIZE sort :: MutablePrimArray s Int8 -> ST s () -#}\r\n{-# SPECIALIZE sort :: MutablePrimArray s Word8 -> ST s () -#}\r\n...\r\n}}}\r\n\r\nFor reference, a `MutablePrimArray` is a `MutableByteArray` with a phantom type variable to tag the element type. This sorting algorithm may be implemented in any number of ways, and the implementation is unimportant here. The specialize pragmas are intended to capture a number of common use cases. Here's where a problem arises:\r\n\r\n{{{\r\n-- Example.hs\r\nnewtype PersonId = PersonId Int\r\n deriving (Eq,Ord,Prim)\r\nsortPeople :: MutablePrimArray s PersonId -> MutablePrimArray s PersonId\r\nsortPeople x = sort x\r\n}}}\r\n\r\nThere isn't a rewrite rule that specializes the `sort` function when we are dealing with `PersonId`. So, we end up with a slower version of the code that explicitly passes all the dictionaries. One solution would be to just use `INLINABLE` instead. Then we don't have to try to list every type, and we just let the specialization be generate at the call site. But this isn't totally satisfying. There are a lot of types that are just newtype wrappers around `Int`. Why should we have an extra copy of the same code for each of them? (Even without newtypes, `INLINABLE` can still result in duplication if neither of the modules that needs a specialization transitively imports the other).\r\n\r\nWhat I'm suggesting is that rewrite rules (like those generated by `SPECIALIZE`) could target not just the given type but also any newtype around it, provided that all typeclass instances required by the function were the result of GND. The only situations where this is unsound are situations where the user was already doing something unsound with rewrite rules. There are several implementation difficulties:\r\n\r\n* In core, there is no good way to tell that a typeclass instance dictionary was the result of GND. I'm not sure how to work around this.\r\n* `Eq` and `Ord` usually aren't handled by the `newtype` deriving strategy. They are handled by the `stock` strategy, which produces code with equivalent behavior but is nevertheless different code.\r\n* The rewrite rule would need to look at additional arguments beyond the type arguments.\r\n\r\nI suspect that these difficulties would make such this feature difficult to implement, but this feature would help me with some of my libraries and applications.","type_of_failure":"OtherFailure","blocking":[]} -->Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/14980Runtime performance regression with binary operations on vectors2021-09-07T15:48:34ZttylecRuntime performance regression with binary operations on vectorsLet me briefly explain our use case: we have a machine learning tools created in Haskell. Basically it builds association rules for a database. In plain English: predicates on data rows. We need to score them, so we need to check how man...Let me briefly explain our use case: we have a machine learning tools created in Haskell. Basically it builds association rules for a database. In plain English: predicates on data rows. We need to score them, so we need to check how many rows are "matched" by the predicate.
In order to optimize performance, our code uses two main representations for data: one is a "human readable", where a values are real values. The second one is binarized representation for categorical data. The latter has is actually a family of representation, since we pack bits into tuples of Word64 and use bitwise operation to implement logic.
Simplified but representative code is attached.
In GHC 8.0.2 binary representation is faster by one order of magnitude than the "human readable" one:
```
➜ ghc-bug stack exec performance-bug-pair-1
"Generated"
benchmarking 256 columns/raw unbox vectors
time 342.6 μs (338.3 μs .. 348.0 μs)
0.999 R² (0.998 R² .. 1.000 R²)
mean 339.3 μs (337.5 μs .. 342.0 μs)
std dev 7.203 μs (5.596 μs .. 10.07 μs)
variance introduced by outliers: 13% (moderately inflated)
benchmarking 256 columns/binary packed
time 32.07 μs (29.69 μs .. 34.14 μs)
0.982 R² (0.976 R² .. 0.997 R²)
mean 29.97 μs (29.41 μs .. 31.03 μs)
std dev 2.428 μs (1.526 μs .. 3.750 μs)
variance introduced by outliers: 78% (severely inflated)
```
In GHC 8.2.2 (and later) binary representation performance is similar to "human readable", so no performance gain:
```
➜ ghc-bug stack exec performance-bug-pair-1
"Generated"
benchmarking 256 columns/raw unbox vectors
time 442.4 μs (406.7 μs .. 474.5 μs)
0.978 R² (0.969 R² .. 0.993 R²)
mean 399.3 μs (391.3 μs .. 415.1 μs)
std dev 34.73 μs (20.36 μs .. 53.29 μs)
variance introduced by outliers: 71% (severely inflated)
benchmarking 256 columns/binary packed
time 378.6 μs (295.8 μs .. 488.0 μs)
0.637 R² (0.492 R² .. 0.780 R²)
mean 568.1 μs (437.1 μs .. 747.6 μs)
std dev 308.7 μs (233.6 μs .. 386.1 μs)
variance introduced by outliers: 98% (severely inflated)
```
However, for certain compilation paths, we still can get similar speedup as with GHC 8.0.2. In the above examples we used 4-tuple of Word64 as binary representation. In the following code we run two tests: one on just Word64 and one of 4-tuple of Word64. The difference is that we just add the Word64 case:
```
➜ ghc-bug stack exec performance-bug-pair-2
"Generated"
benchmarking 64 columns/raw unbox vectors
time 337.6 μs (336.1 μs .. 339.3 μs)
0.999 R² (0.998 R² .. 1.000 R²)
mean 349.6 μs (344.4 μs .. 359.7 μs)
std dev 23.22 μs (15.39 μs .. 38.22 μs)
variance introduced by outliers: 60% (severely inflated)
benchmarking 64 columns/binary packed
time 21.66 μs (21.53 μs .. 21.79 μs)
1.000 R² (0.999 R² .. 1.000 R²)
mean 21.68 μs (21.53 μs .. 21.89 μs)
std dev 613.2 ns (466.0 ns .. 806.0 ns)
variance introduced by outliers: 30% (moderately inflated)
benchmarking 256 columns/raw unbox vectors
time 344.5 μs (341.6 μs .. 348.2 μs)
0.999 R² (0.999 R² .. 1.000 R²)
mean 345.1 μs (342.5 μs .. 349.3 μs)
std dev 10.66 μs (7.997 μs .. 16.34 μs)
variance introduced by outliers: 25% (moderately inflated)
benchmarking 256 columns/binary packed
time 28.04 μs (27.70 μs .. 28.46 μs)
0.999 R² (0.999 R² .. 1.000 R²)
mean 28.05 μs (27.85 μs .. 28.30 μs)
std dev 758.2 ns (628.2 ns .. 907.6 ns)
variance introduced by outliers: 27% (moderately inflated)
```
I made a variant of code with simpler accumulating function (in our code we accumulate pair of integers, simplified accumulator work on one integer). GHC 8.2.2 in that case losses speed-up with 4-tuples:
```
➜ ghc-bug stack exec performance-bug-2
"Generated"
benchmarking 64 columns/raw unbox vectors
time 333.8 μs (333.0 μs .. 335.1 μs)
1.000 R² (0.999 R² .. 1.000 R²)
mean 333.6 μs (332.4 μs .. 335.8 μs)
std dev 5.651 μs (3.233 μs .. 9.582 μs)
benchmarking 64 columns/binary packed
time 39.06 μs (38.98 μs .. 39.14 μs)
1.000 R² (1.000 R² .. 1.000 R²)
mean 38.94 μs (38.83 μs .. 39.14 μs)
std dev 495.0 ns (310.2 ns .. 782.1 ns)
benchmarking 256 columns/raw unbox vectors
time 336.9 μs (336.2 μs .. 337.9 μs)
1.000 R² (1.000 R² .. 1.000 R²)
mean 337.5 μs (336.2 μs .. 339.8 μs)
std dev 5.757 μs (2.946 μs .. 8.979 μs)
benchmarking 256 columns/binary packed
time 239.8 μs (237.6 μs .. 243.0 μs)
0.998 R² (0.996 R² .. 0.999 R²)
mean 251.4 μs (247.9 μs .. 259.8 μs)
std dev 11.50 μs (5.662 μs .. 19.79 μs)
variance introduced by outliers: 37% (moderately inflated)
```
In GHC 8.0.2 we have speed-up in both cases.
What may be related: using random-fu to generate random numbers seems to produce broken code on GHC 8.2.2 (the `performance-bug-rfu.hs` source).
Short description of attached sources:
- performance-bug-pair-2.hs: using two binary representations
- performance-bug-pair-1.hs: using one binary representation (one case commented)
- performance-bug-1.hs: using one binary representation with simplified accumulator
- performance-bug-2.hs: using two binary representation with simplified accumulator
- performance-bug-rfu.hs: using random-fu to generate data (optional)
- stack-8.0.yaml: stack file for GHC-8.0.2
- stack-8.2.yaml: stack file for GHC-8.2.2
- stack-nightly.yaml: stack file for GHC-8.4
- performance-bug.cabal: to be able to stack build everything.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Runtime performance regression with binary operations on vectors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["bitwise","operations","vector"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Let me briefly explain our use case: we have a machine learning tools created in Haskell. Basically it builds association rules for a database. In plain English: predicates on data rows. We need to score them, so we need to check how many rows are \"matched\" by the predicate.\r\n\r\nIn order to optimize performance, our code uses two main representations for data: one is a \"human readable\", where a values are real values. The second one is binarized representation for categorical data. The latter has is actually a family of representation, since we pack bits into tuples of Word64 and use bitwise operation to implement logic.\r\n\r\nSimplified but representative code is attached.\r\n\r\nIn GHC 8.0.2 binary representation is faster by one order of magnitude than the \"human readable\" one:\r\n\r\n{{{\r\n➜ ghc-bug stack exec performance-bug-pair-1\r\n\"Generated\"\r\nbenchmarking 256 columns/raw unbox vectors\r\ntime 342.6 μs (338.3 μs .. 348.0 μs)\r\n 0.999 R² (0.998 R² .. 1.000 R²)\r\nmean 339.3 μs (337.5 μs .. 342.0 μs)\r\nstd dev 7.203 μs (5.596 μs .. 10.07 μs)\r\nvariance introduced by outliers: 13% (moderately inflated)\r\n\r\nbenchmarking 256 columns/binary packed\r\ntime 32.07 μs (29.69 μs .. 34.14 μs)\r\n 0.982 R² (0.976 R² .. 0.997 R²)\r\nmean 29.97 μs (29.41 μs .. 31.03 μs)\r\nstd dev 2.428 μs (1.526 μs .. 3.750 μs)\r\nvariance introduced by outliers: 78% (severely inflated)\r\n}}}\r\n\r\nIn GHC 8.2.2 (and later) binary representation performance is similar to \"human readable\", so no performance gain:\r\n\r\n{{{\r\n➜ ghc-bug stack exec performance-bug-pair-1\r\n\"Generated\"\r\nbenchmarking 256 columns/raw unbox vectors\r\ntime 442.4 μs (406.7 μs .. 474.5 μs)\r\n 0.978 R² (0.969 R² .. 0.993 R²)\r\nmean 399.3 μs (391.3 μs .. 415.1 μs)\r\nstd dev 34.73 μs (20.36 μs .. 53.29 μs)\r\nvariance introduced by outliers: 71% (severely inflated)\r\n\r\nbenchmarking 256 columns/binary packed\r\ntime 378.6 μs (295.8 μs .. 488.0 μs)\r\n 0.637 R² (0.492 R² .. 0.780 R²)\r\nmean 568.1 μs (437.1 μs .. 747.6 μs)\r\nstd dev 308.7 μs (233.6 μs .. 386.1 μs)\r\nvariance introduced by outliers: 98% (severely inflated)\r\n}}}\r\n\r\nHowever, for certain compilation paths, we still can get similar speedup as with GHC 8.0.2. In the above examples we used 4-tuple of Word64 as binary representation. In the following code we run two tests: one on just Word64 and one of 4-tuple of Word64. The difference is that we just add the Word64 case:\r\n\r\n{{{\r\n➜ ghc-bug stack exec performance-bug-pair-2\r\n\"Generated\"\r\nbenchmarking 64 columns/raw unbox vectors\r\ntime 337.6 μs (336.1 μs .. 339.3 μs)\r\n 0.999 R² (0.998 R² .. 1.000 R²)\r\nmean 349.6 μs (344.4 μs .. 359.7 μs)\r\nstd dev 23.22 μs (15.39 μs .. 38.22 μs)\r\nvariance introduced by outliers: 60% (severely inflated)\r\n\r\nbenchmarking 64 columns/binary packed\r\ntime 21.66 μs (21.53 μs .. 21.79 μs)\r\n 1.000 R² (0.999 R² .. 1.000 R²)\r\nmean 21.68 μs (21.53 μs .. 21.89 μs)\r\nstd dev 613.2 ns (466.0 ns .. 806.0 ns)\r\nvariance introduced by outliers: 30% (moderately inflated)\r\n\r\nbenchmarking 256 columns/raw unbox vectors\r\ntime 344.5 μs (341.6 μs .. 348.2 μs)\r\n 0.999 R² (0.999 R² .. 1.000 R²)\r\nmean 345.1 μs (342.5 μs .. 349.3 μs)\r\nstd dev 10.66 μs (7.997 μs .. 16.34 μs)\r\nvariance introduced by outliers: 25% (moderately inflated)\r\n\r\nbenchmarking 256 columns/binary packed\r\ntime 28.04 μs (27.70 μs .. 28.46 μs)\r\n 0.999 R² (0.999 R² .. 1.000 R²)\r\nmean 28.05 μs (27.85 μs .. 28.30 μs)\r\nstd dev 758.2 ns (628.2 ns .. 907.6 ns)\r\nvariance introduced by outliers: 27% (moderately inflated)\r\n}}}\r\n\r\nI made a variant of code with simpler accumulating function (in our code we accumulate pair of integers, simplified accumulator work on one integer). GHC 8.2.2 in that case losses speed-up with 4-tuples:\r\n\r\n{{{\r\n➜ ghc-bug stack exec performance-bug-2\r\n\"Generated\"\r\nbenchmarking 64 columns/raw unbox vectors\r\ntime 333.8 μs (333.0 μs .. 335.1 μs)\r\n 1.000 R² (0.999 R² .. 1.000 R²)\r\nmean 333.6 μs (332.4 μs .. 335.8 μs)\r\nstd dev 5.651 μs (3.233 μs .. 9.582 μs)\r\n\r\nbenchmarking 64 columns/binary packed\r\ntime 39.06 μs (38.98 μs .. 39.14 μs)\r\n 1.000 R² (1.000 R² .. 1.000 R²)\r\nmean 38.94 μs (38.83 μs .. 39.14 μs)\r\nstd dev 495.0 ns (310.2 ns .. 782.1 ns)\r\n\r\nbenchmarking 256 columns/raw unbox vectors\r\ntime 336.9 μs (336.2 μs .. 337.9 μs)\r\n 1.000 R² (1.000 R² .. 1.000 R²)\r\nmean 337.5 μs (336.2 μs .. 339.8 μs)\r\nstd dev 5.757 μs (2.946 μs .. 8.979 μs)\r\n\r\nbenchmarking 256 columns/binary packed\r\ntime 239.8 μs (237.6 μs .. 243.0 μs)\r\n 0.998 R² (0.996 R² .. 0.999 R²)\r\nmean 251.4 μs (247.9 μs .. 259.8 μs)\r\nstd dev 11.50 μs (5.662 μs .. 19.79 μs)\r\nvariance introduced by outliers: 37% (moderately inflated)\r\n}}}\r\n\r\nIn GHC 8.0.2 we have speed-up in both cases.\r\n\r\nWhat may be related: using random-fu to generate random numbers seems to produce broken code on GHC 8.2.2 (the `performance-bug-rfu.hs` source).\r\n\r\nShort description of attached sources:\r\n- performance-bug-pair-2.hs: using two binary representations\r\n- performance-bug-pair-1.hs: using one binary representation (one case commented)\r\n- performance-bug-1.hs: using one binary representation with simplified accumulator\r\n- performance-bug-2.hs: using two binary representation with simplified accumulator\r\n- performance-bug-rfu.hs: using random-fu to generate data (optional)\r\n- stack-8.0.yaml: stack file for GHC-8.0.2\r\n- stack-8.2.yaml: stack file for GHC-8.2.2\r\n- stack-nightly.yaml: stack file for GHC-8.4\r\n- performance-bug.cabal: to be able to stack build everything.","type_of_failure":"OtherFailure","blocking":[]} -->⊥Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/14789GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at p...2021-09-16T10:04:36ZKevinBuhrGHCi fails to garbage collect declaration `l = length [1..10^8]` entered at promptThis was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and-then-calculating-len-causes-ghc-to-consume-lots).
With GHC 8.2.2, assigning the length of a large list as a top-level d...This was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and-then-calculating-len-causes-ghc-to-consume-lots).
With GHC 8.2.2, assigning the length of a large list as a top-level declaration at the GHCi prompt and evaluating it:
```
Prelude> l = length [1..10^8]
Prelude> l
10000000
Prelude>
```
allocates about 7 gigs of memory before displaying a result, and then memory continues to grow over the next few seconds (at the idle GHCi prompt) until 10 gigs of memory has been allocated. None of it is freed until the interpreter session ends.
In contrast, directly evaluating the expression or assigning it with a let-statement does \*\*not\*\* exhibit this behavior:
```
Prelude> length [1..10^8]
10000000
Prelude> let l = length [1..10^8]
Prelude> l
10000000
Prelude>
```
Also, loading the top-level declaration from a file and then evaluating it at the prompt does \*\*not\*\* exhibit the problem.
I took a look at Ticket [14336](ticket:) and applied the `-fno-it` patch referenced there. This slightly changed the pattern of memory usage: it grew to about 4 gigs before displaying the result, but then continued to grow for several seconds at the GHCi prompt before landing at about 10 gigs.
I verified that the bug still exists on the current "master" branch (though I didn't check the "ghc-8.4" branch).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and-then-calculating-len-causes-ghc-to-consume-lots).\r\n\r\nWith GHC 8.2.2, assigning the length of a large list as a top-level declaration at the GHCi prompt and evaluating it:\r\n\r\n{{{\r\nPrelude> l = length [1..10^8]\r\nPrelude> l\r\n10000000\r\nPrelude>\r\n}}}\r\n\r\nallocates about 7 gigs of memory before displaying a result, and then memory continues to grow over the next few seconds (at the idle GHCi prompt) until 10 gigs of memory has been allocated. None of it is freed until the interpreter session ends.\r\n\r\nIn contrast, directly evaluating the expression or assigning it with a let-statement does **not** exhibit this behavior:\r\n\r\n{{{\r\nPrelude> length [1..10^8]\r\n10000000\r\nPrelude> let l = length [1..10^8]\r\nPrelude> l\r\n10000000\r\nPrelude>\r\n}}}\r\n\r\nAlso, loading the top-level declaration from a file and then evaluating it at the prompt does **not** exhibit the problem.\r\n\r\nI took a look at Ticket [ticket: 14336] and applied the `-fno-it` patch referenced there. This slightly changed the pattern of memory usage: it grew to about 4 gigs before displaying the result, but then continued to grow for several seconds at the GHCi prompt before landing at about 10 gigs.\r\n\r\nI verified that the bug still exists on the current \"master\" branch (though I didn't check the \"ghc-8.4\" branch).","type_of_failure":"OtherFailure","blocking":[]} -->9.2.1ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/14613Validate Failure On OSX -- implicit fall through error for machO linker suppo...2019-07-07T18:16:17ZCarter SchonwaldValidate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5)seems like validate for OSX needs some TLC, heres a bug from the linker code that maybe could use an eyeball or two. Phyx suggests someone familiar with the code base could simply do
` __attribute__ ((fallthrough)); `, which is allegedly...seems like validate for OSX needs some TLC, heres a bug from the linker code that maybe could use an eyeball or two. Phyx suggests someone familiar with the code base could simply do
` __attribute__ ((fallthrough)); `, which is allegedly also supported by clang?
```
"inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-DDTRACE -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DDYNAMIC -optc-DRtsWay=\"rts_dyn\" -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/posix/GetTime.c -o rts/dist/build/posix/GetTime.dyn_o
rts/linker/MachO.c: In function 'ocGetNames_MachO':
rts/linker/MachO.c:1532:17: error:
error: this statement may fall through [-Werror=implicit-fallthrough=]
secArray[i].info->relocation_info
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
= (MachORelocationInfo*)(oc->image + section->reloff);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
1532 | = (MachORelocationInfo*)(oc->image + section->reloff);
| ^
rts/linker/MachO.c:1534:13: error:
note: here
default: {
^~~~~~~
|
1534 | default: {
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erikd@mega-nerd.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5)","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["erikd@mega-nerd.com"],"type":"Bug","description":"seems like validate for OSX needs some TLC, heres a bug from the linker code that maybe could use an eyeball or two. Phyx suggests someone familiar with the code base could simply do \r\n` __attribute__ ((fallthrough)); `, which is allegedly also supported by clang?\r\n\r\n{{{\r\n\r\n\"inplace/bin/ghc-stage1\" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-DDTRACE -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DDYNAMIC -optc-DRtsWay=\\\"rts_dyn\\\" -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/posix/GetTime.c -o rts/dist/build/posix/GetTime.dyn_o\r\nrts/linker/MachO.c: In function 'ocGetNames_MachO':\r\n\r\nrts/linker/MachO.c:1532:17: error:\r\n error: this statement may fall through [-Werror=implicit-fallthrough=]\r\n secArray[i].info->relocation_info\r\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n = (MachORelocationInfo*)(oc->image + section->reloff);\r\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n |\r\n1532 | = (MachORelocationInfo*)(oc->image + section->reloff);\r\n | ^\r\n\r\nrts/linker/MachO.c:1534:13: error:\r\n note: here\r\n default: {\r\n ^~~~~~~\r\n |\r\n1534 | default: {\r\n\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/14382The 'impossible' happened whilst installing gi-gtk via cabal2019-07-07T18:17:14ZmaartenjacobsThe 'impossible' happened whilst installing gi-gtk via cabalI've been trying to install gi-gtk using "cabal install gi-gtk". In the process I upgraded to the most recent stable GHC and cabal. I've also installed gtk3 libraries which I thought were necessary.
```
...
[91 of 95] Compiling GI.Pango...I've been trying to install gi-gtk using "cabal install gi-gtk". In the process I upgraded to the most recent stable GHC and cabal. I've also installed gtk3 libraries which I thought were necessary.
```
...
[91 of 95] Compiling GI.Pango.Objects.Layout ( GI/Pango/Objects/Layout.hs, dist/build/GI/Pango/Objects/Layout.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.1 for x86_64-unknown-linux):
tcIfaceGlobal (local): not found
You are in a maze of twisty little passages, all alike.
While forcing the thunk for TyThing Layout
which was lazily initialized by initIfaceCheck typecheckLoop,
I tried to tie the knot, but I couldn't find Layout
in the current type environment.
If you are developing GHC, please read Note [Tying the knot]
and Note [Type-checking inside the knot].
Consider rebuilding GHC with profiling for a better stack trace.
Contents of current type environment: []
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/iface/TcIface.hs:1696:23 in ghc:TcIface
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Failed to install gi-pango-1.0.15
cabal: Error: some packages failed to install:
gi-gdk-3.0.14-INozoUgbf2HFkX3VeIwKfl depends on gi-gdk-3.0.14 which failed to
install.
gi-gtk-3.0.17-1AObKz0Ppj5GXVupmEC7Yc depends on gi-gtk-3.0.17 which failed to
install.
gi-pango-1.0.15-E4HLwHGC2n62ObUIQeuwp8 failed during the building phase. The
exception was:
ExitFailure 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The 'impossible' happened whilst installing gi-gtk via cabal","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["gtk,","pango"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've been trying to install gi-gtk using \"cabal install gi-gtk\". In the process I upgraded to the most recent stable GHC and cabal. I've also installed gtk3 libraries which I thought were necessary. \r\n\r\n{{{\r\n...\r\n[91 of 95] Compiling GI.Pango.Objects.Layout ( GI/Pango/Objects/Layout.hs, dist/build/GI/Pango/Objects/Layout.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.1 for x86_64-unknown-linux):\r\n\ttcIfaceGlobal (local): not found\r\n You are in a maze of twisty little passages, all alike.\r\n While forcing the thunk for TyThing Layout\r\n which was lazily initialized by initIfaceCheck typecheckLoop,\r\n I tried to tie the knot, but I couldn't find Layout\r\n in the current type environment.\r\n If you are developing GHC, please read Note [Tying the knot]\r\n and Note [Type-checking inside the knot].\r\n Consider rebuilding GHC with profiling for a better stack trace.\r\n Contents of current type environment: []\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/iface/TcIface.hs:1696:23 in ghc:TcIface\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nFailed to install gi-pango-1.0.15\r\ncabal: Error: some packages failed to install:\r\ngi-gdk-3.0.14-INozoUgbf2HFkX3VeIwKfl depends on gi-gdk-3.0.14 which failed to\r\ninstall.\r\ngi-gtk-3.0.17-1AObKz0Ppj5GXVupmEC7Yc depends on gi-gtk-3.0.17 which failed to\r\ninstall.\r\ngi-pango-1.0.15-E4HLwHGC2n62ObUIQeuwp8 failed during the building phase. The\r\nexception was:\r\nExitFailure 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.3https://gitlab.haskell.org/ghc/ghc/-/issues/14295tagToEnum# leads to some silly closures2019-09-05T14:07:16ZDavid FeuertagToEnum# leads to some silly closuresI don't know how important this is in practice, but it looks unfortunate.
Suppose I write
```hs
foo :: (Bool -> a) -> Int# -> a
foo f x = f (tagToEnum# x)
```
Since `tagToEnum#` can fail, GHC compiles this to
```hs
foo
= \ (@ a_a10...I don't know how important this is in practice, but it looks unfortunate.
Suppose I write
```hs
foo :: (Bool -> a) -> Int# -> a
foo f x = f (tagToEnum# x)
```
Since `tagToEnum#` can fail, GHC compiles this to
```hs
foo
= \ (@ a_a10v)
(f_s1by [Occ=Once!] :: GHC.Types.Bool -> a_a10v)
(x_s1bz [Occ=Once] :: GHC.Prim.Int#) ->
let {
sat_s1bA [Occ=Once] :: GHC.Types.Bool
[LclId]
sat_s1bA = GHC.Prim.tagToEnum# @ GHC.Types.Bool x_s1bz } in
f_s1by sat_s1bA
```
That seems pretty bad! We know that `tagToEnum#` is applied to `Bool`, so we can transform this to something like
```hs
foo f x = case leWord# (intToWord# x) 1## of
1# -> f $! tagToEnum# x
_ -> f (error "tagToEnum# was used at Bool with tag ...")
```
which avoids an extra closure at the cost of a single `Word#` comparison. The same goes for arbitrary known enumeration types. I suspect the right place to fix this up is in CorePrep.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/14226Common Block Elimination pass doesn't eliminate common blocks2021-09-07T15:40:17ZBen GamariCommon Block Elimination pass doesn't eliminate common blocksIn #14222 it was noted that something appears to be broken in `CmmCommonBlockElim`. Consider the program from that ticket,
```hs
module T14221 where
import Data.Text as T
isNumeric :: Text -> Bool
isNumeric t =
T.all isNumeric' t ...In #14222 it was noted that something appears to be broken in `CmmCommonBlockElim`. Consider the program from that ticket,
```hs
module T14221 where
import Data.Text as T
isNumeric :: Text -> Bool
isNumeric t =
T.all isNumeric' t && T.any isNumber t
where
isNumber c = '0' <= c && c <= '9'
isNumeric' c = isNumber c
|| c == 'e'
|| c == 'E'
|| c == '.'
|| c == '-'
|| c == '+'
```
This program produces six copies of a block of the form,
```
c6JT:
R2 = I64[R1 + 7];
R1 = P64[Sp + 8];
Sp = Sp + 16;
call $wloop_all_s6CQ_info(R2, R1) args: 8, res: 0, upd: 8;
```
in the `-ddump-opt-cmm` output, which are manifest in the assembler as,
```asm
block_c6JT_info:
_c6JT:
movq 7(%rbx),%r14
movq 8(%rbp),%rbx
addq $16,%rbp
jmp $wloop_all_s6CQ_info
```
CBE really ought to be catching these.⊥Michal TerepetaMichal Terepetahttps://gitlab.haskell.org/ghc/ghc/-/issues/14057Upstream Alpine Linux distribution patches2019-07-07T18:18:40ZBen GamariUpstream Alpine Linux distribution patchesAlpine Linux has a variety of [patches](https://git.alpinelinux.org/cgit/aports/tree/community/ghc?h=3.6-stable) to allow GHC to build against the musl libc implementation. Let's get these upstream.
Here is my take on the patches:
- `0...Alpine Linux has a variety of [patches](https://git.alpinelinux.org/cgit/aports/tree/community/ghc?h=3.6-stable) to allow GHC to build against the musl libc implementation. Let's get these upstream.
Here is my take on the patches:
- `0000-alpine.patch`: This is a no-brainer. Merged as 9ae24bb615416b3e8d972d45ebe3dd281242d213.
- `0000-bootstrap.patch`: I really don't know about this one. The motivation is quite unclear. Needs discussion.
- `0001-rm-ghc-pwd.patch`: Already merged in 4c56ad36ee0d1f8b6f1b2bc0d8fff1c9acd1a389.
- `0002-Correct-issue-with-libffi-and-glibc.patch`: This is, unfortunately, a `libffi` fix, not a GHC fix. I'm not enthusiastic about patching libffi like this. However, `libffi`'s upstream is quite unresponsive and we are waiting for them to act on a number of issues, so perhaps we'll need to reconsider this. I've created #14056 to track this.
- `0003-do-not-use-SHELL.patch`: Looks reasonable to me. Merged as a10c2e6e9e9af3addbf91c0bb374257fb6c72553.
- `0004-reproducible-tmp-names.patch`: Seems plausible.
- `0005-buildpath-abi-stability.patch`: There's some discussion in #10424.
- `0006-fix-madvise.patch`: Merged in 6576bf83cdf4eac05eb88a24aa934a736c91e3da. See #12865
- `0007-build-hp2ps-twice.patch`, `0008-build-unlit-twice.patch`: Why?8.2.3https://gitlab.haskell.org/ghc/ghc/-/issues/14044ghc-8.2.1 installation fails on OpenBSD 6.02019-07-07T18:18:44Zromanzolotarevghc-8.2.1 installation fails on OpenBSD 6.0I have tried to install ghc-8.2.1 directly and via stack. Getting the same error:
```
ghc-cabal: can't load library 'libc.so.89.3'
```
ghc requires 'libc.so.89.3', while OpenBSD 6.0 has 'libc.so.88.0' by default.
```
# find / -name li...I have tried to install ghc-8.2.1 directly and via stack. Getting the same error:
```
ghc-cabal: can't load library 'libc.so.89.3'
```
ghc requires 'libc.so.89.3', while OpenBSD 6.0 has 'libc.so.88.0' by default.
```
# find / -name libc.so*
/usr/lib/libc.so.88.0
/usr/lib/libc.so.88.0.a
```
----
Full log
```
# /root/.cabal/bin/stack setup
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.
Running /usr/local/bin/gmake install in directory /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/ghc-8.2.1/ exited with ExitFailure 2
/usr/local/bin/gmake --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES
"rm" -f utils/ghc-pkg/dist-install/build/Version.hs
echo "module Version where" >> utils/ghc-pkg/dist-install/build/Version.hs
echo "version, targetOS, targetARCH :: String" >> utils/ghc-pkg/dist-install/build/Version.hs
echo "version = \"8.2.1\"" >> utils/ghc-pkg/dist-install/build/Version.hs
echo "targetOS = \"openbsd\"" >> utils/ghc-pkg/dist-install/build/Version.hs
echo "targetARCH = \"x86_64\"" >> utils/ghc-pkg/dist-install/build/Version.hs
"rm" -f utils/ghc-pkg/dist/build/Version.hs
echo "module Version where" >> utils/ghc-pkg/dist/build/Version.hs
echo "version, targetOS, targetARCH :: String" >> utils/ghc-pkg/dist/build/Version.hs
echo "version = \"8.2.1\"" >> utils/ghc-pkg/dist/build/Version.hs
echo "targetOS = \"openbsd\"" >> utils/ghc-pkg/dist/build/Version.hs
echo "targetARCH = \"x86_64\"" >> utils/ghc-pkg/dist/build/Version.hs
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
echo 'exeprog="hp2ps"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
cat utils/hp2ps/hp2ps.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1"
create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1"
echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1"
echo 'exec "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" --interactive "$@"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1"
chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci"
ln -s ghci-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/." && /usr/bin/install -c -m 644 includes/./*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/./" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts" && /usr/bin/install -c -m 644 includes/rts/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/prof" && /usr/bin/install -c -m 644 includes/rts/prof/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/prof/" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/storage" && /usr/bin/install -c -m 644 includes/rts/storage/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/storage/" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/stg" && /usr/bin/install -c -m 644 includes/stg/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/stg/" && true
/usr/bin/install -c -m 644 includes/ghcautoconf.h includes/ghcplatform.h includes/ghcversion.h includes/dist-derivedconstants/header/DerivedConstants.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
echo 'exeprog="haddock"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
cat utils/haddock/haddock.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/latex/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/haddock-util.js "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Classic.theme/haskell_icon.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Classic.theme/minus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Classic.theme/plus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Classic.theme/xhaddock.css "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean.std-theme/hslogo-16.png "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean.std-theme/minus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean.std-theme/ocean.css "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean.std-theme/plus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean.std-theme/synopsis.png "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/solarized.css "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/highlight.js "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/"
/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/latex/haddock.sty "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/latex/"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock"
ln -s haddock-ghc-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
echo 'exeprog="hsc2hs"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
echo 'HSC2HS_EXTRA="--cflag=-std=gnu99 --cflag=-fno-stack-protector --lflag=-Wl,-z,wxneeded"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
cat utils/hsc2hs/hsc2hs.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs"
/usr/bin/install -c -m 644 utils/hsc2hs/template-hsc.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
echo 'exeprog="ghc-pkg"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
cat utils/ghc-pkg/ghc-pkg.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg"
ln -s ghc-pkg-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
echo 'exeprog="hpc"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
cat utils/hpc/hpc.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
echo 'exeprog="runghc"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
echo 'ghcprog="ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
cat utils/runghc/runghc.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runhaskell"
ln -s runghc "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runhaskell"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc"
ln -s runghc-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
echo 'exeprog="ghc-stage2"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
echo 'executablename="$exedir/ghc"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
cat ghc/ghc.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1"
"rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc"
ln -s ghc-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man/man1"
/usr/bin/install -c -m 644 docs/users_guide/build-man/ghc.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man/man1"
# driver/ghc-usage.txt driver/ghci-usage.txt includes/dist-derivedconstants/header/platformConstants settings = libraries to install
# "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" = directory to install to
#
# The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because
# on Win64, "install -s" calls a strip that doesn't understand 64bit binaries.
# For some reason, this means the DLLs end up non-executable, which means
# executables that use them just segfault.
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"
for i in driver/ghc-usage.txt driver/ghci-usage.txt includes/dist-derivedconstants/header/platformConstants settings; do case $i in *.a) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"; true "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" ; strip "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" ;; *.dylib) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1";; *) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"; esac; done
gcc -E -undef -traditional -P -DINSTALLING -DLIB_DIR='"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' -DINCLUDE_DIR='"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include"' -DFFI_INCLUDE_DIR=/usr/local/include -DFFI_LIB_DIR=/usr/local/lib '-DFFI_LIB=' -x c -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header rts/package.conf.in -o rts/dist/package.conf.install.raw
grep -v '^#pragma GCC' rts/dist/package.conf.install.raw | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >rts/dist/package.conf.install
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"
for i in utils/unlit/dist/build/tmp/unlit utils/hp2ps/dist/build/tmp/hp2ps utils/hp2ps/dist/build/tmp/hp2ps utils/haddock/dist/build/tmp/haddock utils/haddock/dist/build/tmp/haddock utils/hsc2hs/dist-install/build/tmp/hsc2hs utils/hsc2hs/dist-install/build/tmp/hsc2hs utils/ghc-pkg/dist-install/build/tmp/ghc-pkg utils/ghc-pkg/dist-install/build/tmp/ghc-pkg utils/hpc/dist-install/build/tmp/hpc utils/hpc/dist-install/build/tmp/hpc utils/runghc/dist-install/build/tmp/runghc utils/runghc/dist-install/build/tmp/runghc ghc/stage2/build/tmp/ghc-stage2 ghc/stage2/build/tmp/ghc-stage2 iserv/stage2/build/tmp/ghc-iserv iserv/stage2_p/build/tmp/ghc-iserv-prof iserv/stage2_dyn/build/tmp/ghc-iserv-dyn; do \
/usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"; \
done
"mv" "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin/ghc-stage2" "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin/ghc"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"
"rm" -rf "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/package.conf.d"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/package.conf.d"
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"
# rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts-ghc8.2.1.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug-ghc8.2.1.so rts/dist/build/libHSrts_thr-ghc8.2.1.so rts/dist/build/libHSrts_thr_debug-ghc8.2.1.so rts/dist/build/libHSrts_l-ghc8.2.1.so rts/dist/build/libHSrts_thr_l-ghc8.2.1.so = libraries to install
# "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" = directory to install to
#
# The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because
# on Win64, "install -s" calls a strip that doesn't understand 64bit binaries.
# For some reason, this means the DLLs end up non-executable, which means
# executables that use them just segfault.
/usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"
for i in rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts-ghc8.2.1.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug-ghc8.2.1.so rts/dist/build/libHSrts_thr-ghc8.2.1.so rts/dist/build/libHSrts_thr_debug-ghc8.2.1.so rts/dist/build/libHSrts_l-ghc8.2.1.so rts/dist/build/libHSrts_thr_l-ghc8.2.1.so; do case $i in *.a) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"; true "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" ; strip "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" ;; *.dylib) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts";; *) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"; esac; done
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/ghc-prim dist-install "strip" '' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/doc/ghc-8.2.1/html/libraries' 'v p dyn'
ghc-cabal: can't load library 'libc.so.89.3'
gmake[1]: *** [ghc.mk:991: install_packages] Error 4
gmake: *** [Makefile:51: install] Error 2
Error: Error encountered while installing GHC with
gmake install
run in /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/ghc-8.2.1/
The following directories may now contain files, but won't be used by stack:
- /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/
- /root/.stack/programs/x86_64-openbsd/ghc-8.2.1/
Installing GHC ...
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-8.2.1 installation fails on OpenBSD 6.0","status":"New","operating_system":"","component":"None","related":[],"milestone":"Research needed","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have tried to install ghc-8.2.1 directly and via stack. Getting the same error:\r\n\r\n{{{\r\nghc-cabal: can't load library 'libc.so.89.3'\r\n}}}\r\n\r\nghc requires 'libc.so.89.3', while OpenBSD 6.0 has 'libc.so.88.0' by default.\r\n\r\n{{{\r\n# find / -name libc.so*\r\n/usr/lib/libc.so.88.0\r\n/usr/lib/libc.so.88.0.a\r\n}}}\r\n\r\n\r\n----\r\n\r\nFull log\r\n\r\n{{{\r\n# /root/.cabal/bin/stack setup\r\nPreparing to install GHC to an isolated location.\r\nThis will not interfere with any system-level installation.\r\nAlready downloaded.\r\nRunning /usr/local/bin/gmake install in directory /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/ghc-8.2.1/ exited with ExitFailure 2\r\n\r\n/usr/local/bin/gmake --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES\r\n\"rm\" -f utils/ghc-pkg/dist-install/build/Version.hs\r\necho \"module Version where\" >> utils/ghc-pkg/dist-install/build/Version.hs\r\necho \"version, targetOS, targetARCH :: String\" >> utils/ghc-pkg/dist-install/build/Version.hs\r\necho \"version = \\\"8.2.1\\\"\" >> utils/ghc-pkg/dist-install/build/Version.hs\r\necho \"targetOS = \\\"openbsd\\\"\" >> utils/ghc-pkg/dist-install/build/Version.hs\r\necho \"targetARCH = \\\"x86_64\\\"\" >> utils/ghc-pkg/dist-install/build/Version.hs\r\n\"rm\" -f utils/ghc-pkg/dist/build/Version.hs\r\necho \"module Version where\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"version, targetOS, targetARCH :: String\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"version = \\\"8.2.1\\\"\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"targetOS = \\\"openbsd\\\"\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"targetARCH = \\\"x86_64\\\"\" >> utils/ghc-pkg/dist/build/Version.hs\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\ncreate () { touch \"$1\" && chmod 755 \"$1\" ; } && create \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\necho '#!/bin/sh' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\necho 'exedir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\necho 'exeprog=\"hp2ps\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\necho 'executablename=\"$exedir/$exeprog\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\necho 'datadir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\necho 'bindir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\necho 'topdir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\ncat utils/hp2ps/hp2ps.wrapper >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\nchmod +x \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1\"\r\ncreate () { touch \"$1\" && chmod 755 \"$1\" ; } && create \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1\"\r\necho '#!/bin/sh' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1\"\r\necho 'exec \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\" --interactive \"$@\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1\"\r\nchmod +x \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci\"\r\nln -s ghci-8.2.1 \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/.\" && /usr/bin/install -c -m 644 includes/./*.h \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/./\" && /usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts\" && /usr/bin/install -c -m 644 includes/rts/*.h \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/\" && /usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/prof\" && /usr/bin/install -c -m 644 includes/rts/prof/*.h \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/prof/\" && /usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/storage\" && /usr/bin/install -c -m 644 includes/rts/storage/*.h \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/storage/\" && /usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/stg\" && /usr/bin/install -c -m 644 includes/stg/*.h \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/stg/\" && true\r\n/usr/bin/install -c -m 644 includes/ghcautoconf.h includes/ghcplatform.h includes/ghcversion.h includes/dist-derivedconstants/header/DerivedConstants.h \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\ncreate () { touch \"$1\" && chmod 755 \"$1\" ; } && create \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\necho '#!/bin/sh' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\necho 'exedir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\necho 'exeprog=\"haddock\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\necho 'executablename=\"$exedir/$exeprog\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\necho 'datadir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\necho 'bindir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\necho 'topdir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\ncat utils/haddock/haddock.wrapper >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\nchmod +x \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/latex/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/haddock-util.js \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Classic.theme/haskell_icon.gif \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Classic.theme/minus.gif \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Classic.theme/plus.gif \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Classic.theme/xhaddock.css \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean.std-theme/hslogo-16.png \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean.std-theme/minus.gif \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean.std-theme/ocean.css \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean.std-theme/plus.gif \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean.std-theme/synopsis.png \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean.std-theme/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/solarized.css \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/highlight.js \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/\"\r\n/usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/latex/haddock.sty \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/latex/\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock\"\r\nln -s haddock-ghc-8.2.1 \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\ncreate () { touch \"$1\" && chmod 755 \"$1\" ; } && create \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\necho '#!/bin/sh' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\necho 'exedir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\necho 'exeprog=\"hsc2hs\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\necho 'executablename=\"$exedir/$exeprog\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\necho 'datadir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\necho 'bindir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\necho 'topdir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\necho 'HSC2HS_EXTRA=\"--cflag=-std=gnu99 --cflag=-fno-stack-protector --lflag=-Wl,-z,wxneeded\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\ncat utils/hsc2hs/hsc2hs.wrapper >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\nchmod +x \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs\"\r\n/usr/bin/install -c -m 644 utils/hsc2hs/template-hsc.h \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\ncreate () { touch \"$1\" && chmod 755 \"$1\" ; } && create \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\necho '#!/bin/sh' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\necho 'exedir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\necho 'exeprog=\"ghc-pkg\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\necho 'executablename=\"$exedir/$exeprog\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\necho 'datadir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\necho 'bindir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\necho 'topdir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\ncat utils/ghc-pkg/ghc-pkg.wrapper >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\nchmod +x \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg\"\r\nln -s ghc-pkg-8.2.1 \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\ncreate () { touch \"$1\" && chmod 755 \"$1\" ; } && create \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\necho '#!/bin/sh' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\necho 'exedir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\necho 'exeprog=\"hpc\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\necho 'executablename=\"$exedir/$exeprog\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\necho 'datadir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\necho 'bindir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\necho 'topdir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\ncat utils/hpc/hpc.wrapper >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\nchmod +x \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\ncreate () { touch \"$1\" && chmod 755 \"$1\" ; } && create \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\necho '#!/bin/sh' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\necho 'exedir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\necho 'exeprog=\"runghc\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\necho 'executablename=\"$exedir/$exeprog\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\necho 'datadir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\necho 'bindir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\necho 'topdir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\necho 'ghcprog=\"ghc-8.2.1\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\ncat utils/runghc/runghc.wrapper >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\nchmod +x \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runhaskell\"\r\nln -s runghc \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runhaskell\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc\"\r\nln -s runghc-8.2.1 \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\ncreate () { touch \"$1\" && chmod 755 \"$1\" ; } && create \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\necho '#!/bin/sh' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\necho 'exedir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\necho 'exeprog=\"ghc-stage2\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\necho 'executablename=\"$exedir/$exeprog\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\necho 'datadir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\necho 'bindir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\necho 'topdir=\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\necho 'executablename=\"$exedir/ghc\"' >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\ncat ghc/ghc.wrapper >> \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\nchmod +x \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1\"\r\n\"rm\" -f \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc\"\r\nln -s ghc-8.2.1 \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man/man1\"\r\n/usr/bin/install -c -m 644 docs/users_guide/build-man/ghc.1 \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man/man1\"\r\n# driver/ghc-usage.txt driver/ghci-usage.txt includes/dist-derivedconstants/header/platformConstants settings = libraries to install\r\n# \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\" = directory to install to\r\n#\r\n# The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because\r\n# on Win64, \"install -s\" calls a strip that doesn't understand 64bit binaries.\r\n# For some reason, this means the DLLs end up non-executable, which means\r\n# executables that use them just segfault.\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"\r\nfor i in driver/ghc-usage.txt driver/ghci-usage.txt includes/dist-derivedconstants/header/platformConstants settings; do case $i in *.a) /usr/bin/install -c -m 644 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"; true \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\" ; strip \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\" ;; *.dylib) /usr/bin/install -c -m 755 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\";; *) /usr/bin/install -c -m 644 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"; esac; done\r\ngcc -E -undef -traditional -P -DINSTALLING -DLIB_DIR='\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"' -DINCLUDE_DIR='\"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include\"' -DFFI_INCLUDE_DIR=/usr/local/include -DFFI_LIB_DIR=/usr/local/lib '-DFFI_LIB=' -x c -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header rts/package.conf.in -o rts/dist/package.conf.install.raw\r\ngrep -v '^#pragma GCC' rts/dist/package.conf.install.raw | sed -e 's/\"\"//g' -e 's/:[ ]*,/: /g' >rts/dist/package.conf.install\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin\"\r\nfor i in utils/unlit/dist/build/tmp/unlit utils/hp2ps/dist/build/tmp/hp2ps utils/hp2ps/dist/build/tmp/hp2ps utils/haddock/dist/build/tmp/haddock utils/haddock/dist/build/tmp/haddock utils/hsc2hs/dist-install/build/tmp/hsc2hs utils/hsc2hs/dist-install/build/tmp/hsc2hs utils/ghc-pkg/dist-install/build/tmp/ghc-pkg utils/ghc-pkg/dist-install/build/tmp/ghc-pkg utils/hpc/dist-install/build/tmp/hpc utils/hpc/dist-install/build/tmp/hpc utils/runghc/dist-install/build/tmp/runghc utils/runghc/dist-install/build/tmp/runghc ghc/stage2/build/tmp/ghc-stage2 ghc/stage2/build/tmp/ghc-stage2 iserv/stage2/build/tmp/ghc-iserv iserv/stage2_p/build/tmp/ghc-iserv-prof iserv/stage2_dyn/build/tmp/ghc-iserv-dyn; do \\\r\n /usr/bin/install -c -m 755 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin\"; \\\r\ndone\r\n\"mv\" \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin/ghc-stage2\" \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin/ghc\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1\"\r\n\"rm\" -rf \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/package.conf.d\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/package.conf.d\"\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts\"\r\n# rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts-ghc8.2.1.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug-ghc8.2.1.so rts/dist/build/libHSrts_thr-ghc8.2.1.so rts/dist/build/libHSrts_thr_debug-ghc8.2.1.so rts/dist/build/libHSrts_l-ghc8.2.1.so rts/dist/build/libHSrts_thr_l-ghc8.2.1.so = libraries to install\r\n# \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts\" = directory to install to\r\n#\r\n# The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because\r\n# on Win64, \"install -s\" calls a strip that doesn't understand 64bit binaries.\r\n# For some reason, this means the DLLs end up non-executable, which means\r\n# executables that use them just segfault.\r\n/usr/bin/install -c -m 755 -d \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts\"\r\nfor i in rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts-ghc8.2.1.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug-ghc8.2.1.so rts/dist/build/libHSrts_thr-ghc8.2.1.so rts/dist/build/libHSrts_thr_debug-ghc8.2.1.so rts/dist/build/libHSrts_l-ghc8.2.1.so rts/dist/build/libHSrts_thr_l-ghc8.2.1.so; do case $i in *.a) /usr/bin/install -c -m 644 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts\"; true \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts\"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts\" ; strip \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts\"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts\" ;; *.dylib) /usr/bin/install -c -m 755 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts\";; *) /usr/bin/install -c -m 644 $i \"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts\"; esac; done\r\n\"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist\" copy libraries/ghc-prim dist-install \"strip\" '' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/doc/ghc-8.2.1/html/libraries' 'v p dyn'\r\n\r\nghc-cabal: can't load library 'libc.so.89.3'\r\ngmake[1]: *** [ghc.mk:991: install_packages] Error 4\r\ngmake: *** [Makefile:51: install] Error 2\r\n\r\n\r\nError: Error encountered while installing GHC with\r\n gmake install\r\n run in /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/ghc-8.2.1/\r\n\r\nThe following directories may now contain files, but won't be used by stack:\r\n - /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/\r\n - /root/.stack/programs/x86_64-openbsd/ghc-8.2.1/\r\n\r\nInstalling GHC ...\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/14013Bad monads performance2022-07-18T08:52:05Zdanilo2Bad monads performanceHi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled):
```hs
module Main where
import Prelude
import Criterion.Main
import qualified Control....Hi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled):
```hs
module Main where
import Prelude
import Criterion.Main
import qualified Control.Monad.State.Strict as Strict
import qualified Control.Monad.State.Class as State
import Control.DeepSeq (NFData, rnf, force)
import GHC.IO (evaluate)
import Data.Monoid
-----------------------------
-- === Criterion utils === --
-----------------------------
eval :: NFData a => a -> IO a
eval = evaluate . force ; {-# INLINE eval #-}
liftExp :: (Int -> a) -> (Int -> a)
liftExp f = f . (10^) ; {-# INLINE liftExp #-}
expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a)
expCodeGen f i = do
putStrLn $ "generating input code (10e" <> show i <> " chars)"
out <- eval $ liftExp f i
putStrLn "code generated sucessfully"
return out
{-# INLINE expCodeGen #-}
expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int -> Benchmark
expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . nf p ; {-# INLINE expCodeGenBench #-}
-------------------------------
-- === (a*) list parsing === --
-------------------------------
genList_a :: Int -> [Char]
genList_a i = replicate i 'a' ; {-# INLINE genList_a #-}
pureListParser_a :: [Char] -> Bool
pureListParser_a = \case
'a':s -> pureListParser_a s
[] -> True
_ -> False
{-# INLINE pureListParser_a #-}
mtlStateListParser_a :: State.MonadState [Char] m => m Bool
mtlStateListParser_a = State.get >>= \case
'a':s -> State.put s >> mtlStateListParser_a
[] -> return True
_ -> return False
{-# INLINE mtlStateListParser_a #-}
mtlStateListParser_a_typed :: Strict.State [Char] Bool
mtlStateListParser_a_typed = State.get >>= \case
'a':s -> State.put s >> mtlStateListParser_a_typed
[] -> return True
_ -> return False
{-# INLINE mtlStateListParser_a_typed #-}
mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool
mtlStateListParser_a_let = go where
go = Strict.get >>= \case
'a':s -> Strict.put s >> go
[] -> return True
_ -> return False
{-# INLINE mtlStateListParser_a_let #-}
{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}
{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}
main = do
defaultMain
[ bgroup "a*" $
[ bgroup "pure" $ expCodeGenBench genList_a pureListParser_a <$> [6..6]
, bgroup "mtl.State.Strict" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6]
, bgroup "mtl.State.Strict typed" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6]
, bgroup "mtl.State.Strict let" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6]
]
]
```
The code was compiled with following options (and many other variations): `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick-factor=1000 -flate-dmd-anal`
Everything in this code has `INLINE` pragma. The important part we should focus on are these two functions:
```hs
pureListParser_a :: [Char] -> Bool
pureListParser_a = \case
'a':s -> pureListParser_a s
[] -> True
_ -> False
{-# INLINE pureListParser_a #-}
mtlStateListParser_a :: State.MonadState [Char] m => m Bool
mtlStateListParser_a = State.get >>= \case
'a':s -> State.put s >> mtlStateListParser_a
[] -> return True
_ -> return False
{-# INLINE mtlStateListParser_a #-}
```
Which are just "parsers" accepting strings containing only 'a' characters. The former is pure one, while the later uses `State` to keep the remaining input. The following list contains performance related observations:
1. For the rest of the points, let's call the performance of `pureListParser_a` a "good" one and everything worse a "bad" one.
1. The performance of `mtlStateListParser_a` is bad, it runs 10 times slower than `pureListParser_a`. Inspecting CORE we can observe that GHC jumps between `(# a,b #)` and `(a,b)` representations all the time.
1. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` is good (exactly the same as `pureListParser_a`).
1. If we do NOT use specialize pragma, but we use explicite, non-polymorphic type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool`, the performance is bad (!), identical to the polymorphic version without specialization.
1. If we use SPECIALIZE pragma together with explicite, non-polymorphic type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}` we get the good performance.
1. If we transform `pureListParser_a` to
```hs
mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool
mtlStateListParser_a_let = go where
go = Strict.get >>= \case
'a':s -> Strict.put s >> go
[] -> return True
_ -> return False
{-# INLINE mtlStateListParser_a_let #-}
```
we again get the good performance without the need to use `SPECIALIZE` pragmas.
1. The performance of all the functions that are not optimized as good as `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2.
1. The not-yet documented flag `-fspecialise-aggressively` does NOT affect the results (https://ghc.haskell.org/trac/ghc/ticket/12463).
1. If you do NOT use `INLINE` pragma on functions `mtlStateListParser_a` and `mtlStateListParser_a_typed` their performance is good (so `INLINE` pragma makes it bad until we provide explicit specialization). Moreover, if we use `INLINABLE` pragma instead of `INLINE` on these functions (which logically makes more sense, because they are recursive), performance of the polymorphic one `mtlStateListParser_a` is good, while performance of the explicitly typed `mtlStateListParser_a_typed` is bad until we provide explicite specialization.
The above points raise the following questions:
1. Why GHC does not optimize `mtlStateListParser_a` the same way as `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` comes from?
1. Is there any way to tell GHC to automatically insert `SPECIALIZE` pragmas, especially in performance critical code?
1. Why providing very-explicite type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve the problem unless we use `SPECIALIZE` pragma that tells the same as the signature? (GHC even warns: `SPECIALISE pragma for non-overloaded function ‘mtlStateListParser_a_typed’` but it affects performance.)
1. Why the trick to alias the body of recursive function to a local variable `go` affects the performance in any way, especially when it does NOT bring any variable to the local let scope?
We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several people reported exactly the same observations.⊥Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/13763Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inn...2021-09-07T15:37:04ZjberrymanPerformance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an arrayTesting GHC 8.0.1 against the RC 8.2.0.20170507
I've distilled a smallish test-case from a much larger case in my 'hashabler' library, and validated that the same modifications also make that regression disappear in the real case. It's ...Testing GHC 8.0.1 against the RC 8.2.0.20170507
I've distilled a smallish test-case from a much larger case in my 'hashabler' library, and validated that the same modifications also make that regression disappear in the real case. It's probably possible to get this smaller but I don't know if I'll have time to work on it more for a while:
repro3.hs:
```hs
{-# LANGUAGE BangPatterns #-}
module Main(main) where
import Criterion.Main
import qualified Data.Primitive as P
import Data.Bits
import Data.Word
import Control.DeepSeq
main :: IO ()
main = do
defaultMain
[ env (newByteArr64 5) $ \ ~bs ->
bench "ByteArray 5" $ nf (hashTextSip 99) bs
, env (newByteArr64 8) $ \ ~bs ->
bench "ByteArray 8" $ nf (hashTextSip 99) bs
, env (newByteArr64 512) $ \ ~bs ->
bench "ByteArray 512" $ nf (hashTextSip 99) bs
, env (newByteArr64 1000000) $ \ ~bs ->
bench "ByteArray 1000000" $ nf (hashTextSip 99) bs
]
instance NFData P.ByteArray where rnf _ = ()
newByteArr64 n = P.newAlignedPinnedByteArray (8*n) 8 >>= P.unsafeFreezeByteArray
sipRound :: Word64 -> Word64 -> Word64 -> Word64 -> (Word64, Word64, Word64, Word64)
{-# INLINE sipRound #-}
sipRound v0 v1 v2 v3 = (v3 `xor` v0, v0 `xor` v1, v1 `xor` v2, v2 `xor` v3)
hashTextSip :: Word64 -> P.ByteArray -> Word64
{-# INLINE hashTextSip #-}
hashTextSip h = \ ba ->
let !lenWord16 = P.sizeofByteArray ba `unsafeShiftR` 1
!word16sRem = lenWord16 .&. 3
!word16sIx = lenWord16-word16sRem
!ixFinal = lenWord16-1
!word16sIxWd = word16sIx `unsafeShiftR` 2 -- `div` 4
hash4Word16sLoop hAcc@(!w0,!w1,!w2,!w3) !ix
| ix == word16sIxWd = hashRemainingWord16s hAcc word16sIx
| otherwise =
let w64Dirty = P.indexByteArray ba ix
w64 = clean4xWord16ChunkLE w64Dirty
in hash4Word16sLoop (sipRound (w0 `xor` w64) w1 w2 w3) (ix + 1)
-- NOTE: Removing this causes regression to disappear as well.
hashRemainingWord16s (!w0,!w1,!w2,!w3) !ix
| ix > ixFinal = w0
| otherwise =
let w16 = P.indexByteArray ba ix
in hashRemainingWord16s (sipRound (w0 `xor` (fromIntegral (w16 :: Word16))) w1 w2 w3) (ix+1)
in hash4Word16sLoop (h,1,2,3) 0
clean4xWord16ChunkLE :: Word64 -> Word64
{-# INLINE clean4xWord16ChunkLE #-}
clean4xWord16ChunkLE w64Dirty =
-- NOTE: no regression when just this (8.2 is faster)
-- (((byteSwap64 w64Dirty) `unsafeShiftR` 8) .&. 0x00FF00FF00FF00FF)
-- ...but this is a big regression:
(((byteSwap64 w64Dirty) `unsafeShiftR` 8) .&. 0x00FF00FF00FF00FF)
.|.
(((byteSwap64 w64Dirty) `unsafeShiftL` 8) .&. 0xFF00FF00FF00FF00)
```
Here are the results of the benchmark above on my machine:
On GHC \*\*8.0.1\*\*:
```
benchmarking ByteArray 5
time 24.70 ns (24.00 ns .. 26.25 ns)
0.987 R² (0.967 R² .. 1.000 R²)
mean 24.44 ns (24.13 ns .. 25.80 ns)
std dev 1.859 ns (318.3 ps .. 4.227 ns)
variance introduced by outliers: 86% (severely inflated)
benchmarking ByteArray 8
time 32.66 ns (32.58 ns .. 32.76 ns)
1.000 R² (1.000 R² .. 1.000 R²)
mean 32.79 ns (32.64 ns .. 33.09 ns)
std dev 683.7 ps (365.4 ps .. 1.175 ns)
variance introduced by outliers: 31% (moderately inflated)
benchmarking ByteArray 512
time 1.428 μs (1.382 μs .. 1.522 μs)
0.986 R² (0.970 R² .. 1.000 R²)
mean 1.398 μs (1.384 μs .. 1.454 μs)
std dev 91.12 ns (4.475 ns .. 193.9 ns)
variance introduced by outliers: 76% (severely inflated)
benchmarking ByteArray 1000000
time 2.658 ms (2.653 ms .. 2.663 ms)
1.000 R² (1.000 R² .. 1.000 R²)
mean 2.672 ms (2.665 ms .. 2.691 ms)
std dev 35.00 μs (10.88 μs .. 59.58 μs)
```
And on \*\*GHC 8.2\*\* RC:
```
benchmarking ByteArray 5
time 23.78 ns (23.68 ns .. 23.88 ns)
1.000 R² (1.000 R² .. 1.000 R²)
mean 23.83 ns (23.76 ns .. 23.95 ns)
std dev 298.8 ps (183.2 ps .. 482.5 ps)
variance introduced by outliers: 14% (moderately inflated)
benchmarking ByteArray 8
time 35.81 ns (35.44 ns .. 36.27 ns)
0.999 R² (0.998 R² .. 1.000 R²)
mean 35.56 ns (35.45 ns .. 35.94 ns)
std dev 596.8 ps (134.5 ps .. 1.184 ns)
variance introduced by outliers: 22% (moderately inflated)
benchmarking ByteArray 512
time 1.706 μs (1.698 μs .. 1.716 μs)
1.000 R² (1.000 R² .. 1.000 R²)
mean 1.701 μs (1.698 μs .. 1.707 μs)
std dev 13.27 ns (5.825 ns .. 24.41 ns)
benchmarking ByteArray 1000000
time 3.322 ms (3.284 ms .. 3.377 ms)
0.999 R² (0.998 R² .. 1.000 R²)
mean 3.296 ms (3.287 ms .. 3.332 ms)
std dev 44.62 μs (20.55 μs .. 87.29 μs)
```
Looking at the core wasn't fruitful, but I think dumping the asm shows that this is a case of bad (or worse) register allocation. I've attached two screenshots showing the instructions added (in blue), when moving from the one-line `clean4xWord16ChunkLE` to the two-line version, for both 8.0 and 8.2 (there wasn't anything in the diff besides instances of this change).
It looks in the 8.2 version like we've decided we're out of registers and need to use the stack.
In my real code I'm seeing 35% regression on very long Text, as well as 21% regression on very long ByteString; the latter implementation is similarly structured to `hashTextSip`, but doesn't call `clean4xWord16ChunkLE` but does do a byteswap.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Testing GHC 8.0.1 against the RC 8.2.0.20170507\r\n\r\nI've distilled a smallish test-case from a much larger case in my 'hashabler' library, and validated that the same modifications also make that regression disappear in the real case. It's probably possible to get this smaller but I don't know if I'll have time to work on it more for a while:\r\n\r\nrepro3.hs:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE BangPatterns #-}\r\nmodule Main(main) where\r\n\r\nimport Criterion.Main\r\nimport qualified Data.Primitive as P\r\n\r\nimport Data.Bits\r\nimport Data.Word\r\nimport Control.DeepSeq\r\n\r\nmain :: IO ()\r\nmain = do\r\n defaultMain \r\n [ env (newByteArr64 5) $ \\ ~bs ->\r\n bench \"ByteArray 5\" $ nf (hashTextSip 99) bs\r\n , env (newByteArr64 8) $ \\ ~bs ->\r\n bench \"ByteArray 8\" $ nf (hashTextSip 99) bs\r\n , env (newByteArr64 512) $ \\ ~bs ->\r\n bench \"ByteArray 512\" $ nf (hashTextSip 99) bs\r\n , env (newByteArr64 1000000) $ \\ ~bs ->\r\n bench \"ByteArray 1000000\" $ nf (hashTextSip 99) bs\r\n ]\r\n\r\ninstance NFData P.ByteArray where rnf _ = ()\r\n\r\nnewByteArr64 n = P.newAlignedPinnedByteArray (8*n) 8 >>= P.unsafeFreezeByteArray\r\n\r\nsipRound :: Word64 -> Word64 -> Word64 -> Word64 -> (Word64, Word64, Word64, Word64)\r\n{-# INLINE sipRound #-}\r\nsipRound v0 v1 v2 v3 = (v3 `xor` v0, v0 `xor` v1, v1 `xor` v2, v2 `xor` v3)\r\n\r\nhashTextSip :: Word64 -> P.ByteArray -> Word64\r\n{-# INLINE hashTextSip #-}\r\nhashTextSip h = \\ ba -> \r\n let !lenWord16 = P.sizeofByteArray ba `unsafeShiftR` 1\r\n !word16sRem = lenWord16 .&. 3 \r\n !word16sIx = lenWord16-word16sRem\r\n !ixFinal = lenWord16-1\r\n !word16sIxWd = word16sIx `unsafeShiftR` 2 -- `div` 4\r\n\r\n hash4Word16sLoop hAcc@(!w0,!w1,!w2,!w3) !ix \r\n | ix == word16sIxWd = hashRemainingWord16s hAcc word16sIx\r\n | otherwise = \r\n let w64Dirty = P.indexByteArray ba ix\r\n w64 = clean4xWord16ChunkLE w64Dirty\r\n in hash4Word16sLoop (sipRound (w0 `xor` w64) w1 w2 w3) (ix + 1)\r\n \r\n -- NOTE: Removing this causes regression to disappear as well.\r\n hashRemainingWord16s (!w0,!w1,!w2,!w3) !ix \r\n | ix > ixFinal = w0 \r\n | otherwise = \r\n let w16 = P.indexByteArray ba ix\r\n in hashRemainingWord16s (sipRound (w0 `xor` (fromIntegral (w16 :: Word16))) w1 w2 w3) (ix+1)\r\n in hash4Word16sLoop (h,1,2,3) 0 \r\n\r\nclean4xWord16ChunkLE :: Word64 -> Word64\r\n{-# INLINE clean4xWord16ChunkLE #-}\r\nclean4xWord16ChunkLE w64Dirty = \r\n -- NOTE: no regression when just this (8.2 is faster)\r\n -- (((byteSwap64 w64Dirty) `unsafeShiftR` 8) .&. 0x00FF00FF00FF00FF) \r\n\r\n -- ...but this is a big regression:\r\n (((byteSwap64 w64Dirty) `unsafeShiftR` 8) .&. 0x00FF00FF00FF00FF) \r\n .|.\r\n (((byteSwap64 w64Dirty) `unsafeShiftL` 8) .&. 0xFF00FF00FF00FF00)\r\n}}}\r\n\r\nHere are the results of the benchmark above on my machine:\r\n\r\nOn GHC **8.0.1**:\r\n{{{\r\nbenchmarking ByteArray 5\r\ntime 24.70 ns (24.00 ns .. 26.25 ns)\r\n 0.987 R² (0.967 R² .. 1.000 R²)\r\nmean 24.44 ns (24.13 ns .. 25.80 ns)\r\nstd dev 1.859 ns (318.3 ps .. 4.227 ns)\r\nvariance introduced by outliers: 86% (severely inflated)\r\n\r\nbenchmarking ByteArray 8\r\ntime 32.66 ns (32.58 ns .. 32.76 ns)\r\n 1.000 R² (1.000 R² .. 1.000 R²)\r\nmean 32.79 ns (32.64 ns .. 33.09 ns)\r\nstd dev 683.7 ps (365.4 ps .. 1.175 ns)\r\nvariance introduced by outliers: 31% (moderately inflated)\r\n\r\nbenchmarking ByteArray 512\r\ntime 1.428 μs (1.382 μs .. 1.522 μs)\r\n 0.986 R² (0.970 R² .. 1.000 R²)\r\nmean 1.398 μs (1.384 μs .. 1.454 μs)\r\nstd dev 91.12 ns (4.475 ns .. 193.9 ns)\r\nvariance introduced by outliers: 76% (severely inflated)\r\n\r\nbenchmarking ByteArray 1000000\r\ntime 2.658 ms (2.653 ms .. 2.663 ms)\r\n 1.000 R² (1.000 R² .. 1.000 R²)\r\nmean 2.672 ms (2.665 ms .. 2.691 ms)\r\nstd dev 35.00 μs (10.88 μs .. 59.58 μs)\r\n\r\n}}}\r\n\r\nAnd on **GHC 8.2** RC:\r\n{{{\r\nbenchmarking ByteArray 5\r\ntime 23.78 ns (23.68 ns .. 23.88 ns)\r\n 1.000 R² (1.000 R² .. 1.000 R²)\r\nmean 23.83 ns (23.76 ns .. 23.95 ns)\r\nstd dev 298.8 ps (183.2 ps .. 482.5 ps)\r\nvariance introduced by outliers: 14% (moderately inflated)\r\n\r\nbenchmarking ByteArray 8\r\ntime 35.81 ns (35.44 ns .. 36.27 ns)\r\n 0.999 R² (0.998 R² .. 1.000 R²)\r\nmean 35.56 ns (35.45 ns .. 35.94 ns)\r\nstd dev 596.8 ps (134.5 ps .. 1.184 ns)\r\nvariance introduced by outliers: 22% (moderately inflated)\r\n\r\nbenchmarking ByteArray 512\r\ntime 1.706 μs (1.698 μs .. 1.716 μs)\r\n 1.000 R² (1.000 R² .. 1.000 R²)\r\nmean 1.701 μs (1.698 μs .. 1.707 μs)\r\nstd dev 13.27 ns (5.825 ns .. 24.41 ns)\r\n\r\nbenchmarking ByteArray 1000000\r\ntime 3.322 ms (3.284 ms .. 3.377 ms)\r\n 0.999 R² (0.998 R² .. 1.000 R²)\r\nmean 3.296 ms (3.287 ms .. 3.332 ms)\r\nstd dev 44.62 μs (20.55 μs .. 87.29 μs)\r\n\r\n}}}\r\n\r\nLooking at the core wasn't fruitful, but I think dumping the asm shows that this is a case of bad (or worse) register allocation. I've attached two screenshots showing the instructions added (in blue), when moving from the one-line `clean4xWord16ChunkLE` to the two-line version, for both 8.0 and 8.2 (there wasn't anything in the diff besides instances of this change). \r\n\r\nIt looks in the 8.2 version like we've decided we're out of registers and need to use the stack.\r\n\r\nIn my real code I'm seeing 35% regression on very long Text, as well as 21% regression on very long ByteString; the latter implementation is similarly structured to `hashTextSip`, but doesn't call `clean4xWord16ChunkLE` but does do a byteswap.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/13745Investigate compile-time regressions in regex-tdfa-1.2.22019-11-04T10:55:02ZBen GamariInvestigate compile-time regressions in regex-tdfa-1.2.2hvr [points out](https://mail.haskell.org/pipermail/ghc-devs/2017-May/014208.html) that GHC 8.2 takes significantly longer to compile `regex-tdfa-1.2.2` than 8.0.2. Interestingly, it seems that compiler allocations fell dramatically whil...hvr [points out](https://mail.haskell.org/pipermail/ghc-devs/2017-May/014208.html) that GHC 8.2 takes significantly longer to compile `regex-tdfa-1.2.2` than 8.0.2. Interestingly, it seems that compiler allocations fell dramatically while compilation time rose.
```
GHC 8.0.2:
<<ghc: 89544610040 bytes, 2301 GCs, 189183965/391103872 avg/max bytes
residency (29 samples), 1075M in use, 0.001 INIT (0.001 elapsed),
55.747 MUT (61.520 elapsed), 23.276 GC (23.278 elapsed) :ghc>>
GHC 8.2.1:
<<ghc: 115210990008 bytes, 6383 GCs, 116487828/234031864 avg/max bytes
residency (77 samples), 670M in use, 0.001 INIT (0.000 elapsed),
64.154 MUT (68.262 elapsed), 37.114 GC (37.077 elapsed) :ghc>>
```
## Reproducing
```
$ cabal unpack regex-tdfa-1.2.2
$ cd regex-tdfa-1.2.2
$ cabal install --only-dependencies
$ cabal configure
$ cabal build
$ time ghc -idist/build/autogen -O2 Text/Regex/TDFA.hs \
-XMagicHash -XFlexibleInstances -XMultiParamTypeClasses \
-XRecursiveDo -XBangPatterns -XRankNTypes -XUnboxedTuples \
-XFlexibleContexts -XUnliftedFFITypes
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Investigate compile-time regressions in regex-tdfa-1.2.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"hvr [[https://mail.haskell.org/pipermail/ghc-devs/2017-May/014208.html|points out]] that GHC 8.2 takes significantly longer to compile `regex-tdfa-1.2.2` than 8.0.2. Interestingly, it seems that compiler allocations fell dramatically while compilation time rose.\r\n\r\n{{{\r\nGHC 8.0.2:\r\n\r\n<<ghc: 89544610040 bytes, 2301 GCs, 189183965/391103872 avg/max bytes\r\nresidency (29 samples), 1075M in use, 0.001 INIT (0.001 elapsed),\r\n55.747 MUT (61.520 elapsed), 23.276 GC (23.278 elapsed) :ghc>>\r\n\r\nGHC 8.2.1:\r\n\r\n<<ghc: 115210990008 bytes, 6383 GCs, 116487828/234031864 avg/max bytes\r\nresidency (77 samples), 670M in use, 0.001 INIT (0.000 elapsed),\r\n64.154 MUT (68.262 elapsed), 37.114 GC (37.077 elapsed) :ghc>>\r\n}}}\r\n\r\n== Reproducing ==\r\n\r\n{{{\r\n$ cabal unpack regex-tdfa-1.2.2\r\n$ cd regex-tdfa-1.2.2\r\n$ cabal install --only-dependencies\r\n$ cabal configure\r\n$ cabal build\r\n$ time ghc -idist/build/autogen -O2 Text/Regex/TDFA.hs \\\r\n -XMagicHash -XFlexibleInstances -XMultiParamTypeClasses \\\r\n -XRecursiveDo -XBangPatterns -XRankNTypes -XUnboxedTuples \\\r\n -XFlexibleContexts -XUnliftedFFITypes\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.3https://gitlab.haskell.org/ghc/ghc/-/issues/13715test dynamic-paper for way profasm fails with Simplifier ticks exhausted2019-07-07T18:20:28Zgeorge.colpittstest dynamic-paper for way profasm fails with Simplifier ticks exhaustedon ghc 8.2.1-rc2 on a mac running the latest Xcode and os
{{{
make TEST=dynamic-paper WAY=profasm
fails with
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.2.0.20170507 for x86_64-apple-darwin):
Simplifier ticks exhaust...on ghc 8.2.1-rc2 on a mac running the latest Xcode and os
{{{
make TEST=dynamic-paper WAY=profasm
fails with
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.2.0.20170507 for x86_64-apple-darwin):
Simplifier ticks exhausted
When trying UnfoldingDone delta
1. ..
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable
pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad
it also fails with 1000 ticks
make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick-factor=1000'
so there may be an infinite loop
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"test dynamic-paper for way profasm fails with Simplifier ticks exhausted","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":["simplifier","ticks"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"on ghc 8.2.1-rc2 on a mac running the latest Xcode and os\r\n{{{\r\nmake TEST=dynamic-paper WAY=profasm \r\nfails with \r\nghc-stage2: panic! (the 'impossible' happened)\r\n\t (GHC version 8.2.0.20170507 for x86_64-apple-darwin):\r\n\t\tSimplifier ticks exhausted\r\n\t When trying UnfoldingDone delta\r\n...\r\nCall stack:\r\n\t CallStack (from HasCallStack):\r\n\t\tprettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable\r\n\t\tcallStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable\r\n\t\tpprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad\r\n\r\nit also fails with 1000 ticks\r\nmake TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick-factor=1000'\r\nso there may be an infinite loop","type_of_failure":"OtherFailure","blocking":[]} -->Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/13689Data.Either doesn't export INLINABLE short functions like "rights"2019-07-07T18:20:35ZvarosiData.Either doesn't export INLINABLE short functions like "rights"Currently if I use Data.Either's simple functions like "rights", "isLeft", etc. In Core/Cmm with -O2 I see that they are called like external functions and not inlined. This is because they are not marked as INLINABLE in the library itse...Currently if I use Data.Either's simple functions like "rights", "isLeft", etc. In Core/Cmm with -O2 I see that they are called like external functions and not inlined. This is because they are not marked as INLINABLE in the library itself.
It'll be great if such functions in base are marked as INLINABLE so optimizator/inliner to generate more efficient code.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.Either doesn't export INLINABLE short functions like \"rights\"","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently if I use Data.Either's simple functions like \"rights\", \"isLeft\", etc. In Core/Cmm with -O2 I see that they are called like external functions and not inlined. This is because they are not marked as INLINABLE in the library itself.\r\n\r\nIt'll be great if such functions in base are marked as INLINABLE so optimizator/inliner to generate more efficient code.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/13535vector test suite uses excessive memory on GHC 8.22023-06-02T11:06:30ZRyan Scottvector test suite uses excessive memory on GHC 8.2First noticed [here](https://github.com/haskell/vector/pull/161#issuecomment-292031845). I haven't managed to boil this down to a test case with no dependencies yet, so for the time being, this requires `vector`. To reproduce, follow the...First noticed [here](https://github.com/haskell/vector/pull/161#issuecomment-292031845). I haven't managed to boil this down to a test case with no dependencies yet, so for the time being, this requires `vector`. To reproduce, follow these steps:
```
$ git clone https://github.com/erikd/vector
$ cd vector/
$ cabal install --only-dependencies --enable-tests -w /opt/ghc/8.2.1/bin/ghc
$ cabal configure --enable-tests -w /opt/ghc/8.2.1/bin/ghc
$ cabal test
```
When building `vector-tests-O2`, GHC will stall when compiling the `Tests.Vector` module. On machines with modest memory allowances (e.g., [the machines used on Travis CI](https://travis-ci.org/haskell/vector/jobs/218749281#L1270)), GHC will be killed with an out-of-memory error after trying to compile `Tests.Vector` for a while.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"vector test suite uses excessive memory on GHC 8.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First noticed [https://github.com/haskell/vector/pull/161#issuecomment-292031845 here]. I haven't managed to boil this down to a test case with no dependencies yet, so for the time being, this requires `vector`. To reproduce, follow these steps:\r\n\r\n{{{\r\n$ git clone https://github.com/erikd/vector\r\n$ cd vector/\r\n$ cabal install --only-dependencies --enable-tests -w /opt/ghc/8.2.1/bin/ghc\r\n$ cabal configure --enable-tests -w /opt/ghc/8.2.1/bin/ghc\r\n$ cabal test\r\n}}}\r\n\r\nWhen building `vector-tests-O2`, GHC will stall when compiling the `Tests.Vector` module. On machines with modest memory allowances (e.g., [https://travis-ci.org/haskell/vector/jobs/218749281#L1270 the machines used on Travis CI]), GHC will be killed with an out-of-memory error after trying to compile `Tests.Vector` for a while.","type_of_failure":"OtherFailure","blocking":[]} -->⊥Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/13149Giving Backpack a Promotion2019-11-27T16:57:26ZEdward Z. YangGiving Backpack a PromotionThis ticket is tracking assumptions the current implementation of Backpack makes about terms and types, which may be violated when more and more term-level things start being lifted into the type level. I don't expect any work to be done...This ticket is tracking assumptions the current implementation of Backpack makes about terms and types, which may be violated when more and more term-level things start being lifted into the type level. I don't expect any work to be done on this in the near future, but I'd like to keep track of these breadcrumbs.
- We currently assume that it is impossible for a typechecked-only module (that is, one with no Core unfoldings) to refer to a DFun or a coercion axiom. In the absence of promotion, I'm pretty sure this is the case, since there is no way to refer to a term from a type (DFun), and coercions do not ordinarily occur at the type level.
With promotion, this is not true:
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE Rank2Types #-}
{-# LANGUAGE TypeInType #-}
unit p where
signature A where
import GHC.Types
type family F a where
F Bool = Type
module B where
import A
foo :: forall (a :: F Bool). a -> a
foo x = x
unit q where
dependency p[A=<A>]
module C where
import B
```
> This will fail in a puzzling way:
```
<no location info>: error:
The identifier D:R:F does not exist in the signature for <A>
(Try adding it to the export list in that hsig file.)
```
- (Put more problems here)Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/12486Investigate removing libGCC symbols from RtsSymbols.c2022-08-11T18:39:43ZTamar ChristinaInvestigate removing libGCC symbols from RtsSymbols.cThe RTS is currently re-exporting symbols from the C compiler runtime in `RtsSymbols.c`.
How this works is that the Runtime linker is declaring that it can provide these symbols because it's been linked against the C compiler library it...The RTS is currently re-exporting symbols from the C compiler runtime in `RtsSymbols.c`.
How this works is that the Runtime linker is declaring that it can provide these symbols because it's been linked against the C compiler library itself. In essence it's providing pointers to it's own symbol table.
This Is fine but has two downsides:
1) We have to keep adding symbols to export anytime the underlying C compiler changes things or someone needs a new symbol from the library.
2) User code that is linking explicitly against these libraries will probably generate a duplicate symbols error if it needs a symbol we have not yet exported but is in the same object file or dependency of a symbol we have exported.
One solution would be to add `libgcc_s` to the dependencies of `ghc-prim` which is the package that seems to require them.
This has two issues with it: `GCC_S` doesn't exist for llvm, so we need to somehow know which compiler we're compiling for.
Secondly on Windows `GCC_S` is an import library with a non-standard name. (.a instead of .dll.a) and we currently cannot recognize it as such. We'd try to load it as a normal archive and end up trying to execute ascii as code.
This task is to find a way to remove the need to export these symbols yet still work with both GCC and LLVM.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Investigate removing libGCC symbols from RtsSymbols.c","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"The RTS is currently re-exporting symbols from the C compiler runtime in `RtsSymbols.c`.\r\n\r\nHow this works is that the Runtime linker is declaring that it can provide these symbols because it's been linked against the C compiler library itself. In essence it's providing pointers to it's own symbol table.\r\n\r\nThis Is fine but has two downsides:\r\n\r\n1) We have to keep adding symbols to export anytime the underlying C compiler changes things or someone needs a new symbol from the library.\r\n\r\n2) User code that is linking explicitly against these libraries will probably generate a duplicate symbols error if it needs a symbol we have not yet exported but is in the same object file or dependency of a symbol we have exported.\r\n\r\nOne solution would be to add `libgcc_s` to the dependencies of `ghc-prim` which is the package that seems to require them.\r\n\r\nThis has two issues with it: `GCC_S` doesn't exist for llvm, so we need to somehow know which compiler we're compiling for. \r\n\r\nSecondly on Windows `GCC_S` is an import library with a non-standard name. (.a instead of .dll.a) and we currently cannot recognize it as such. We'd try to load it as a normal archive and end up trying to execute ascii as code.\r\n\r\nThis task is to find a way to remove the need to export these symbols yet still work with both GCC and LLVM.","type_of_failure":"OtherFailure","blocking":[]} -->⊥