GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-02-16T22:04:52Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/11983Can't use IntPtr or WordPtr in a foreign import2024-02-16T22:04:52ZRyan ScottCan't use IntPtr or WordPtr in a foreign importDespite the [docs claiming](http://hackage.haskell.org/package/base-4.8.2.0/docs/Foreign-Ptr.html#t:IntPtr) that you can use `IntPtr` and `WordPtr` to convert to and from `intptr_t` and `uintptr_t`, you can't actually do so in a `foreign...Despite the [docs claiming](http://hackage.haskell.org/package/base-4.8.2.0/docs/Foreign-Ptr.html#t:IntPtr) that you can use `IntPtr` and `WordPtr` to convert to and from `intptr_t` and `uintptr_t`, you can't actually do so in a `foreign import` as of GHC 7.6. Here's a minimal example:
```hs
-- Example.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module Example where
{-# INCLUDE example.h #-}
import Foreign.Ptr
foreign import ccall "intptr_example"
intPtrExample :: IntPtr -> IO ()
foreign import ccall "uintptr_example"
wordPtrExample :: WordPtr -> IO ()
```
```c
// example.h
#ifndef EXAMPLE_H
#define EXAMPLE_H
#include <stdint.h>
void intptr_example(intptr_t);
void uintptr_example(uintptr_t);
#endif // EXAMPLE_H
```
```c
// example.c
#include <stdint.h>
#include "example.h"
void intptr_example(intptr_t i) {}
void uintptr_example(uintptr_t u) {}
```
This appears to be a consequence of #3008, which prevents `newtype`s from being used as FFI types unless their constructors are exported. #5529 fixed this problem for the datatypes in `Foreign.C.Types` and `System.Posix.Types` by simply exporting their constructors, so I think all that's needed to fix this particular example is to export the constructors for `IntPtr` and `WordPtr`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't use IntPtr or WordPtr in a foreign import","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"RyanGlScott"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Despite the [http://hackage.haskell.org/package/base-4.8.2.0/docs/Foreign-Ptr.html#t:IntPtr docs claiming] that you can use `IntPtr` and `WordPtr` to convert to and from `intptr_t` and `uintptr_t`, you can't actually do so in a `foreign import` as of GHC 7.6. Here's a minimal example:\r\n\r\n{{{#!hs\r\n-- Example.hs\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\nmodule Example where\r\n\r\n{-# INCLUDE example.h #-}\r\n\r\nimport Foreign.Ptr\r\n\r\nforeign import ccall \"intptr_example\"\r\n intPtrExample :: IntPtr -> IO ()\r\nforeign import ccall \"uintptr_example\"\r\n wordPtrExample :: WordPtr -> IO ()\r\n}}}\r\n\r\n{{{#!c\r\n// example.h\r\n#ifndef EXAMPLE_H\r\n#define EXAMPLE_H\r\n\r\n#include <stdint.h>\r\n\r\nvoid intptr_example(intptr_t);\r\nvoid uintptr_example(uintptr_t);\r\n\r\n#endif // EXAMPLE_H\r\n}}}\r\n\r\n{{{#!c\r\n// example.c\r\n#include <stdint.h>\r\n#include \"example.h\"\r\n\r\nvoid intptr_example(intptr_t i) {}\r\nvoid uintptr_example(uintptr_t u) {}\r\n}}}\r\n\r\nThis appears to be a consequence of #3008, which prevents `newtype`s from being used as FFI types unless their constructors are exported. #5529 fixed this problem for the datatypes in `Foreign.C.Types` and `System.Posix.Types` by simply exporting their constructors, so I think all that's needed to fix this particular example is to export the constructors for `IntPtr` and `WordPtr`.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/13218<$ is bad in derived functor instances2023-10-02T09:12:24ZDavid Feuer<$ is bad in derived functor instances`Functor` deriving derives the definition of `fmap`, leaving the definition of `<$` to the default. This is quite bad for recursive types:
```hs
data Tree a = Bin !(Tree a) a !(Tree a) | Tip deriving Functor
```
produces
```
Replace.$...`Functor` deriving derives the definition of `fmap`, leaving the definition of `<$` to the default. This is quite bad for recursive types:
```hs
data Tree a = Bin !(Tree a) a !(Tree a) | Tip deriving Functor
```
produces
```
Replace.$fFunctorTree_$c<$ =
\ (@ a_aGl) (@ b_aGm) (eta_aGn :: a_aGl) (eta1_B1 :: Tree b_aGm) ->
Replace.$fFunctorTree_$cfmap
@ b_aGm @ a_aGl (\ _ [Occ=Dead] -> eta_aGn) eta1_B1
```
Why is this bad? It fills the tree with thunks keeping the original values (which we never use again) alive. What we want to generate is
```hs
x <$ Bin l _ r = Bin (x <$ l) x (x <$ r)
```
When there are other functor types in the constructor, like
```hs
| Whatever (Tree (Tree a))
```
we will need to insert `fmap (x <$) t`. The overall shape should be basically the same as `fmap` deriving.
Note: there are some types for which we will not realistically be able to derive optimal definitions. In particular, fixed-shape, undecorated types that appear in nested types allow special treatment:
```hs
data Pair a = Pair a a deriving Functor
data Tree2 a = Z a | S (Tree2 (Pair a)) deriving Functor
```
The ideal definition for this type is
```hs
x <$ Z _ = Z x
x <$ S t = S (Pair x x <$ t)
```
but that requires cleverness. We should probably settle for
```hs
x <$ Z _ = Z x
x <$ S t = S (fmap (x <$) t)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"<$ is bad in derived functor instances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dfeuer"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`Functor` deriving derives the definition of `fmap`, leaving the definition of `<$` to the default. This is quite bad for recursive types:\r\n\r\n{{{#!hs\r\ndata Tree a = Bin !(Tree a) a !(Tree a) | Tip deriving Functor\r\n}}}\r\n\r\nproduces\r\n\r\n{{{\r\nReplace.$fFunctorTree_$c<$ =\r\n \\ (@ a_aGl) (@ b_aGm) (eta_aGn :: a_aGl) (eta1_B1 :: Tree b_aGm) ->\r\n Replace.$fFunctorTree_$cfmap\r\n @ b_aGm @ a_aGl (\\ _ [Occ=Dead] -> eta_aGn) eta1_B1\r\n}}}\r\n\r\nWhy is this bad? It fills the tree with thunks keeping the original values (which we never use again) alive. What we want to generate is\r\n\r\n{{{#!hs\r\nx <$ Bin l _ r = Bin (x <$ l) x (x <$ r)\r\n}}}\r\n\r\nWhen there are other functor types in the constructor, like\r\n\r\n{{{#!hs\r\n | Whatever (Tree (Tree a))\r\n}}}\r\n\r\nwe will need to insert `fmap (x <$) t`. The overall shape should be basically the same as `fmap` deriving.\r\n\r\nNote: there are some types for which we will not realistically be able to derive optimal definitions. In particular, fixed-shape, undecorated types that appear in nested types allow special treatment:\r\n\r\n{{{#!hs\r\ndata Pair a = Pair a a deriving Functor\r\ndata Tree2 a = Z a | S (Tree2 (Pair a)) deriving Functor\r\n}}}\r\n\r\nThe ideal definition for this type is\r\n\r\n{{{#!hs\r\n x <$ Z _ = Z x\r\n x <$ S t = S (Pair x x <$ t)\r\n}}}\r\n\r\nbut that requires cleverness. We should probably settle for\r\n\r\n{{{#!hs\r\n x <$ Z _ = Z x\r\n x <$ S t = S (fmap (x <$) t)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/13413GHC HEAD panic: collectNBinders2023-09-01T12:15:47ZRyan ScottGHC HEAD panic: collectNBinders`repa-eval-4.2.3.1` currently fails to build on GHC HEAD because of this issue. Trying to build it leads to several `collectNBinders` panics is various modules. You can reproduce this by compiling this module:
```hs
{-# LANGUAGE BangPat...`repa-eval-4.2.3.1` currently fails to build on GHC HEAD because of this issue. Trying to build it leads to several `collectNBinders` panics is various modules. You can reproduce this by compiling this module:
```hs
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE MagicHash #-}
module Data.Repa.Eval.Generic.Seq.Chunked where
import GHC.Exts (Int#, (+#), (*#), (>=#))
-------------------------------------------------------------------------------
-- | Fill a block in a rank-2 array, sequentially.
--
-- * Blockwise filling can be more cache-efficient than linear filling for
-- rank-2 arrays.
--
-- * The block is filled in row major order from top to bottom.
--
fillBlock2
:: (Int# -> a -> IO ()) -- ^ Update function to write into result buffer.
-> (Int# -> Int# -> a) -- ^ Function to get the value at an (x, y) index.
-> Int# -- ^ Width of the whole array.
-> Int# -- ^ x0 lower left corner of block to fill.
-> Int# -- ^ y0
-> Int# -- ^ w0 width of block to fill
-> Int# -- ^ h0 height of block to fill
-> IO ()
fillBlock2
write getElem
!imageWidth !x0 !y0 !w0 h0
= do fillBlock y0 ix0
where !x1 = x0 +# w0
!y1 = y0 +# h0
!ix0 = x0 +# (y0 *# imageWidth)
{-# INLINE fillBlock #-}
fillBlock !y !ix
| 1# <- y >=# y1 = return ()
| otherwise
= do fillLine1 x0 ix
fillBlock (y +# 1#) (ix +# imageWidth)
where {-# INLINE fillLine1 #-}
fillLine1 !x !ix'
| 1# <- x >=# x1 = return ()
| otherwise
= do write ix' (getElem x y)
fillLine1 (x +# 1#) (ix' +# 1#)
{-# INLINE [0] fillBlock2 #-}
```
This compiles on GHC 8.0.2, but on GHC HEAD:
```
$ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs
[1 of 1] Compiling Data.Repa.Eval.Generic.Seq.Chunked ( Bug.hs, Bug.o )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20170201 for x86_64-unknown-linux):
collectNBinders
2
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1179:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1183:37 in ghc:Outputable
pprPanic, called at compiler/coreSyn/CoreSyn.hs:1970:25 in ghc:CoreSyn
```
Interestingly, compiling this triggers the panic at any optimization level, but loading the module into GHCi does not cause it to panic.
This regression was introduced in 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 (Join points).
<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":"GHC HEAD panic: collectNBinders","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":["JoinPoints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`repa-eval-4.2.3.1` currently fails to build on GHC HEAD because of this issue. Trying to build it leads to several `collectNBinders` panics is various modules. You can reproduce this by compiling this module:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE BangPatterns #-}\r\n{-# LANGUAGE MagicHash #-}\r\nmodule Data.Repa.Eval.Generic.Seq.Chunked where\r\n\r\nimport GHC.Exts (Int#, (+#), (*#), (>=#))\r\n\r\n-------------------------------------------------------------------------------\r\n-- | Fill a block in a rank-2 array, sequentially.\r\n--\r\n-- * Blockwise filling can be more cache-efficient than linear filling for\r\n-- rank-2 arrays.\r\n--\r\n-- * The block is filled in row major order from top to bottom.\r\n--\r\nfillBlock2\r\n :: (Int# -> a -> IO ()) -- ^ Update function to write into result buffer.\r\n -> (Int# -> Int# -> a) -- ^ Function to get the value at an (x, y) index.\r\n -> Int# -- ^ Width of the whole array.\r\n -> Int# -- ^ x0 lower left corner of block to fill.\r\n -> Int# -- ^ y0\r\n -> Int# -- ^ w0 width of block to fill\r\n -> Int# -- ^ h0 height of block to fill\r\n -> IO ()\r\n\r\nfillBlock2\r\n write getElem\r\n !imageWidth !x0 !y0 !w0 h0\r\n\r\n = do fillBlock y0 ix0\r\n where !x1 = x0 +# w0\r\n !y1 = y0 +# h0\r\n !ix0 = x0 +# (y0 *# imageWidth)\r\n\r\n {-# INLINE fillBlock #-}\r\n fillBlock !y !ix\r\n | 1# <- y >=# y1 = return ()\r\n | otherwise\r\n = do fillLine1 x0 ix\r\n fillBlock (y +# 1#) (ix +# imageWidth)\r\n\r\n where {-# INLINE fillLine1 #-}\r\n fillLine1 !x !ix'\r\n | 1# <- x >=# x1 = return ()\r\n | otherwise\r\n = do write ix' (getElem x y)\r\n fillLine1 (x +# 1#) (ix' +# 1#)\r\n\r\n{-# INLINE [0] fillBlock2 #-}\r\n}}}\r\n\r\nThis compiles on GHC 8.0.2, but on GHC HEAD:\r\n\r\n{{{\r\n$ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs\r\n[1 of 1] Compiling Data.Repa.Eval.Generic.Seq.Chunked ( Bug.hs, Bug.o )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20170201 for x86_64-unknown-linux):\r\n collectNBinders\r\n 2\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1179:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1183:37 in ghc:Outputable\r\n pprPanic, called at compiler/coreSyn/CoreSyn.hs:1970:25 in ghc:CoreSyn\r\n}}}\r\n\r\nInterestingly, compiling this triggers the panic at any optimization level, but loading the module into GHCi does not cause it to panic.\r\n\r\nThis regression was introduced in 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 (Join points).","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/12637ghc-pkg: Allow unregistering multiple packages in one call2023-08-24T23:43:09ZNiklas Hambüchenmail@nh2.meghc-pkg: Allow unregistering multiple packages in one callThis can save lots of time when the cost to invoke a single GHC command is high, for example through docker.
An example user of this would be `stack build`, which will unregister all relevant packages if e.g. `--extra-lib-dirs` has chan...This can save lots of time when the cost to invoke a single GHC command is high, for example through docker.
An example user of this would be `stack build`, which will unregister all relevant packages if e.g. `--extra-lib-dirs` has changed. Currently it has to do that through multiple `ghc-pkg unregister` operations, which can take about 2 seconds per call when done through a docker image. If we could unregister multiple packages at once, such use cases would have to pay the 2 seconds penalty only once.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg: Allow unregistering multiple packages in one call","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"FeatureRequest","description":"This can save lots of time when the cost to invoke a single GHC command is high, for example through docker.\r\n\r\nAn example user of this would be `stack build`, which will unregister all relevant packages if e.g. `--extra-lib-dirs` has changed. Currently it has to do that through multiple `ghc-pkg unregister` operations, which can take about 2 seconds per call when done through a docker image. If we could unregister multiple packages at once, such use cases would have to pay the 2 seconds penalty only once.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/10010LLVM/optimized code for sqrt incorrect for negative values2023-08-23T11:41:57ZglguyLLVM/optimized code for sqrt incorrect for negative valuesThe LLVM sqrt intrinsic is undefined below values of -0.0
See http://llvm.org/docs/LangRef.html\#llvm-sqrt-intrinsic
In some versions of LLVM it returns 0.0 in this case, but in newer versions the return value is undefined.
This cause...The LLVM sqrt intrinsic is undefined below values of -0.0
See http://llvm.org/docs/LangRef.html\#llvm-sqrt-intrinsic
In some versions of LLVM it returns 0.0 in this case, but in newer versions the return value is undefined.
This causes the result of Haskell's sqrt to vary at negative values based on the codegen and optimization flags chosen.
```
main = print (sqrt (-7 :: Double))
```
```
$ ghc -O -fllvm Sqrt.hs
[1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o )
Linking Sqrt ...
$ ./Sqrt
0.0
$ ghc -O Sqrt.hs
[1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o )
Linking Sqrt ...
$ ./Sqrt
NaN
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LLVM/optimized code for sqrt incorrect for negative values","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The LLVM sqrt intrinsic is undefined below values of -0.0\r\n\r\nSee http://llvm.org/docs/LangRef.html#llvm-sqrt-intrinsic\r\n\r\nIn some versions of LLVM it returns 0.0 in this case, but in newer versions the return value is undefined.\r\n\r\nThis causes the result of Haskell's sqrt to vary at negative values based on the codegen and optimization flags chosen.\r\n\r\n{{{\r\nmain = print (sqrt (-7 :: Double))\r\n}}}\r\n\r\n{{{\r\n$ ghc -O -fllvm Sqrt.hs\r\n[1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o )\r\nLinking Sqrt ...\r\n$ ./Sqrt \r\n0.0\r\n$ ghc -O Sqrt.hs\r\n[1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o )\r\nLinking Sqrt ...\r\n$ ./Sqrt \r\nNaN\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13267Constraint synonym instances2023-06-15T18:41:07ZEdward Z. YangConstraint synonym instancesSomething funny happens when you try to declare an instance of a constraint synonym:
```
{-# LANGUAGE ConstraintKinds #-}
module F where
type ShowF a = Show (a -> Bool)
instance ShowF Int where
show _ = "Fun"
```
I get:
```
F.hs...Something funny happens when you try to declare an instance of a constraint synonym:
```
{-# LANGUAGE ConstraintKinds #-}
module F where
type ShowF a = Show (a -> Bool)
instance ShowF Int where
show _ = "Fun"
```
I get:
```
F.hs:8:5: error: ‘show’ is not a (visible) method of class ‘ShowF’
|
8 | show _ = "Fun"
| ^^^^
```
OK, but it gets weirder. Look at:
```
{-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances #-}
module F where
type ShowF a = (Show (a -> Bool))
instance ShowF Int where
```
This is accepted (with a complaint that `show` is not implemented.) It gets even more awful:
```
{-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances, MultiParamTypeClasses #-}
module F where
type ShowF a = (Show Bool, Show Int)
instance ShowF Int where
```
This is awful: GHC treats `Show Bool` and `Show Int` as if they were constraints, and then emits the following DFun:
```
df9d1b4635f2a752f29ff327ab66d1cb
$f(%,%)ShowShow :: (Show Bool, Show Int)
DFunId
{- Strictness: m, Inline: CONLIKE,
Unfolding: DFun: @ a @ b.
@ (Show Bool) @ (Show Int) $fShowBool $fShowInt -}
```
I don't even know what this is supposed to mean.
OK, so what should we do? I think there are a few possibilities:
1. Completely outlaw instance declarations on constraint synonyms.
1. Allow instance declarations on constraint synonyms, but only if after desugaring the synonym, you end up with a single class head. I would find this useful in a few cases, for example, if you are writing `instance MonadSample (Impl t) MyMonad`, if you had `type MonadSample2 t a = MonadSample (Impl t) a` you might prefer writing `instance MonadSample2 t MyMonad` instead
1. Figure out what to do with instance declarations with multiple class heads, and proceed accordingly.8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/11046lookupTypeName does not support type operators not starting with :2023-06-14T22:51:53Zoerjan@nvg.ntnu.nolookupTypeName does not support type operators not starting with :The following non-working code (minus a missing import) was [posted on stackoverflow](http://stackoverflow.com/questions/33465109/template-haskell-how-to-lookup-type-operator-name):
`IssueTH.hs`:
```hs
{-# LANGUAGE TemplateHaskell #-}
...The following non-working code (minus a missing import) was [posted on stackoverflow](http://stackoverflow.com/questions/33465109/template-haskell-how-to-lookup-type-operator-name):
`IssueTH.hs`:
```hs
{-# LANGUAGE TemplateHaskell #-}
module IssueTH where
import Language.Haskell.TH
f :: Q [Dec]
f = do
Just n <- lookupTypeName "GHC.TypeLits.*"
return []
```
`Issue.hs`:
```hs
{-# LANGUAGE TemplateHaskell #-}
module Issue where
import IssueTH
import GHC.TypeLits
$f
```
`ghc Issue.hs` fails with message:
`Pattern match failure in do expression at IssueTH.hs:7:5-10`
This gives no error if `*` is replaced by an alphanumeric type like `Nat`. Similar tests seem to fail whenever attempting to look up a type operator with `lookupTypeName`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | oerjan |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"lookupTypeName does not support type operators","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["oerjan"],"type":"Bug","description":"The following non-working code (minus a missing import) was [http://stackoverflow.com/questions/33465109/template-haskell-how-to-lookup-type-operator-name posted on stackoverflow]:\r\n\r\n`IssueTH.hs`:\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule IssueTH where\r\nimport Language.Haskell.TH\r\n\r\nf :: Q [Dec]\r\nf = do\r\n Just n <- lookupTypeName \"GHC.TypeLits.*\"\r\n return []\r\n}}}\r\n\r\n`Issue.hs`:\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Issue where\r\nimport IssueTH\r\nimport GHC.TypeLits\r\n\r\n$f\r\n}}}\r\n\r\n`ghc Issue.hs` fails with message:\r\n`Pattern match failure in do expression at IssueTH.hs:7:5-10`\r\n\r\nThis gives no error if `*` is replaced by an alphanumeric type like `Nat`. Similar tests seem to fail whenever attempting to look up a type operator with `lookupTypeName`.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1albertusalbertushttps://gitlab.haskell.org/ghc/ghc/-/issues/9007fails to build with hardening flags enabled (relocation R_X86_64_32 against `...2023-05-08T13:54:34ZJoachim Breitnermail@joachim-breitner.defails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...)Building HEAD on Debian wheezy with the Debian packaging setup fails:
```
configure: Building in-tree ghc-pwd
/usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making...Building HEAD on Debian wheezy with the Debian packaging setup fails:
```
configure: Building in-tree ghc-pwd
/usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC
utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
configure: error: Building ghc-pwd failed
```
http://deb.haskell.org/dailies/2014-04-16/ghc_7.9.20140416-0.daily_amd64.build
This is possibly related to the Hardening flags added by Debian:
```
~ $ dpkg-buildflags --get LDFLAGS
-Wl,-z,relro
~ $ dpkg-buildflags --get CFLAGS
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
```
Other related bug might be #3668 and https://bugs.debian.org/712228
I’ll disable the hardening flags and see if it helps. The error first occurred 2014-03-27.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| 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":"relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Building HEAD on Debian wheezy with the Debian packaging setup fails:\r\n{{{\r\nconfigure: Building in-tree ghc-pwd\r\n/usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC\r\nutils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value\r\ncollect2: error: ld returned 1 exit status\r\nconfigure: error: Building ghc-pwd failed\r\n}}}\r\nhttp://deb.haskell.org/dailies/2014-04-16/ghc_7.9.20140416-0.daily_amd64.build\r\n\r\nThis is possibly related to the Hardening flags added by Debian:\r\n{{{\r\n~ $ dpkg-buildflags --get LDFLAGS\r\n-Wl,-z,relro\r\n~ $ dpkg-buildflags --get CFLAGS\r\n-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security\r\n}}}\r\n\r\nOther related bug might be #3668 and https://bugs.debian.org/712228\r\n\r\nI’ll disable the hardening flags and see if it helps. The error first occurred 2014-03-27.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Joachim Breitnermail@joachim-breitner.deJoachim Breitnermail@joachim-breitner.dehttps://gitlab.haskell.org/ghc/ghc/-/issues/12846On Windows, runtime linker can't find function defined in GHC's RTS2023-02-12T00:00:41ZRyan ScottOn Windows, runtime linker can't find function defined in GHC's RTSThis is an annoyance I discovered when working with the [atomic-primops](https://github.com/rrnewton/haskell-lockfree/tree/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic-primops) package on Windows. Here is a simplified test case:
```h...This is an annoyance I discovered when working with the [atomic-primops](https://github.com/rrnewton/haskell-lockfree/tree/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic-primops) package on Windows. Here is a simplified test case:
```hs
module Main (main) where
foreign import ccall unsafe "store_load_barrier"
storeLoadBarrier :: IO ()
main :: IO ()
main = do
putStrLn "1"
storeLoadBarrier
putStrLn "2"
```
Compiling and running this program works without issue. But when run as GHCi bytecode, it fails. I've reproduced this with GHC 8.0.1 and HEAD (but based on [this](https://github.com/rrnewton/haskell-lockfree/pull/38), the issue is likely much older than 8.0.1).
```
$ runghc Bug.hs
Bug.hs:
ByteCodeLink: can't find label
During interactive linking, GHCi couldn't find the following symbol:
store_load_barrier
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
```
To work around this issue, `atomic-primops` currently links against [a separate C file](https://github.com/rrnewton/haskell-lockfree/blob/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic-primops/cbits/RtsDup.c#L52-L69) that contains an exact duplicate of the `store_load_barrier` function from GHC's RTS when build on Windows.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx- |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"On Windows, runtime linker can't find function defined in GHC's RTS","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":["Phyx-"],"type":"Bug","description":"This is an annoyance I discovered when working with the [https://github.com/rrnewton/haskell-lockfree/tree/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic-primops atomic-primops] package on Windows. Here is a simplified test case:\r\n\r\n{{{#!hs\r\nmodule Main (main) where\r\n\r\nforeign import ccall unsafe \"store_load_barrier\"\r\n storeLoadBarrier :: IO ()\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn \"1\"\r\n storeLoadBarrier\r\n putStrLn \"2\"\r\n}}}\r\n\r\nCompiling and running this program works without issue. But when run as GHCi bytecode, it fails. I've reproduced this with GHC 8.0.1 and HEAD (but based on [https://github.com/rrnewton/haskell-lockfree/pull/38 this], the issue is likely much older than 8.0.1).\r\n\r\n{{{\r\n$ runghc Bug.hs\r\nBug.hs:\r\nByteCodeLink: can't find label\r\nDuring interactive linking, GHCi couldn't find the following symbol:\r\n store_load_barrier\r\nThis may be due to you not asking GHCi to load extra object files,\r\narchives or DLLs needed by your current session. Restart GHCi, specifying\r\nthe missing library using the -L/path/to/object/dir and -lmissinglibname\r\nflags, or simply by naming the relevant files on the GHCi command line.\r\nAlternatively, this link failure might indicate a bug in GHCi.\r\nIf you suspect the latter, please send a bug report to:\r\n glasgow-haskell-bugs@haskell.org\r\n}}}\r\n\r\nTo work around this issue, `atomic-primops` currently links against [https://github.com/rrnewton/haskell-lockfree/blob/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic-primops/cbits/RtsDup.c#L52-L69 a separate C file] that contains an exact duplicate of the `store_load_barrier` function from GHC's RTS when build on Windows.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/11578Fix GHC on AArch64/Arm642022-12-24T18:57:39ZerikdFix GHC on AArch64/Arm64Raising this to track discussion about GHC on Arm64. There is already some discussion in ticket #11206 (ARM is generally a disaster), but that ticket is about 32 bit Arm which is vastly different and is now mostly fixed.
Information wort...Raising this to track discussion about GHC on Arm64. There is already some discussion in ticket #11206 (ARM is generally a disaster), but that ticket is about 32 bit Arm which is vastly different and is now mostly fixed.
Information worth saving from #11206:
- GHC 7.8.4 from Debian can build the ghc-8.0 branch, but cannot build HEAD because HEAD requires ghc-7.10 to build.
- GHC 7.10 from Debian is broken because of an unfixed bug in llvm-3.5.2.
- \~\~User \@mfox reports that ghc-7.10 does build against llvm-3.7 and results in a compiler that can build HEAD.\~\~
- \~\~That GHC 7.10 can be build against llvm-3.7 is a happy accident. Versions of GHC are usually locked to a specific version of LLVM.\~\~8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/10383AArch64: get GHC Calling convention working2022-12-21T21:51:45ZerikdAArch64: get GHC Calling convention workingBuilding on AArch64 via the LLVM abckend has been working for some time. Its now time to get `("Unregisterised", "NO")` working as well.
Enabling GHC calling convention can be done with this patch to `configure.ac`:
```
diff --git a/co...Building on AArch64 via the LLVM abckend has been working for some time. Its now time to get `("Unregisterised", "NO")` working as well.
Enabling GHC calling convention can be done with this patch to `configure.ac`:
```
diff --git a/configure.ac b/configure.ac
index d5d9ab3..a11e5af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -241,7 +241,7 @@ AC_SUBST(SOLARIS_BROKEN_SHLD)
dnl ** Do an unregisterised build?
dnl --------------------------------------------------------------
case "$HostArch" in
- i386|x86_64|powerpc|arm)
+ i386|x86_64|powerpc|arm|aarch64)
UnregisterisedDefault=NO
;;
*)
```
but when building it this way, the stage2 compiler dies will `Illegal instructon`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| 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":"AArch64: get GHC Calling convention working","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"erikd"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Building on AArch64 via the LLVM abckend has been working for some time. Its now time to get `(\"Unregisterised\", \"NO\")` working as well.\r\n\r\nEnabling GHC calling convention can be done with this patch to `configure.ac`:\r\n\r\n{{{\r\ndiff --git a/configure.ac b/configure.ac\r\nindex d5d9ab3..a11e5af 100644\r\n--- a/configure.ac\r\n+++ b/configure.ac\r\n@@ -241,7 +241,7 @@ AC_SUBST(SOLARIS_BROKEN_SHLD)\r\n dnl ** Do an unregisterised build?\r\n dnl --------------------------------------------------------------\r\n case \"$HostArch\" in\r\n- i386|x86_64|powerpc|arm)\r\n+ i386|x86_64|powerpc|arm|aarch64)\r\n UnregisterisedDefault=NO\r\n ;;\r\n *)\r\n}}}\r\n\r\nbut when building it this way, the stage2 compiler dies will `Illegal instructon`.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1erikderikdhttps://gitlab.haskell.org/ghc/ghc/-/issues/10830maximumBy has a space leak2022-12-19T18:34:42ZNeil MitchellmaximumBy has a space leakGiven the program:
```hs
import Data.List
main = print $ maximumBy compare [1..10000]
```
Compiling with `-O2`, on GHC 7.8.3 this runs in constant stack space (works fine with `+RTS -K1K`). With GHC 7.10.2 I get:
```
$ ghc --make Test...Given the program:
```hs
import Data.List
main = print $ maximumBy compare [1..10000]
```
Compiling with `-O2`, on GHC 7.8.3 this runs in constant stack space (works fine with `+RTS -K1K`). With GHC 7.10.2 I get:
```
$ ghc --make Test.hs -O2 -rtsopts
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test.exe ...
$ Test +RTS -K100K
Stack space overflow: current size 33680 bytes.
Use `+RTS -Ksize -RTS' to increase it.
```
Not sure why it's failing at 33K instead of 100K, but it's certainly taking more than 1K as GHC 7.8.3 did.
See #3416 for previous discussion of this issue. My guess is that in older versions of GHC the strictness analysis managed to kick in and optimise things. With the burnt bridges that no longer works.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"maximumBy has a space leak","status":"New","operating_system":"Windows","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Given the program:\r\n\r\n{{{#!hs\r\nimport Data.List\r\nmain = print $ maximumBy compare [1..10000]\r\n}}}\r\n\r\nCompiling with {{{-O2}}}, on GHC 7.8.3 this runs in constant stack space (works fine with {{{+RTS -K1K}}}). With GHC 7.10.2 I get:\r\n\r\n{{{\r\n$ ghc --make Test.hs -O2 -rtsopts\r\n[1 of 1] Compiling Main ( Test.hs, Test.o )\r\nLinking Test.exe ...\r\n\r\n$ Test +RTS -K100K\r\nStack space overflow: current size 33680 bytes.\r\nUse `+RTS -Ksize -RTS' to increase it.\r\n}}}\r\n\r\nNot sure why it's failing at 33K instead of 100K, but it's certainly taking more than 1K as GHC 7.8.3 did.\r\n\r\nSee #3416 for previous discussion of this issue. My guess is that in older versions of GHC the strictness analysis managed to kick in and optimise things. With the burnt bridges that no longer works.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13894isByteArrayPinned# should consider BF_LARGE2022-11-18T13:57:09ZwinterisByteArrayPinned# should consider BF_LARGEFirst of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray\#/MutableByteArray\#' is movable during safe FFI call, isn't it?
If that is the case, then the code for `stg_isByteArrayPinnedzh` ...First of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray\#/MutableByteArray\#' is movable during safe FFI call, isn't it?
If that is the case, then the code for `stg_isByteArrayPinnedzh` is not enough, since not only bytes marked with `BF_PINNED` flag is not movable, but also the bytes which is marked with `BF_LARGE`. (I read the gc code and i'm confident this holds, but if it's not, please correct me).
Currently i'm using a FFI trick[https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c\#L33](https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c#L33) to get `isByteArrayPinned#` on older GHCs, i want to make sure if `BF_LARGE` works.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"isByteArrayPinned# should consider BF_LARGE","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray#/MutableByteArray#' is movable during safe FFI call, isn't it?\r\n\r\nIf that is the case, then the code for `stg_isByteArrayPinnedzh` is not enough, since not only bytes marked with `BF_PINNED` flag is not movable, but also the bytes which is marked with `BF_LARGE`. (I read the gc code and i'm confident this holds, but if it's not, please correct me).\r\n\r\nCurrently i'm using a FFI trick[https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c#L33] to get `isByteArrayPinned#` on older GHCs, i want to make sure if `BF_LARGE` works.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13429Optimizer produces Core with an infinite <<loop>>2022-08-06T23:27:36ZAlexey KuleshevichOptimizer produces Core with an infinite <<loop>>While using vector package to implement convolution and supplying `-O1` or `-02` to ghc compilation results in core with an infinite loop. In order to trigger this behavior at least two modules is required. Attached is the minimal setup ...While using vector package to implement convolution and supplying `-O1` or `-02` to ghc compilation results in core with an infinite loop. In order to trigger this behavior at least two modules is required. Attached is the minimal setup that I could come up with, that demonstrates the issue. Here is the stack trace:
```
$ stack --install-ghc --resolver lts-8.3 exec -- ghc -O1 -prof -fprof-auto main.hs && ./main +RTS -xc
[1 of 2] Compiling Loop ( Loop.hs, Loop.o )
[2 of 2] Compiling Main ( main.hs, main.o )
Linking main ...
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.CAF
--> evaluated by: Main.main,
called from Main.CAF
--> evaluated by: Loop.toKernel.\,
called from Data.Vector.Fusion.Util.>>=,
called from Loop.toKernel,
called from Main.main,
called from Main.CAF
--> evaluated by: Data.Vector.Fusion.Util.>>=,
called from Loop.toKernel,
called from Main.main,
called from Main.CAF
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.CAF
main: <<loop>>
```
At first I though that it might be a bug in a vector package, which is still a possibility, but since I was not able to observe that issue with ghc-7.8.4, I decided to open an ticket here. I tested attached code with all of subsequent released ghc versions (7.10.1 - 8.0.2), which resulted in the infinite loop.
Worth noting that sometimes, when recompilation of only the `main.hs` file is enforced, program starts to work as expected. Here is an example:
```
$ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main
[1 of 2] Compiling Loop ( Loop.hs, Loop.o )
[2 of 2] Compiling Main ( main.hs, main.o )
Linking main ...
main: <<loop>>
$ touch main.hs
$ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main
[2 of 2] Compiling Main ( main.hs, main.o )
Linking main ...
<Image 1x1>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | IncorrectResultAtRuntime |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Optimizer produces Core with an infinite <<loop>>","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While using vector package to implement convolution and supplying `-O1` or `-02` to ghc compilation results in core with an infinite loop. In order to trigger this behavior at least two modules is required. Attached is the minimal setup that I could come up with, that demonstrates the issue. Here is the stack trace:\r\n\r\n{{{\r\n$ stack --install-ghc --resolver lts-8.3 exec -- ghc -O1 -prof -fprof-auto main.hs && ./main +RTS -xc\r\n[1 of 2] Compiling Loop ( Loop.hs, Loop.o )\r\n[2 of 2] Compiling Main ( main.hs, main.o )\r\nLinking main ...\r\n*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n Main.CAF\r\n --> evaluated by: Main.main,\r\n called from Main.CAF\r\n --> evaluated by: Loop.toKernel.\\,\r\n called from Data.Vector.Fusion.Util.>>=,\r\n called from Loop.toKernel,\r\n called from Main.main,\r\n called from Main.CAF\r\n --> evaluated by: Data.Vector.Fusion.Util.>>=,\r\n called from Loop.toKernel,\r\n called from Main.main,\r\n called from Main.CAF\r\n*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n Main.CAF\r\nmain: <<loop>>\r\n}}}\r\n\r\n\r\nAt first I though that it might be a bug in a vector package, which is still a possibility, but since I was not able to observe that issue with ghc-7.8.4, I decided to open an ticket here. I tested attached code with all of subsequent released ghc versions (7.10.1 - 8.0.2), which resulted in the infinite loop.\r\n\r\nWorth noting that sometimes, when recompilation of only the `main.hs` file is enforced, program starts to work as expected. Here is an example:\r\n\r\n\r\n{{{\r\n$ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main\r\n[1 of 2] Compiling Loop ( Loop.hs, Loop.o )\r\n[2 of 2] Compiling Main ( main.hs, main.o )\r\nLinking main ...\r\nmain: <<loop>>\r\n$ touch main.hs\r\n$ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main\r\n[2 of 2] Compiling Main ( main.hs, main.o )\r\nLinking main ...\r\n<Image 1x1>\r\n}}}\r\n","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->8.2.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/13411GCC driver fails on Windows 10 15019+2022-07-27T10:30:04ZTamar ChristinaGCC driver fails on Windows 10 15019+Our GCC driver seems to be failing with a compatibility error on Windows 10 Insider builds 15019+. Leaving error code 0xc0000142.
This driver has been unchanged since Windows XP and may just need some old APIs replaced.
<details><summa...Our GCC driver seems to be failing with a compatibility error on Windows 10 Insider builds 15019+. Leaving error code 0xc0000142.
This driver has been unchanged since Windows XP and may just need some old APIs replaced.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GCC driver fails on Windows 10 15019+","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Our GCC driver seems to be failing with a compatibility error on Windows 10 Insider builds 15019+. Leaving error code 0xc0000142.\r\n\r\nThis driver has been unchanged since Windows XP and may just need some old APIs replaced.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12243RebindableSyntax and OverloadedLabels2022-05-30T20:10:04ZhtebalakaRebindableSyntax and OverloadedLabelsShould these extensions work together? I wasn't able to come up with a good motivating example; I was playing around with lenses, and thought a more restrictive class definition might aid type inference, though it turned out in that part...Should these extensions work together? I wasn't able to come up with a good motivating example; I was playing around with lenses, and thought a more restrictive class definition might aid type inference, though it turned out in that particular case it didn't. In the general case I think it might still be useful.
I didn't see any discussion on this, and it seemed like maybe it's an oversight.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| 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":"RebindableSyntax and OverloadedLabels","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Should these extensions work together? I wasn't able to come up with a good motivating example; I was playing around with lenses, and thought a more restrictive class definition might aid type inference, though it turned out in that particular case it didn't. In the general case I think it might still be useful.\r\n\r\nI didn't see any discussion on this, and it seemed like maybe it's an oversight.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Adam GundryAdam Gundryhttps://gitlab.haskell.org/ghc/ghc/-/issues/12957In a record-update construct:ghc-stage2: panic! (the 'impossible' happened)2022-04-08T13:31:56ZniteriaIn a record-update construct:ghc-stage2: panic! (the 'impossible' happened)While compiling `Repro.hs` with `HEAD` I get this:
```
$ ~/local/ghc-inaccessible-right-side/inplace/bin/ghc-stage2 Repro.hs
[1 of 1] Compiling Repro ( Repro.hs, Repro.o )
Repro.hs:22:35: warning: [-Woverlapping-patterns]
...While compiling `Repro.hs` with `HEAD` I get this:
```
$ ~/local/ghc-inaccessible-right-side/inplace/bin/ghc-stage2 Repro.hs
[1 of 1] Compiling Repro ( Repro.hs, Repro.o )
Repro.hs:22:35: warning: [-Woverlapping-patterns]
Pattern match has inaccessible right hand side
In a record-update construct:ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20161209 for x86_64-unknown-linux):
unused
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
It doesn't reproduce on 7.10.2.
I'm 90% sure it reproduces on 8.0.2 (I have a branch with some unrelated patches).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| 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":"In a record-update construct:ghc-stage2: panic! (the 'impossible' happened)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While compiling `Repro.hs` with `HEAD` I get this:\r\n{{{\r\n$ ~/local/ghc-inaccessible-right-side/inplace/bin/ghc-stage2 Repro.hs\r\n[1 of 1] Compiling Repro ( Repro.hs, Repro.o )\r\n\r\nRepro.hs:22:35: warning: [-Woverlapping-patterns]\r\n Pattern match has inaccessible right hand side\r\n In a record-update construct:ghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20161209 for x86_64-unknown-linux):\r\n unused\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n}}}\r\n\r\nIt doesn't reproduce on 7.10.2.\r\nI'm 90% sure it reproduces on 8.0.2 (I have a branch with some unrelated patches).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/11143Feature request: Add index/read/write primops with byte offset for ByteArray#2022-03-04T18:48:26ZAlexey VagarenkoFeature request: Add index/read/write primops with byte offset for ByteArray#Currently, primops for indexing `ByteArray#` and reading/writing `MutableByteArray#` have the following form:
```hs
indexTYPEArray# :: ByteArray# -> Int# -> TYPE#
readTYPEArray# :: MutableByteArray# s -> Int# -> State# s -> (#...Currently, primops for indexing `ByteArray#` and reading/writing `MutableByteArray#` have the following form:
```hs
indexTYPEArray# :: ByteArray# -> Int# -> TYPE#
readTYPEArray# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, TYPE##)
writeTYPEArray# :: MutableByteArray# s -> Int# -> TYPE# -> State# s -> State# s
```
where second argument of type `Int#` is an offset measured in terms of the size of `TYPE#`.
This is inconvinient if I want to store values of different types inside `ByteArray#`: I have to read values of type `Int8` and then glue them together with some bitwise operations.
I suggest adding number of primops, similar to existing ones, which would accept offset in bytes from the start of the `ByteArray#`:
```hs
-- | Read 8-bit integer; offset in bytes.
indexByteInt8Array# :: ByteArray# -> Int# -> Int#
-- | Read 16-bit integer; offset in bytes.
indexByteInt16Array# :: ByteArray# -> Int# -> Int#
-- | Read 32-bit integer; offset in bytes.
indexByteInt32Array# :: ByteArray# -> Int# -> Int#
-- | Read 8-bit integer; offset in bytes.
readInt8Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##)
-- | Read 16-bit integer; offset in bytes.
readInt16Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##)
-- | Read 32-bit integer; offset in bytes.
readInt32Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##)
```
and so on...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.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":"Feature request: Add index/read/write primops with byte offset for ByteArray#","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, primops for indexing `ByteArray#` and reading/writing `MutableByteArray#` have the following form:\r\n{{{#!hs\r\nindexTYPEArray# :: ByteArray# -> Int# -> TYPE#\r\nreadTYPEArray# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, TYPE##)\r\nwriteTYPEArray# :: MutableByteArray# s -> Int# -> TYPE# -> State# s -> State# s\r\n}}}\r\nwhere second argument of type `Int#` is an offset measured in terms of the size of `TYPE#`.\r\n\r\nThis is inconvinient if I want to store values of different types inside `ByteArray#`: I have to read values of type `Int8` and then glue them together with some bitwise operations.\r\n\r\nI suggest adding number of primops, similar to existing ones, which would accept offset in bytes from the start of the `ByteArray#`:\r\n{{{#!hs\r\n-- | Read 8-bit integer; offset in bytes.\r\nindexByteInt8Array# :: ByteArray# -> Int# -> Int#\r\n\r\n-- | Read 16-bit integer; offset in bytes.\r\nindexByteInt16Array# :: ByteArray# -> Int# -> Int#\r\n\r\n-- | Read 32-bit integer; offset in bytes.\r\nindexByteInt32Array# :: ByteArray# -> Int# -> Int#\r\n\r\n-- | Read 8-bit integer; offset in bytes.\r\nreadInt8Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##)\r\n\r\n-- | Read 16-bit integer; offset in bytes.\r\nreadInt16Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##)\r\n\r\n-- | Read 32-bit integer; offset in bytes.\r\nreadInt32Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##)\r\n}}}\r\nand so on...","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/10746No non-exhaustive pattern match warning given for empty case analysis2022-02-23T03:50:37ZBen GamariNo non-exhaustive pattern match warning given for empty case analysisI would expect GHC to warn of a non-exhaustive pattern match at compile-time when faced with this,
```hs
{-# LANGUAGE EmptyCase #-}
module Test where
test :: Bool -> Int
test a = case a of
```
Yet it happily accepts this without compl...I would expect GHC to warn of a non-exhaustive pattern match at compile-time when faced with this,
```hs
{-# LANGUAGE EmptyCase #-}
module Test where
test :: Bool -> Int
test a = case a of
```
Yet it happily accepts this without complaint. If one attempts to evaluate, e.g., `test True` the expected "Non-exhaustive patterns in case" error is thrown at runtime.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | edsko |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"No non-exhaustive pattern match warning given for empty case analysis","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["edsko"],"type":"Bug","description":"I would expect GHC to warn of a non-exhaustive pattern match at compile-time when faced with this,\r\n\r\n{{{#!hs\r\n{-# LANGUAGE EmptyCase #-}\r\nmodule Test where\r\n\r\ntest :: Bool -> Int\r\ntest a = case a of\r\n}}}\r\n\r\nYet it happily accepts this without complaint. If one attempts to evaluate, e.g., `test True` the expected \"Non-exhaustive patterns in case\" error is thrown at runtime.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/2721Newtype deriving doesn't work with type families2022-02-09T14:08:17Zrl@cse.unsw.edu.auNewtype deriving doesn't work with type familiesThis assumes `-XTypeFamiles -XGeneralizedNewtypeDeriving`. Example:
```
class C a where
type T a
foo :: a -> T a
instance C Int where
type T Int = Int
foo = id
newtype N = N Int deriving(C)
```
This happily produces an `insta...This assumes `-XTypeFamiles -XGeneralizedNewtypeDeriving`. Example:
```
class C a where
type T a
foo :: a -> T a
instance C Int where
type T Int = Int
foo = id
newtype N = N Int deriving(C)
```
This happily produces an `instance C N` but no `type instance T N`. It should either (preferably) generate
```
type instance T N = Int
```
or fail. The example also compiles if `T` is a data family (the `Int` instance needs to be change accordingly). It should probably fail in this case.
BTW, this also compiles fine, with rather dramatic consequences:
```
type family T a
class C a where
foo :: a -> T a
type instance T Int = Int
instance C Int where
foo = id
type instance T N = Double
newtype N = N Int deriving(C)
```
I guess this last example is the same bug as #1496. I wonder if the deriving clause could generate something like:
```
instance T Int ~ T N => C Int
```8.2.1