GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:06:36Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2840Top level string literals2019-07-07T19:06:36ZSimon Peyton JonesTop level string literalsAt the moment GHC's internal language does not allow any top-level definitions of unlifted type, and for the most part rightly so. But consider this:
```hs
f :: Int -> String
f n = let a::Addr# = "foo"
in let g y = ...a...g...
...At the moment GHC's internal language does not allow any top-level definitions of unlifted type, and for the most part rightly so. But consider this:
```hs
f :: Int -> String
f n = let a::Addr# = "foo"
in let g y = ...a...g...
in g n
```
Here we'd like to float the definitions out thus:
```hs
a::Addr# = "foo"
g y = ...a...g...
f n = g n
```
This is much better. Usually this happens, but not here, because we don't allow a top-level binding for an `Addr#`. But really perhaps we should allow an exception for *literals*, which can safely be bound at top level.
For literals other than strings, this doesn't make any difference, because we inline them freely. But for literal strings we don't want to make lots of copies of them; on the contrary we'd like to CSE identical strings. So it'd help to be able to bind them at top level.
Simon7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/2841Ghci + foreign export declarations result in undefined symbols2019-07-07T19:06:36Ziampure@gmail.comGhci + foreign export declarations result in undefined symbolsWhen using ghci and foreign export declarations, calling any function, _even_ test, will result in an unknown symbol error.
Another bug is that the compiler is not purely functional in the sense that without history (see below) it is po...When using ghci and foreign export declarations, calling any function, _even_ test, will result in an unknown symbol error.
Another bug is that the compiler is not purely functional in the sense that without history (see below) it is possible for it to work in one instance, but even then it doesn't. GHCi should have the property that if X works in a state S of the OS (collection of files, etc), then it should work in all states S', obtained by adding extra stuff to S, but not modifying anything. Currently, GHCi is breaking this fundamental property.
```
$ ghci New.hs
*Main> foo 1
<interactive>: New_stub.o: unknown symbol `Main_zdffoozuavi_closure'
```
```
{-# LANGUAGE ForeignFunctionInterface #-}
-- save in a file New.hs
foreign export ccall foo :: Int -> IO Int -- add this line and ghci will return something like New_stub.o: unknown symbol `Main_zdffoozuaIc_closure'
-- if you first try without the line, it works. If you still have stub files in the current directory, it will fail with the same message as before.
foo :: Int -> IO Int
foo = return . length . f
f :: Int -> [Int]
f 0 = []
f n = n:(f (n-1))
test = 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Ghci + foreign export declarations result in undefined symbols","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using ghci and foreign export declarations, calling any function, _even_ test, will result in an unknown symbol error. \r\n\r\nAnother bug is that the compiler is not purely functional in the sense that without history (see below) it is possible for it to work in one instance, but even then it doesn't. GHCi should have the property that if X works in a state S of the OS (collection of files, etc), then it should work in all states S', obtained by adding extra stuff to S, but not modifying anything. Currently, GHCi is breaking this fundamental property. \r\n\r\n{{{\r\n$ ghci New.hs\r\n*Main> foo 1\r\n<interactive>: New_stub.o: unknown symbol `Main_zdffoozuavi_closure'\r\n}}}\r\n\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n\r\n-- save in a file New.hs\r\n\r\nforeign export ccall foo :: Int -> IO Int -- add this line and ghci will return something like New_stub.o: unknown symbol `Main_zdffoozuaIc_closure'\r\n\r\n-- if you first try without the line, it works. If you still have stub files in the current directory, it will fail with the same message as before. \r\n\r\nfoo :: Int -> IO Int\r\nfoo = return . length . f\r\n\r\nf :: Int -> [Int]\r\nf 0 = []\r\nf n = n:(f (n-1))\r\n\r\ntest = 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/2842http://darcs.haskell.org/darcsweb/ throwing errors.2019-07-07T19:06:36Zhydohttp://darcs.haskell.org/darcsweb/ throwing errors.Click any link at http://darcs.haskell.org/darcsweb/ and you'll see.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.1 ...Click any link at http://darcs.haskell.org/darcsweb/ and you'll see.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | External Core |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"http://darcs.haskell.org/darcsweb/ throwing errors.","status":"New","operating_system":"","component":"External Core","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Click any link at http://darcs.haskell.org/darcsweb/ and you'll see.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/2843Missing "Defined but not used" for recursive expressions2019-07-07T19:06:36ZguestMissing "Defined but not used" for recursive expressions```
a :: Int
a =
let b = "foo"++b
in 42
```
In this example `b` is not really used, but there is no warning by GHC.
I assume this is so because `b` calls itself.
If I remove `++b` then I get the warning as expected.
(This reminds ...```
a :: Int
a =
let b = "foo"++b
in 42
```
In this example `b` is not really used, but there is no warning by GHC.
I assume this is so because `b` calls itself.
If I remove `++b` then I get the warning as expected.
(This reminds on the difference between a purely reference counting garbage collector and a correct one.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------- |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ghc@henning-thielemann.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Missing \"Defined but not used\" for recursive expressions","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ghc@henning-thielemann.de"],"type":"Bug","description":"{{{\r\na :: Int\r\na =\r\n let b = \"foo\"++b\r\n in 42\r\n}}}\r\n\r\nIn this example {{{b}}} is not really used, but there is no warning by GHC.\r\nI assume this is so because {{{b}}} calls itself.\r\nIf I remove {{{++b}}} then I get the warning as expected.\r\n\r\n(This reminds on the difference between a purely reference counting garbage collector and a correct one.)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2844incorrect results when not compiling with optimisation2019-07-07T19:06:36ZIan Lynagh <igloo@earth.li>incorrect results when not compiling with optimisationThis is a cut-down `random1283`.
`R.hs`:
```
module R (randomIO) where
class Num a => Random a where
randomIO :: IO a
instance Random Int where
randomIO = return 10003
```
`s.hs`:
```
import R
main :: IO ()
main = do r >>=...This is a cut-down `random1283`.
`R.hs`:
```
module R (randomIO) where
class Num a => Random a where
randomIO :: IO a
instance Random Int where
randomIO = return 10003
```
`s.hs`:
```
import R
main :: IO ()
main = do r >>= print
r >>= print
r :: IO Int
r = randomIO
```
```
$ rm *.o *.hi s
$ ghc -c R.hs
$ ghc s.hs R.o -o s
$ ./s
-4611686018427387865
-4611686018427387865
$ rm *.o *.hi s
$ ghc -c R.hs
$ ghc s.hs R.o -o s -O
$ ./s
10003
10003
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.11.20081205
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"incorrect results when not compiling with optimisation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a cut-down `random1283`.\r\n\r\n`R.hs`:\r\n{{{\r\nmodule R (randomIO) where\r\n\r\nclass Num a => Random a where\r\n randomIO :: IO a\r\n\r\ninstance Random Int where\r\n randomIO = return 10003\r\n}}}\r\n\r\n`s.hs`:\r\n{{{\r\nimport R\r\n\r\nmain :: IO ()\r\nmain = do r >>= print\r\n r >>= print\r\n\r\nr :: IO Int\r\nr = randomIO\r\n}}}\r\n\r\n{{{\r\n$ rm *.o *.hi s\r\n$ ghc -c R.hs\r\n$ ghc s.hs R.o -o s\r\n$ ./s\r\n-4611686018427387865\r\n-4611686018427387865\r\n$ rm *.o *.hi s\r\n$ ghc -c R.hs\r\n$ ghc s.hs R.o -o s -O\r\n$ ./s\r\n10003\r\n10003\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.11.20081205\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2845break018 skips a step2019-07-07T19:06:35ZIan Lynagh <igloo@earth.li>break018 skips a stepThe `break018` test is failing:
```
@@ -1,13 +1,11 @@
Stopped at ../mdo.hs:(29,0)-(31,26)
-_result :: IO (N a) = _
-Stopped at ../mdo.hs:(29,15)-(31,26)
-_result :: IO (N Char) = _
-x :: Char = 'h'
-xs :: [Char] = _
+_result :: (# GHC....The `break018` test is failing:
```
@@ -1,13 +1,11 @@
Stopped at ../mdo.hs:(29,0)-(31,26)
-_result :: IO (N a) = _
-Stopped at ../mdo.hs:(29,15)-(31,26)
-_result :: IO (N Char) = _
-x :: Char = 'h'
-xs :: [Char] = _
+_result :: (# GHC.Prim.State# GHC.Prim.RealWorld, N a #) = _
Stopped at ../mdo.hs:29:29-41
_result :: IO (N Char) = _
f :: N Char = _
l :: N Char = _
x :: Char = 'h'
Stopped at ../mdo.hs:(7,0)-(8,41)
-_result :: IO (N a) = _
+_result :: (# GHC.Prim.State# GHC.Prim.RealWorld, N a #) = _
+Stopped at ../mdo.hs:7:25-38
+_result :: IO (IORef Bool) = _
*** unexpected failure for break018(ghci)
```
What's happening here is that as we `:st` through the evaluation we aren't stopping at the `mdo` expression any more; we go straight from the entire `l2dll` to the `newNode` expression:
```
l2dll :: [a] -> IO (N a)
l2dll (x:xs) = mdo c <- newNode l x f
(f, l) <- l2dll' c xs
return c
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"break018 skips a step","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `break018` test is failing:\r\n{{{\r\n@@ -1,13 +1,11 @@\r\n Stopped at ../mdo.hs:(29,0)-(31,26)\r\n-_result :: IO (N a) = _\r\n-Stopped at ../mdo.hs:(29,15)-(31,26)\r\n-_result :: IO (N Char) = _\r\n-x :: Char = 'h'\r\n-xs :: [Char] = _\r\n+_result :: (# GHC.Prim.State# GHC.Prim.RealWorld, N a #) = _\r\n Stopped at ../mdo.hs:29:29-41\r\n _result :: IO (N Char) = _\r\n f :: N Char = _\r\n l :: N Char = _\r\n x :: Char = 'h'\r\n Stopped at ../mdo.hs:(7,0)-(8,41)\r\n-_result :: IO (N a) = _\r\n+_result :: (# GHC.Prim.State# GHC.Prim.RealWorld, N a #) = _\r\n+Stopped at ../mdo.hs:7:25-38\r\n+_result :: IO (IORef Bool) = _\r\n*** unexpected failure for break018(ghci)\r\n}}}\r\nWhat's happening here is that as we `:st` through the evaluation we aren't stopping at the `mdo` expression any more; we go straight from the entire `l2dll` to the `newNode` expression:\r\n{{{\r\nl2dll :: [a] -> IO (N a)\r\nl2dll (x:xs) = mdo c <- newNode l x f\r\n (f, l) <- l2dll' c xs\r\n return c\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2846Impredicativity bug: GHC crash by type signature2019-07-07T19:06:35Zmm_freakImpredicativity bug: GHC crash by type signatureQuick and dirty, this is the bug:
```
Prelude> [1,2,3] :: [Num a => a]
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
TcTyFuns.flattenType: unexpected PredType
```
I'm running Gentoo Linu...Quick and dirty, this is the bug:
```
Prelude> [1,2,3] :: [Num a => a]
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
TcTyFuns.flattenType: unexpected PredType
```
I'm running Gentoo Linux. I can reproduce this bug in the interpreter as well as in the compiler. It seems like it happens only with `-fglasgow-exts`, and only if you use `show` on that specific list. It doesn't happen, if you only use the head or the tail of the list. There is also no problem with appending something using `(++)` or consing through `(:)`.
This is an amd64 architecture, but I'm using a 32 bits system, so this should be irrelevant.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"GHC crash by type signature","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["crash,","type"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Quick and dirty, this is the bug:\r\n\r\n{{{\r\nPrelude> [1,2,3] :: [Num a => a]\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-unknown-linux):\r\n TcTyFuns.flattenType: unexpected PredType\r\n}}}\r\n\r\nI'm running Gentoo Linux. I can reproduce this bug in the interpreter as well as in the compiler. It seems like it happens only with {{{-fglasgow-exts}}}, and only if you use {{{show}}} on that specific list. It doesn't happen, if you only use the head or the tail of the list. There is also no problem with appending something using {{{(++)}}} or consing through {{{(:)}}}.\r\n\r\nThis is an amd64 architecture, but I'm using a 32 bits system, so this should be irrelevant.","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/2847Failure on OPTION_* pramgas other than GHC2019-07-07T19:06:35ZNeil MitchellFailure on OPTION_* pramgas other than GHCGHC should not attempt to look at other peoples pragmas. For example:
```
{-# OPTIONS_DERIVE --derive=Data,Typeable,Eq,Ord #-}
module Example where
data Foo = Bar
```
This worked fine with GHC 6.8, but doesn't with GHC 6.10. It says:
...GHC should not attempt to look at other peoples pragmas. For example:
```
{-# OPTIONS_DERIVE --derive=Data,Typeable,Eq,Ord #-}
module Example where
data Foo = Bar
```
This worked fine with GHC 6.8, but doesn't with GHC 6.10. It says:
```
C:\Neil\derive>ghc Example.hs -c
Example.hs:1:11-48:
unknown flag in {-# OPTIONS #-} pragma: _DERIVE
Example.hs:1:11-48:
unknown flag in {-# OPTIONS #-} pragma: --derive=Data,Typeable,Eq,Ord
```
I consider this to be a major regression, as it breaks (amongst other things) the Yhc compiler, the Derive tool, and my thesis. I suspect it will also break anything Malcolm has set up with OPTION_YHC or OPTION_NHC pragmas.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Failure on OPTION_* pramgas other than GHC","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"GHC should not attempt to look at other peoples pragmas. For example:\r\n\r\n{{{\r\n{-# OPTIONS_DERIVE --derive=Data,Typeable,Eq,Ord #-}\r\nmodule Example where\r\ndata Foo = Bar\r\n}}}\r\n\r\nThis worked fine with GHC 6.8, but doesn't with GHC 6.10. It says:\r\n\r\n{{{\r\nC:\\Neil\\derive>ghc Example.hs -c\r\nExample.hs:1:11-48:\r\n unknown flag in {-# OPTIONS #-} pragma: _DERIVE\r\nExample.hs:1:11-48:\r\n unknown flag in {-# OPTIONS #-} pragma: --derive=Data,Typeable,Eq,Ord\r\n}}}\r\n\r\nI consider this to be a major regression, as it breaks (amongst other things) the Yhc compiler, the Derive tool, and my thesis. I suspect it will also break anything Malcolm has set up with OPTION_YHC or OPTION_NHC pragmas.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2848threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC.2019-07-07T19:06:34Ztomasz.zielonka@gmail.comthreadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC.We(\*) have found a serious bug in the non-threaded RTS on 32-bit \*nix systems.
Calling threadDelay at certain clock-time intervals can make the thread
wait forever. This happens regularly, approximately every 49 days 17 hours,
or, more...We(\*) have found a serious bug in the non-threaded RTS on 32-bit \*nix systems.
Calling threadDelay at certain clock-time intervals can make the thread
wait forever. This happens regularly, approximately every 49 days 17 hours,
or, more accurately, every `(2^32 / 1000)` seconds. You can reproduce the bug with
a simple program, if you set your machine's clock to a specially crafted
time.
In this description I assume a 32-bit \*nix system, where the type
unsigned long has 32 bits.
If you want to see this happen, here is an instruction:
Test.hs:
```
import Control.Concurrent
main = threadDelay 5000000 -- 5 secs
```
Running on Linux, as root:
```
# date --set 'Thu Jan 22 20:20:10 UTC 2009' +%s; strace ./Delay
...
gettimeofday({1232655610, 12122}, NULL) = 0
gettimeofday({1232655610, 12171}, NULL) = 0
gettimeofday({1232655610, 12195}, NULL) = 0
select(0, [], [], NULL, {5, 20000}) = 0 (Timeout)
gettimeofday({1232655615, 32125}, NULL) = 0
select(0, [], [], NULL, {0, 4000}) = 0 (Timeout)
gettimeofday({1232655615, 35777}, NULL) = 0
select(0, [], [], NULL, {0, 4000}) = 0 (Timeout)
gettimeofday({1232655615, 40039}, NULL) = 0
select(0, [], [], NULL, {4294, 951296}
```
The runtime slept for more than 5 seconds, but it didn't wake up the
thread, but instead started waiting for an evil looking amount of time.
I've managed to find the exact location of the bug, in function
getourtimeofday() in rts/posix/Itimer.c. Other parts of non-threaded
RTS, and especially the function awaitEvent(rtsBool) in
rts/posix/Select.c, assume that the results of getourtimeofday() use the
full range of values in lnat. But this isn't so. Let's take a look at
the current version of this function:
```
lnat
getourtimeofday(void)
{
struct timeval tv;
nat interval;
interval = RtsFlags.MiscFlags.tickInterval;
if (interval == 0) { interval = 50; }
gettimeofday(&tv, (struct timezone *) NULL);
// cast to lnat because nat may be 64 bit when int is only 32 bit
return ((lnat)tv.tv_sec * 1000 / interval +
(lnat)tv.tv_usec / (interval * 1000));
}
```
Look at the first half of the expression in the return statement:
```
(lnat)tv.tv_sec * 1000 / interval
```
Here, tv.tv_sec is first converted to lnat, than multiplied by 1000, and
finally divided by interval. lnat is defined as "unsigned long" - on a
32-bit system this is usually a 32-bit type. The result of multiplying
by 1000 will have its higher bits lost and it will be in the range `[0 .. 2^32 - 1]`. Dividing it by interval will shrink the range to `[0 .. (2^32 - 1) / interval]`. With default value of tickInterval - which is `50` - this will be `[0 .. 85899345]`. Adding the second part of the expression
can only increase it by `(999999 / (interval * 1000))`, which is equal to
19 with default settings.
So, for default parameters, the result of getourtimeofday() will be in
`[0 .. 85899364]`. Why is it a problem? It's quite simple: When a thread
executes threadDelay the runtime calculates the tick at which it should
be woken up. In our example, threadDelay is executed at tick 85899266,
and the time of wake-up is probably calculated as
`85899266 + 5 * (1000 / 50) = 85899366`. This is greater then the biggest value `getourtimeofday()`
can return.
At this point I've probably already given too much detail, so I'll
stop. I think the fix is quite easy: just perform the problematic part
of computation on a wider integral type and cast it to lnat at the end.
There is also an easy workaround: compile your program with -threaded.
The threaded runtime does not use this code, and AFAICT, the time is
tracked using a 64-bit number of microseconds.
When I was trying to understand the problem, for some time the culprit
for me was the "clever trick" mentionad at the top of
rts/posix/Select.c. Now I understand it better and think it's innocent.
We have found this bug in GHC 6.6, and it's still there in the HEAD.
(\*) "We" means Mariusz Gądarowski, Przemysław Kosiak, Jakub Bogusz and
Tomasz Zielonka - employees of Gemius SA in Poland.
Mariusz and Przemek encountered this bug in their haskell system for distributing computations on a cluster. Mariusz and Jakub provided data about the symptoms of the problem - that was invaluable
because, as you can now see, the bug was very difficult to reproduce.
Tomasz finally spent four hours in solitude to nail the bug, and another
hour to write this report. The problem repeated itself for serveral
months, and in desperation Mariusz started to think about rewriting the
system in C++. Unfortunately, there is still such a posibility, because
we have another similar problem to solve. We are more optimistic now, but
this event raised some doubts about the development model of GHC. We are
afraid that with the current emphasis on adding new features you may be adding
bugs faster that you are removing them :-/6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2849RegAllocLinear.getStackSlotFor: out of stack slots2019-07-07T19:06:34ZhydoRegAllocLinear.getStackSlotFor: out of stack slots```
bash$ sudo cabal install --global HAppSHelpers
...
Linking dist/build/SymmetricTest/SymmetricTest ...
[1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Utils.o )
[2 of 4] Compiling Data.Dige...```
bash$ sudo cabal install --global HAppSHelpers
...
Linking dist/build/SymmetricTest/SymmetricTest ...
[1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Utils.o )
[2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o )
[3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o )
[4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
```
bash-3.2$ ghc-pkg list
/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf:
Cabal-1.6.0.1, HAppS-Data-0.9.3, HAppS-IxSet-0.9.3,
HAppS-Server-0.9.3.1, HAppS-State-0.9.3, HAppS-Util-0.9.3,
HSH-1.2.6, HStringTemplate-0.4.3, HStringTemplateHelpers-0.0.3,
HTTP-3001.1.3, HUnit-1.2.0.3, HaXml-1.13.3, MissingH-1.0.2.1,
QuickCheck-1.2.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0,
binary-0.4.4, bytestring-0.9.1.4, cairo-0.9.13, containers-0.2.0.0,
directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3),
(dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3),
(dph-seq-0.3), editline-0.2.1.0, filepath-1.1.0.1, gconf-0.9.13,
(ghc-6.10.1), ghc-prim-0.1.0.0, glade-0.9.13, glib-0.9.13,
gnomevfs-0.9.13, gtk-0.9.13, gtkglext-0.9.13, haddock-2.3.0,
haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.2,
hscolour-1.10.1, hslogger-1.0.6, hspread-0.3, html-1.0.1.2,
integer-0.1.0.0, mtl-1.1.0.2, network-2.2.0.1, old-locale-1.0.0.1,
old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.1.0.0,
parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, pureMD5-0.2.4,
random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1,
regex-posix-0.72.0.3, rts-1.0, safe-0.2, soegtk-0.9.13,
sourceview-0.9.13, stm-2.1.1.2, svgcairo-0.9.13, syb-0.1.0.0,
syb-with-class-0.4, template-haskell-2.3.0.0, terminfo-0.2.2.1,
time-1.1.2.2, unix-2.3.1.0, utf8-string-0.3.3, xhtml-3000.2.0.1,
zip-archive-0.1.1.1, zlib-0.4.0.4, zlib-0.5.0.0
bash-3.2$
```https://gitlab.haskell.org/ghc/ghc/-/issues/2850GeneralizedNewtypeDeriving + TypeFamilies doesn't work2019-07-07T19:06:34ZajdGeneralizedNewtypeDeriving + TypeFamilies doesn't workIt would be nice if we could do stuff like this:
```
{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, FlexibleContexts, FlexibleInstances #-}
class K a where
bar :: a -> a
class K (B a) => M a where
data B a :: *
foo :: B a...It would be nice if we could do stuff like this:
```
{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, FlexibleContexts, FlexibleInstances #-}
class K a where
bar :: a -> a
class K (B a) => M a where
data B a :: *
foo :: B a -> B a
instance M Bool where
data B Bool = B1Bool Bool | B2Bool Bool
foo = id
instance K (B Bool) where
bar = id
instance M Int where
newtype B Int = BInt (B Bool) deriving K
foo = id
```
which currently gives the error
```
foo.hs:17:41:
Can't make a derived instance of `K (B Int)'
(even with cunning newtype deriving:
the newtype may be recursive)
In the newtype instance declaration for `B'
```
However, the newtype is not recursive, it is just an associated datatype from another class, so it seems like this ought to work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"GeneralizedNewtypeDeriving + TypeFamilies doesn't work","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It would be nice if we could do stuff like this:\r\n\r\n{{{\r\n{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, FlexibleContexts, FlexibleInstances #-}\r\nclass K a where\r\n bar :: a -> a\r\n\r\nclass K (B a) => M a where\r\n data B a :: *\r\n foo :: B a -> B a\r\n\r\ninstance M Bool where\r\n data B Bool = B1Bool Bool | B2Bool Bool\r\n foo = id\r\n\r\ninstance K (B Bool) where\r\n bar = id\r\n\r\ninstance M Int where\r\n newtype B Int = BInt (B Bool) deriving K\r\n foo = id\r\n}}}\r\n\r\nwhich currently gives the error\r\n\r\n{{{\r\nfoo.hs:17:41:\r\n Can't make a derived instance of `K (B Int)'\r\n (even with cunning newtype deriving:\r\n the newtype may be recursive)\r\n In the newtype instance declaration for `B'\r\n}}}\r\n\r\nHowever, the newtype is not recursive, it is just an associated datatype from another class, so it seems like this ought to work.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2851Improve error message for failed deriving2019-07-07T19:06:33ZguestImprove error message for failed derivingThe following does not work:
```
type family F a :: *
data D a = D (F a)
deriving (Show)
```
The natural way of adding an instance does work (with enough extensions turned on):
```
instance (Show (F a)) => Show (D a) where
sh...The following does not work:
```
type family F a :: *
data D a = D (F a)
deriving (Show)
```
The natural way of adding an instance does work (with enough extensions turned on):
```
instance (Show (F a)) => Show (D a) where
show (D x) = "D " ++ show x
```
It would be nice if the deriving mechanism could derive this code.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Deriving doesn't work when type families are involved","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The following does not work:\r\n\r\n{{{\r\ntype family F a :: *\r\n\r\ndata D a = D (F a)\r\n deriving (Show)\r\n}}}\r\n\r\nThe natural way of adding an instance does work (with enough extensions turned on):\r\n\r\n{{{\r\ninstance (Show (F a)) => Show (D a) where\r\n show (D x) = \"D \" ++ show x\r\n}}}\r\n\r\nIt would be nice if the deriving mechanism could derive this code.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2852Type family checking oddity2019-07-07T19:06:33ZguestType family checking oddityConsider the following snipped
```
class C a where
type T a
data D a = D (T a)
```
If we now ask for the type of D we get
```
> :t D
D :: T a -> D a
```
I find this odd. The type T is in class C, so why is there no context on D ...Consider the following snipped
```
class C a where
type T a
data D a = D (T a)
```
If we now ask for the type of D we get
```
> :t D
D :: T a -> D a
```
I find this odd. The type T is in class C, so why is there no context on D saying so? It would be natural.
Now try some expression
```
> D True
<interactive>:1:2:
Couldn't match expected type `T a' against inferred type `Bool'
In the first argument of `D', namely `True'
In the expression: D True
In the definition of `it': it = D True
```
But this isn't really type incorrect, we just don't know yet. To remedy the problem we can use a context on the data declaration.
```
data (C a) => D a = D (T a)
```
And we try again
```
> :t D True
D True :: (Bool ~ T a, C a) => D a
```
This is what I would have expected in the first try as well; a context indicating what must hold for this to be type correct.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Type family checking oddity","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following snipped\r\n{{{\r\nclass C a where\r\n type T a\r\n\r\ndata D a = D (T a)\r\n}}}\r\nIf we now ask for the type of D we get\r\n{{{\r\n> :t D\r\nD :: T a -> D a\r\n}}}\r\nI find this odd. The type T is in class C, so why is there no context on D saying so? It would be natural.\r\n\r\nNow try some expression\r\n{{{\r\n> D True\r\n<interactive>:1:2:\r\n Couldn't match expected type `T a' against inferred type `Bool'\r\n In the first argument of `D', namely `True'\r\n In the expression: D True\r\n In the definition of `it': it = D True\r\n}}}\r\nBut this isn't really type incorrect, we just don't know yet. To remedy the problem we can use a context on the data declaration.\r\n\r\n{{{\r\ndata (C a) => D a = D (T a)\r\n}}}\r\nAnd we try again\r\n{{{\r\n> :t D True\r\nD True :: (Bool ~ T a, C a) => D a\r\n}}}\r\nThis is what I would have expected in the first try as well; a context indicating what must hold for this to be type correct.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2853Defaulting not used enough with type families2019-07-07T19:06:33ZguestDefaulting not used enough with type familiesConsider this module
```
{-# LANGUAGE TypeFamilies, ExtendedDefaultRules #-}
module Bug3 where
class C t where
type T t
instance C Integer where
type T Integer = Integer
data (C t, Num t) => D t = D (T t)
instance Show (D a) ...Consider this module
```
{-# LANGUAGE TypeFamilies, ExtendedDefaultRules #-}
module Bug3 where
class C t where
type T t
instance C Integer where
type T Integer = Integer
data (C t, Num t) => D t = D (T t)
instance Show (D a) where show _ = ""
```
Now let's try to ask for the type of (D 5)
```
*Bug3> :t D 5
D 5 :: (Num (T t), C t, Num t) => D t
```
That's great. Now if we try to show this value it should have type
```
(Num (T t), C t, Num t) => String
```
And now the defaulting mechanism should set t to Integer, which would resolve the rest of the context. But instead we get this:
```
*Bug3> :t show (D 5)
<interactive>:1:8:
No instance for (Num (T t))
arising from the literal `5' at <interactive>:1:8
Possible fix: add an instance declaration for (Num (T t))
In the first argument of `D', namely `5'
In the first argument of `show', namely `(D 5)'
In the expression: show (D 5)
```
It looks like the defaulting never got used.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Defaulting not used enough with type families","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this module\r\n{{{\r\n{-# LANGUAGE TypeFamilies, ExtendedDefaultRules #-}\r\nmodule Bug3 where\r\n\r\nclass C t where\r\n type T t\r\n\r\ninstance C Integer where\r\n type T Integer = Integer\r\n\r\ndata (C t, Num t) => D t = D (T t)\r\ninstance Show (D a) where show _ = \"\"\r\n}}}\r\nNow let's try to ask for the type of (D 5)\r\n{{{\r\n*Bug3> :t D 5\r\nD 5 :: (Num (T t), C t, Num t) => D t\r\n}}}\r\nThat's great. Now if we try to show this value it should have type\r\n{{{\r\n(Num (T t), C t, Num t) => String\r\n}}}\r\nAnd now the defaulting mechanism should set t to Integer, which would resolve the rest of the context. But instead we get this:\r\n{{{\r\n*Bug3> :t show (D 5)\r\n<interactive>:1:8:\r\n No instance for (Num (T t))\r\n arising from the literal `5' at <interactive>:1:8\r\n Possible fix: add an instance declaration for (Num (T t))\r\n In the first argument of `D', namely `5'\r\n In the first argument of `show', namely `(D 5)'\r\n In the expression: show (D 5)\r\n}}}\r\nIt looks like the defaulting never got used.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2854Extended defaulting rules not used for super classes2019-07-07T19:06:32ZguestExtended defaulting rules not used for super classesConsider the following module
```
{-# LANGUAGE ExtendedDefaultRules #-}
module Bug4 where
class (Num a) => C a where
f :: a -> a
instance C Integer where
f = (+1)
x = show (f 5)
```
The type of x is
```
x :: (C a) => String...Consider the following module
```
{-# LANGUAGE ExtendedDefaultRules #-}
module Bug4 where
class (Num a) => C a where
f :: a -> a
instance C Integer where
f = (+1)
x = show (f 5)
```
The type of x is
```
x :: (C a) => String
```
and since a is ambiguous the defaulting rules should be used. Since Num is a superclass of C the type variable should be defaulted to Integer. But instead we get an error.
Removing the Num superclass of C makes it work, since the type of x is
```
x ::: (Num a, C a) => String
```
and the defaulting kicks in as expected.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Extended defaulting rules not used for super classes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following module\r\n{{{\r\n{-# LANGUAGE ExtendedDefaultRules #-}\r\nmodule Bug4 where\r\n\r\nclass (Num a) => C a where\r\n f :: a -> a\r\n\r\ninstance C Integer where\r\n f = (+1)\r\n\r\nx = show (f 5)\r\n}}}\r\nThe type of x is\r\n{{{\r\nx :: (C a) => String\r\n}}}\r\nand since a is ambiguous the defaulting rules should be used. Since Num is a superclass of C the type variable should be defaulted to Integer. But instead we get an error.\r\n\r\nRemoving the Num superclass of C makes it work, since the type of x is\r\n{{{\r\nx ::: (Num a, C a) => String\r\n}}}\r\nand the defaulting kicks in as expected.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2855Surprising type (family) type derived2019-07-07T19:06:32ZguestSurprising type (family) type derivedConsider the following module
```
{-# LANGUAGE TypeFamilies #-}
module Bug5 where
class C a where
type T a
f :: T a -> T a -> T a
data D a = D { t :: T a }
g r = f (t r) (t r)
```
Now ask for the type of g
```
*Bug5> :t g
g...Consider the following module
```
{-# LANGUAGE TypeFamilies #-}
module Bug5 where
class C a where
type T a
f :: T a -> T a -> T a
data D a = D { t :: T a }
g r = f (t r) (t r)
```
Now ask for the type of g
```
*Bug5> :t g
g :: (T a ~ T a1, C a1) => D a -> T a1
```
Why isn't the type
```
g :: (C a) => D a -> T a
```
?
The strange type is a minor nuisance, but it gets worse
```
{-# LANGUAGE TypeFamilies #-}
module Bug6 where
class C a where
type T a
type U a
f :: T a -> T a -> T a
x :: U a -> T a
data D a = D { t :: T a, u :: U a }
g r = f (t r) (x (u r))
```
This doesn't type check at all.
An even simpler example that fails:
```
{-# LANGUAGE TypeFamilies, ScopedTypeVariables #-}
module Bug7 where
class C a where
type T a
type U a
x :: U a -> T a
data D a = D (U a)
g :: (C a) => D a -> T a
g (D u) = x u
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Surprising type (family) type derived","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart@augustsson.net"],"type":"Bug","description":"Consider the following module\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bug5 where\r\n\r\nclass C a where\r\n type T a\r\n f :: T a -> T a -> T a\r\n\r\ndata D a = D { t :: T a }\r\n\r\ng r = f (t r) (t r)\r\n}}}\r\nNow ask for the type of g\r\n{{{\r\n*Bug5> :t g\r\ng :: (T a ~ T a1, C a1) => D a -> T a1\r\n}}}\r\nWhy isn't the type\r\n{{{\r\ng :: (C a) => D a -> T a\r\n}}}\r\n?\r\n\r\nThe strange type is a minor nuisance, but it gets worse\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bug6 where\r\n\r\nclass C a where\r\n type T a\r\n type U a\r\n f :: T a -> T a -> T a\r\n x :: U a -> T a\r\n\r\ndata D a = D { t :: T a, u :: U a }\r\n\r\ng r = f (t r) (x (u r))\r\n}}}\r\nThis doesn't type check at all.\r\n\r\nAn even simpler example that fails:\r\n{{{\r\n{-# LANGUAGE TypeFamilies, ScopedTypeVariables #-}\r\nmodule Bug7 where\r\n\r\nclass C a where\r\n type T a\r\n type U a\r\n x :: U a -> T a\r\n\r\ndata D a = D (U a)\r\n\r\ng :: (C a) => D a -> T a\r\ng (D u) = x u\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2856GeneralizedNewtypeDeriving doesn't work with data families2019-07-07T19:06:32ZguestGeneralizedNewtypeDeriving doesn't work with data familiesObserve:
```
{-# LANGUAGE TypeFamilies, GeneralizedNewtypeDeriving #-}
module Bug9 where
class C a where
data D a
instance C Bool where
newtype D Bool = DInt Int deriving (Eq, Show, Num)
```
The deriving of Num fails, whereas...Observe:
```
{-# LANGUAGE TypeFamilies, GeneralizedNewtypeDeriving #-}
module Bug9 where
class C a where
data D a
instance C Bool where
newtype D Bool = DInt Int deriving (Eq, Show, Num)
```
The deriving of Num fails, whereas the corresponding standalone newtype works fine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GeneralizedNewtypeDeriving doesn't work with data families","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart@augustsson.net"],"type":"Bug","description":"Observe:\r\n{{{\r\n{-# LANGUAGE TypeFamilies, GeneralizedNewtypeDeriving #-}\r\nmodule Bug9 where\r\n\r\nclass C a where\r\n data D a\r\n\r\ninstance C Bool where\r\n newtype D Bool = DInt Int deriving (Eq, Show, Num)\r\n}}}\r\nThe deriving of Num fails, whereas the corresponding standalone newtype works fine.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2857sync-all ignores --complete2019-07-07T19:06:32Zmegaczsync-all ignores --completeThe ordering of the if...elsif...etc branches appears to be slightly off. A patch to fix this is attached.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| ...The ordering of the if...elsif...etc branches appears to be slightly off. A patch to fix this is attached.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"sync-all ignores --complete","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The ordering of the if...elsif...etc branches appears to be slightly off. A patch to fix this is attached.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2858Segmentation fault due to race between IO manager and installSignals.2019-07-07T19:06:31ZdshSegmentation fault due to race between IO manager and installSignals.Hello,
consider the attached test case.
To reproduce the problem please \[\[BR\]\]
1. compile the attached test case with -threaded\[\[BR\]\]
1. enable core dumps in the shell,\[\[BR\]\]
1. run infinite loop until core dump appears,\[...Hello,
consider the attached test case.
To reproduce the problem please \[\[BR\]\]
1. compile the attached test case with -threaded\[\[BR\]\]
1. enable core dumps in the shell,\[\[BR\]\]
1. run infinite loop until core dump appears,\[\[BR\]\]
1. to make core dumps actually appear run infinite pkill -TERM Test in another shell.\[\[BR\]\]
Regards,\[\[BR\]\]
Dmitry
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segmentation fault due to race between IO manager and installSignals.","status":"New","operating_system":"Linux","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["IOmanager","posix","signal","threaded"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nconsider the attached test case.\r\n\r\nTo reproduce the problem please [[BR]]\r\n1. compile the attached test case with -threaded[[BR]]\r\n2. enable core dumps in the shell,[[BR]]\r\n3. run infinite loop until core dump appears,[[BR]]\r\n4. to make core dumps actually appear run infinite pkill -TERM Test in another shell.[[BR]]\r\n\r\nRegards,[[BR]]\r\nDmitry","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2859Reduce coercion terms to normal form2019-07-07T19:06:31ZSimon Peyton JonesReduce coercion terms to normal formSometimes coercion terms in a Core program grow absurdly big, and can readily be simplified to be much more compact. Example:
- #2627
- #2440
Big coercion terms have no runtime impact, but they may make compilation slower.
I speculate...Sometimes coercion terms in a Core program grow absurdly big, and can readily be simplified to be much more compact. Example:
- #2627
- #2440
Big coercion terms have no runtime impact, but they may make compilation slower.
I speculate that it should be possible to use transformations such as those Max suggests in his comment on #2440, as a confluent, terminating rewriting system that makes coercion terms smaller, or, better still, rewrites them to a normal form. Then we can use "smart constructors" for coercion terms, so that they are always kept in normal form.
Identity coercions occur a lot, but are not so easy to recognise. I've also wondered about having some special representation for the identity.
This ticket is to remind us to look for such a rewrite system. Max, perhaps?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | batterseapower@hotmail.com, chak@cse.unsw.edu.au |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Reduce coercion terms to normal form","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["batterseapower@hotmail.com","chak@cse.unsw.edu.au"],"type":"Bug","description":"Sometimes coercion terms in a Core program grow absurdly big, and can readily be simplified to be much more compact. Example:\r\n * #2627\r\n * #2440\r\nBig coercion terms have no runtime impact, but they may make compilation slower.\r\n\r\nI speculate that it should be possible to use transformations such as those Max suggests in his comment on #2440, as a confluent, terminating rewriting system that makes coercion terms smaller, or, better still, rewrites them to a normal form. Then we can use \"smart constructors\" for coercion terms, so that they are always kept in normal form.\r\n\r\nIdentity coercions occur a lot, but are not so easy to recognise. I've also wondered about having some special representation for the identity.\r\n\r\nThis ticket is to remind us to look for such a rewrite system. Max, perhaps?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2860Redundant unblocking in POSIX generic_handler2019-07-07T19:06:31ZdshRedundant unblocking in POSIX generic_handlerGeneric handler redundantly unblocks signal at the end of generic handler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.1...Generic handler redundantly unblocks signal at the end of generic handler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Redundant unblocking in POSIX generic_handler","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["POSIX","generic_handler"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Generic handler redundantly unblocks signal at the end of generic handler.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2861stage2 crash: PAP object entered!2019-07-07T19:06:31ZSimon Marlowstage2 crash: PAP object entered!With stage2 today:
```
$ ./ghc/stage2-inplace/ghc -package foo
ghc: internal error: PAP object entered!
(GHC version 6.11 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Int...With stage2 today:
```
$ ./ghc/stage2-inplace/ghc -package foo
ghc: internal error: PAP object entered!
(GHC version 6.11 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Interestingly, `-dcore-lint` doesn't find any errors. Looking at the `-ddump-simpl` output for `Packages.hs`, this is the function that is supposed to throw the exception containing the error message for an unknown package. It has been suspiciously eta-expanded a bit...
```
a_r5fu :: GHC.Base.String
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.IOBase.IO [PackageConfig.PackageConfig]
[GlobalId]
[Arity 25]
a_r5fu =
\ (p_a1Pc :: GHC.Base.String)
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
(eta22_s5c7 :: GHC.Prim.State# GHC.Prim.RealWorld) ->
(\ (eta23_s5dN :: GHC.Prim.State# GHC.Prim.RealWorld) ->
((Panic.ghcError
@ (GHC.IOBase.IO [PackageConfig.PackageConfig])
(Panic.CmdLineError
(Pretty.fullRender
@ GHC.Base.String
Pretty.PageMode
Pretty.lvl1
Pretty.lvl
Pretty.string_txt
(GHC.Types.[] @ GHC.Types.Char)
(Pretty.Beside lvl_r5fs GHC.Bool.True (Pretty.text p_a1Pc)))))
`cast` (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig]
:: GHC.IOBase.IO [PackageConfig.PackageConfig]
~
GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld,
[PackageConfig.PackageConfig] #)))
eta23_s5dN)
`cast` (sym (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig])
:: GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld,
[PackageConfig.PackageConfig] #)
~
GHC.IOBase.IO [PackageConfig.PackageConfig])
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"stage2 crash: PAP object entered!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With stage2 today:\r\n\r\n{{{\r\n$ ./ghc/stage2-inplace/ghc -package foo\r\nghc: internal error: PAP object entered!\r\n (GHC version 6.11 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nInterestingly, `-dcore-lint` doesn't find any errors. Looking at the `-ddump-simpl` output for `Packages.hs`, this is the function that is supposed to throw the exception containing the error message for an unknown package. It has been suspiciously eta-expanded a bit...\r\n\r\n{{{\r\na_r5fu :: GHC.Base.String\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.IOBase.IO [PackageConfig.PackageConfig]\r\n[GlobalId]\r\n[Arity 25]\r\na_r5fu =\r\n \\ (p_a1Pc :: GHC.Base.String)\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n (eta22_s5c7 :: GHC.Prim.State# GHC.Prim.RealWorld) ->\r\n (\\ (eta23_s5dN :: GHC.Prim.State# GHC.Prim.RealWorld) ->\r\n ((Panic.ghcError\r\n @ (GHC.IOBase.IO [PackageConfig.PackageConfig])\r\n (Panic.CmdLineError\r\n (Pretty.fullRender\r\n @ GHC.Base.String\r\n Pretty.PageMode\r\n Pretty.lvl1\r\n Pretty.lvl\r\n Pretty.string_txt\r\n (GHC.Types.[] @ GHC.Types.Char)\r\n (Pretty.Beside lvl_r5fs GHC.Bool.True (Pretty.text p_a1Pc)))))\r\n `cast` (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig]\r\n :: GHC.IOBase.IO [PackageConfig.PackageConfig]\r\n ~\r\n GHC.Prim.State# GHC.Prim.RealWorld\r\n -> (# GHC.Prim.State# GHC.Prim.RealWorld,\r\n [PackageConfig.PackageConfig] #)))\r\n eta23_s5dN)\r\n `cast` (sym (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig])\r\n :: GHC.Prim.State# GHC.Prim.RealWorld\r\n -> (# GHC.Prim.State# GHC.Prim.RealWorld,\r\n [PackageConfig.PackageConfig] #)\r\n ~\r\n GHC.IOBase.IO [PackageConfig.PackageConfig])\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2862GHC Panic in ByteCodeGen2019-07-07T19:06:30Znominolo@gmail.comGHC Panic in ByteCodeGenTry to load the following problem with `ghc --interactive` of the latest HEAD.
```
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}
class Search id a where
search :: a -> ()
instance Search id () where
search d = undefine...Try to load the following problem with `ghc --interactive` of the latest HEAD.
```
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}
class Search id a where
search :: a -> ()
instance Search id () where
search d = undefined
-- works:
-- instance Search () () where search d = undefined
```
You get an irrefutable pattern match error in ByteCodeGen:644
The code calls `splitApp` and expects an `AnnVar v`. What it gets instead is:
```
\ (@ id{tv af0} [sk]) -> search1{v rfK} [gid] @ id{tv af0} [sk]
```
The argument to splitApp was:
```
((((\ (@ id{tv af0} [sk]) ->
search1{v rfK} [gid] @ id{tv af0} [sk])
`cast` (forall id{tv af0} [sk].
ghc-prim:GHC.Prim.sym{(w) tc 34v}
(main:Main.NTCo:T:Search{tc rfe}
id{tv af0} [sk] ghc-prim:GHC.Unit.(){(w) tc 40})
:: <pred>forall id{tv af0} [sk].
ghc-prim:GHC.Unit.(){(w) tc 40} -> ghc-prim:GHC.Unit.(){(w) tc 40}
~
forall id{tv af0} [sk].
main:Main.T:Search{tc rf8}
id{tv af0} [sk] ghc-prim:GHC.Unit.(){(w) tc 40}))
@ etaT_sg1{tv} [tv])
`cast` (main:Main.NTCo:T:Search{tc rfe}
etaT_sg1{tv} [tv] ghc-prim:GHC.Unit.(){(w) tc 40}
:: <pred>main:Main.T:Search{tc rf8}
etaT_sg1{tv} [tv] ghc-prim:GHC.Unit.(){(w) tc 40}
~
ghc-prim:GHC.Unit.(){(w) tc 40}
-> ghc-prim:GHC.Unit.(){(w) tc 40}))
eta_sg2{v} [lid]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"GHC Panic in ByteCodeGen","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Try to load the following problem with {{{ghc --interactive}}} of the latest HEAD.\r\n{{{\r\n{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}\r\n\r\nclass Search id a where\r\n search :: a -> ()\r\n\r\ninstance Search id () where\r\n search d = undefined\r\n\r\n-- works:\r\n-- instance Search () () where search d = undefined\r\n}}}\r\nYou get an irrefutable pattern match error in ByteCodeGen:644\r\n\r\nThe code calls {{{splitApp}}} and expects an {{{AnnVar v}}}. What it gets instead is:\r\n{{{\r\n\\ (@ id{tv af0} [sk]) -> search1{v rfK} [gid] @ id{tv af0} [sk]\r\n}}}\r\nThe argument to splitApp was:\r\n{{{\r\n((((\\ (@ id{tv af0} [sk]) ->\r\n search1{v rfK} [gid] @ id{tv af0} [sk])\r\n `cast` (forall id{tv af0} [sk].\r\n ghc-prim:GHC.Prim.sym{(w) tc 34v}\r\n (main:Main.NTCo:T:Search{tc rfe}\r\n id{tv af0} [sk] ghc-prim:GHC.Unit.(){(w) tc 40})\r\n :: <pred>forall id{tv af0} [sk].\r\n ghc-prim:GHC.Unit.(){(w) tc 40} -> ghc-prim:GHC.Unit.(){(w) tc 40}\r\n ~\r\n forall id{tv af0} [sk].\r\n main:Main.T:Search{tc rf8}\r\n id{tv af0} [sk] ghc-prim:GHC.Unit.(){(w) tc 40}))\r\n @ etaT_sg1{tv} [tv])\r\n `cast` (main:Main.NTCo:T:Search{tc rfe}\r\n etaT_sg1{tv} [tv] ghc-prim:GHC.Unit.(){(w) tc 40}\r\n :: <pred>main:Main.T:Search{tc rf8}\r\n etaT_sg1{tv} [tv] ghc-prim:GHC.Unit.(){(w) tc 40}\r\n ~\r\n ghc-prim:GHC.Unit.(){(w) tc 40}\r\n -> ghc-prim:GHC.Unit.(){(w) tc 40}))\r\n eta_sg2{v} [lid]\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2863ghc manual should note FFI non-compliance2019-07-07T19:06:30Zduncanghc manual should note FFI non-complianceThe FFI spec says about hs_init and hs_exit:
> In addition to nested calls to `hs_init()`, the Haskell system may be de-initialised with `hs_exit()` and be re-initialised with `hs_init()` at a later point in time.
The GHC manual says i...The FFI spec says about hs_init and hs_exit:
> In addition to nested calls to `hs_init()`, the Haskell system may be de-initialised with `hs_exit()` and be re-initialised with `hs_init()` at a later point in time.
The GHC manual says in the FFI chapter:
> There can be multiple calls to `hs_init()`, but each one should be matched by one (and only one) call to `hs_exit()`\[11\].
and adds in the footnote:
> \[11\] The outermost `hs_exit()` will actually de-initialise the system. NOTE that currently GHC's runtime cannot reliably re-initialise after this has happened.
The chapter on known bugs and infelicities should have a section on non-compliance with the FFI part of the spec and should note this limitation, that `hs_init()` does not necessarily work after the last `hs_exit()` call.
Of course if this can be fixed then that would be great. If not then perhaps it is better to make it fail obviously rather than possibly working or possibly going horribly wrong.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc manual should note FFI non-compliance","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The FFI spec says about hs_init and hs_exit:\r\n\r\n In addition to nested calls to `hs_init()`, the Haskell system may be de-initialised with `hs_exit()` and be re-initialised with `hs_init()` at a later point in time.\r\n\r\nThe GHC manual says in the FFI chapter:\r\n\r\n There can be multiple calls to `hs_init()`, but each one should be matched by one (and only one) call to `hs_exit()`[11].\r\n\r\nand adds in the footnote:\r\n\r\n [11] The outermost `hs_exit()` will actually de-initialise the system. NOTE that currently GHC's runtime cannot reliably re-initialise after this has happened.\r\n\r\nThe chapter on known bugs and infelicities should have a section on non-compliance with the FFI part of the spec and should note this limitation, that `hs_init()` does not necessarily work after the last `hs_exit()` call.\r\n\r\nOf course if this can be fixed then that would be great. If not then perhaps it is better to make it fail obviously rather than possibly working or possibly going horribly wrong.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2864ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug2019-07-07T19:06:30Zmegaczghc: panic! (the 'impossible' happened) -- Please report this as a GHC bugThe compiler asked me to report this.
```
/Users/megacz/proj/icfp09/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081208 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inative...The compiler asked me to report this.
```
/Users/megacz/proj/icfp09/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081208 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist-stage2/build -I../libffi/build/include -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include -optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist-stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf p_o -idist-stage2/build -H32m -O -Rghc-timing -O2 -c nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o -ohi dist-stage2/build/MachRegs.p_hi
ghc: panic! (the 'impossible' happened)
(GHC version 6.11.20081208 for i386-apple-darwin):
CoreToStg.myCollectArgs
(__scc {trivColorable ghc-6.11.20081208:MachRegs !}
ghc-6.11.20081208:MachRegs.isSqueesed{v r2zH} [gid] 0 0)
eta_s2Gv{v} [lid]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<<ghc: 127672968 bytes, 16 GCs, 5231957/10604544 avg/max bytes residency (3 samples), 38M in use, 0.00 INIT (0.00 elapsed), 0.36 MUT (0.46 elapsed), 0.16 GC (0.19 elapsed) :ghc>>
make[4]: *** [dist-stage2/build/MachRegs.p_o] Error 1
make[3]: *** [all] Error 1
make[2]: *** [build.stage.2] Error 2
make[1]: *** [stage2] Error 2
make: *** [bootstrap2] Error 2
```
This is using git HEAD, commit 2aba6f168b7bcb4f8c7c8e8f7cdc340a0ccb56e76.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2865Add more tab completions in GHCi for :set and :show2019-07-07T19:06:30Zsalty-horseAdd more tab completions in GHCi for :set and :showGHCi already has tab completions for several :set options, but not all of them.
:show also has a limited number of options and could be completed.
The (untested) attached patch addresses both issues.
<details><summary>Trac metadata</su...GHCi already has tab completions for several :set options, but not all of them.
:show also has a limited number of options and could be completed.
The (untested) attached patch addresses both issues.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add more autocompletions in GHCi for :set and :show","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHCi already has tab completions for several :set options, but not all of them.\r\n:show also has a limited number of options and could be completed.\r\n\r\nThe (untested) attached patch addresses both issues.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2866panic with GADTs + NoMonomorphismRestriction2019-07-07T19:06:29Zganeshpanic with GADTs + NoMonomorphismRestrictionThe program below causes
```
ganesh@defoe:~/temp$ ghc -c Test.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
initC: srt_lbl
```
with ghc, and
```
*Test> E 5
ghc: panic! (the 'impossib...The program below causes
```
ganesh@defoe:~/temp$ ghc -c Test.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
initC: srt_lbl
```
with ghc, and
```
*Test> E 5
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
nameModule xs{v afT}
```
with ghci
The problem goes away with ghc -O.
```
{-# LANGUAGE GADTs, NoMonomorphismRestriction #-}
module Test where
data Expr a = E Int
deriving Show
data IsSeq a where
IsSeq :: IsSeq [a]
isSeq :: Expr a -> IsSeq a
isSeq = undefined
mkSeq :: [Expr [a]] -> Expr [a]
mkSeq = undefined
unSeq :: Expr [a] -> [Expr [a]]
unSeq = undefined
sequenceEquality :: Expr a -> Expr a
sequenceEquality x = case isSeq x of
IsSeq -> let xs = unSeq x in mkSeq xs
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ganesh@earth.li |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic with GADTs + NoMonomorphismRestriction","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ganesh@earth.li"],"type":"Bug","description":"The program below causes\r\n\r\n{{{\r\nganesh@defoe:~/temp$ ghc -c Test.hs\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-unknown-linux):\r\n initC: srt_lbl\r\n}}}\r\n\r\nwith ghc, and \r\n\r\n{{{\r\n*Test> E 5\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-unknown-linux):\r\n nameModule xs{v afT}\r\n}}}\r\n\r\nwith ghci\r\n\r\nThe problem goes away with ghc -O.\r\n\r\n{{{\r\n{-# LANGUAGE GADTs, NoMonomorphismRestriction #-}\r\nmodule Test where\r\n\r\ndata Expr a = E Int\r\n deriving Show\r\n\r\ndata IsSeq a where\r\n IsSeq :: IsSeq [a]\r\n\r\nisSeq :: Expr a -> IsSeq a\r\nisSeq = undefined\r\n\r\nmkSeq :: [Expr [a]] -> Expr [a]\r\nmkSeq = undefined\r\n\r\nunSeq :: Expr [a] -> [Expr [a]]\r\nunSeq = undefined\r\n\r\nsequenceEquality :: Expr a -> Expr a\r\nsequenceEquality x = case isSeq x of\r\n IsSeq -> let xs = unSeq x in mkSeq xs\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2868`par` `pseq` does not work as expected2019-07-07T19:06:29Zhoangta`par` `pseq` does not work as expectedThe following Wombat program is from "A Tutorial on Parallel and Concurrent Programming in Haskell". It does not work as expected on my computer (Core(TM)2 Quad CPU). Only one core is used when I watch by "mpstat -P ALL 1 200". I compile...The following Wombat program is from "A Tutorial on Parallel and Concurrent Programming in Haskell". It does not work as expected on my computer (Core(TM)2 Quad CPU). Only one core is used when I watch by "mpstat -P ALL 1 200". I compile and run by:
```
ghc --make -threaded wombat.hs
./wombat +RTS -N4
```
and the result is:
```
par sum: 119201850
par time: 20.932636 seconds.
seq sum: 119201850
seq time: 20.926783 seconds.
```
Please check if is is a bug.
```
---- wombat.hs ----
import System.Time
import Control.Parallel
fib :: Int -> Int
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)
secDiff :: ClockTime -> ClockTime -> Float
secDiff (TOD secs1 psecs1) (TOD secs2 psecs2) =
fromInteger (psecs2 - psecs1) / 1e12 + fromInteger (secs2 - secs1)
mkList :: Int -> [Int]
mkList n = [1..n-1]
relprime :: Int -> Int -> Bool
relprime x y = gcd x y == 1
euler :: Int -> Int
euler n = length (filter (relprime n) (mkList n))
sumEuler :: Int -> Int
sumEuler = sum . (map euler) . mkList
seqSumFibEuler:: Int -> Int -> Int
seqSumFibEuler a b = fib a + sumEuler b
parSumFibEuler a b = f `par` (e `pseq` (e+ f))
where
f = fib a
e = sumEuler b
r1 = seqSumFibEuler 40 7450
r2 = parSumFibEuler 40 7450
main :: IO ()
main =
do
t0 <- getClockTime
pseq r1 (return())
t1 <- getClockTime
putStrLn ("seq sum: " ++ show r1)
putStrLn ("seq time: " ++ show (secDiff t0 t1) ++ " seconds.")
t0 <- getClockTime
pseq r2 (return())
t1 <- getClockTime
putStrLn ("par sum: " ++ show r2)
putStrLn ("par time: " ++ show (secDiff t0 t1) ++ " seconds.")
```6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2869Linking problem in S390 and ARM2019-07-07T19:06:29ZmarcotLinking problem in S390 and ARMThe bug is described in http://bugs.debian.org/482503 .
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type ...The bug is described in http://bugs.debian.org/482503 .
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.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":"Linking problem in S390 and ARM","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The bug is described in http://bugs.debian.org/482503 .","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2870User signals are not blocked before 'fork' in runInteractiveProcess2019-07-07T19:06:28ZdshUser signals are not blocked before 'fork' in runInteractiveProcessHello,\[\[BR\]\]
It is possible that the parent process handles user-defined interrupts for the child process. IOManager pipe and generic_handler is inherited in the child process. Pipe and generic_handler are used in threaded RTS.
Alt...Hello,\[\[BR\]\]
It is possible that the parent process handles user-defined interrupts for the child process. IOManager pipe and generic_handler is inherited in the child process. Pipe and generic_handler are used in threaded RTS.
Although the race window before 'exec' is small.\[\[BR\]\]
Regards,\[\[BR\]\]
Dmitry
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"User signals are not blocked before 'fork' in runInteractiveProcess","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["runInteractiveProcess","threaded"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,[[BR]]\r\n\r\nIt is possible that the parent process handles user-defined interrupts for the child process. IOManager pipe and generic_handler is inherited in the child process. Pipe and generic_handler are used in threaded RTS.\r\n\r\nAlthough the race window before 'exec' is small.[[BR]]\r\n\r\nRegards,[[BR]]\r\nDmitry\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2igooigoohttps://gitlab.haskell.org/ghc/ghc/-/issues/2871"Prologue junk?" error when building GHC2019-07-07T19:06:28ZDeewiant"Prologue junk?" error when building GHCAs far as I can tell this is a bug in the Evil Mangler.
This is on Windows, using MSYS to build. The relevant `make` output, compiling the HEAD:
```
make -C rts
make[1]: Entering directory `/D/Programming/src/ghc-HEAD/rts'
d:/Programmi...As far as I can tell this is a bug in the Evil Mangler.
This is on Windows, using MSYS to build. The relevant `make` output, compiling the HEAD:
```
make -C rts
make[1]: Entering directory `/D/Programming/src/ghc-HEAD/rts'
d:/Programming/src/ghc-HEAD/ghc/stage1-inplace/ghc -fvia-C -static -I../gmp/gmpbuild
-I../libffi/build/include -I. -dcmm-lint -c Apply.cmm -o Apply.o
Prologue junk?: .globl _stg_ap_0_fast
_stg_ap_0_fast:
/APP
# 9 "C:\Temp\/ghc3572_0/ghc3572_0.hc" 1
make[1]: *** [Apply.o] Error 9
make[1]: Leaving directory `/D/Programming/src/ghc-HEAD/rts'
make: *** [stage1] Error 2
```
This happens also when building 6.10.1, so it's not a HEAD problem. I didn't try other GHC versions.
`gcc --version`:
```
gcc.exe (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502
```
Attached is a `.raw_s` obtained by running the ghc command with `-keep-raw-s-file`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"\"Prologue junk?\" error when building GHC","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"As far as I can tell this is a bug in the Evil Mangler.\r\n\r\nThis is on Windows, using MSYS to build. The relevant `make` output, compiling the HEAD:\r\n{{{\r\nmake -C rts\r\nmake[1]: Entering directory `/D/Programming/src/ghc-HEAD/rts'\r\nd:/Programming/src/ghc-HEAD/ghc/stage1-inplace/ghc -fvia-C -static -I../gmp/gmpbuild\r\n-I../libffi/build/include -I. -dcmm-lint -c Apply.cmm -o Apply.o\r\nPrologue junk?: .globl _stg_ap_0_fast\r\n_stg_ap_0_fast:\r\n/APP\r\n # 9 \"C:\\Temp\\/ghc3572_0/ghc3572_0.hc\" 1\r\n\r\nmake[1]: *** [Apply.o] Error 9\r\nmake[1]: Leaving directory `/D/Programming/src/ghc-HEAD/rts'\r\nmake: *** [stage1] Error 2\r\n}}}\r\n\r\nThis happens also when building 6.10.1, so it's not a HEAD problem. I didn't try other GHC versions.\r\n\r\n`gcc --version`:\r\n{{{\r\ngcc.exe (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502\r\n}}}\r\n\r\nAttached is a `.raw_s` obtained by running the ghc command with `-keep-raw-s-file`.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2872sparc -mcpu=v9 is not used in assembly phase2019-07-07T19:06:28Zduncansparc -mcpu=v9 is not used in assembly phaseThe ghc `DriverPipeline.hs` adds `-mcpu=v9` when compiling .hs files on sparc:
```
#ifdef sparc_TARGET_ARCH
-- We only support SparcV9 and better because V8 lacks an atomic CAS
-- instruction. Note that the user can stil...The ghc `DriverPipeline.hs` adds `-mcpu=v9` when compiling .hs files on sparc:
```
#ifdef sparc_TARGET_ARCH
-- We only support SparcV9 and better because V8 lacks an atomic CAS
-- instruction. Note that the user can still override this
-- (e.g., -mcpu=ultrasparc) as GCC picks the "best" -mcpu flag
-- regardless of the ordering.
--
-- This is a temporary hack.
++ ["-mcpu=v9"]
#endif
```
This is great, but it does not add -mcpu=v9 when it calls gcc to assemble the .s file. So it fails because the .s file uses v9 instructions but we're not telling the assembler to use v9:
```
/tmp/ghc16216_0/ghc16216_0.split__1.s:22:0:
Error: Architecture mismatch on "blu,pn %icc,.LL4".
/tmp/ghc16216_0/ghc16216_0.split__1.s:22:0:
(Requires v9|v9a|v9b; requested architecture is v8.)
```
If one re-runs that failing command with -opta-mcpu=v9 then of course it works.
The general rule is that any -mcpu flags passed to gcc at the compile stage also have to be passed to gcc at the assembly phase.
Looking at the code it appears that the `-mcpu=v9` flag is passed for the `HCc` and `As` but not `SplitAs` phases. Of course the `SplitAs` phase is used during ghc bootstrapping which is where I found this failure. This is in ghc-6.8.3 but the code looks to be the same in 6.10 so I don't think it's already been fixed.
The workaround is to use `SRC_HC_OPTS=-opta-mcpu=v9` in `mk/build.mk`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| 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":"sparc -mcpu=v9 is not used in assembly phase","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The ghc `DriverPipeline.hs` adds `-mcpu=v9` when compiling .hs files on sparc:\r\n\r\n{{{\r\n#ifdef sparc_TARGET_ARCH\r\n -- We only support SparcV9 and better because V8 lacks an atomic CAS\r\n -- instruction. Note that the user can still override this\r\n -- (e.g., -mcpu=ultrasparc) as GCC picks the \"best\" -mcpu flag\r\n -- regardless of the ordering.\r\n --\r\n -- This is a temporary hack.\r\n ++ [\"-mcpu=v9\"]\r\n#endif\r\n}}}\r\n\r\nThis is great, but it does not add -mcpu=v9 when it calls gcc to assemble the .s file. So it fails because the .s file uses v9 instructions but we're not telling the assembler to use v9:\r\n\r\n{{{\r\n/tmp/ghc16216_0/ghc16216_0.split__1.s:22:0:\r\n Error: Architecture mismatch on \"blu,pn %icc,.LL4\".\r\n/tmp/ghc16216_0/ghc16216_0.split__1.s:22:0:\r\n (Requires v9|v9a|v9b; requested architecture is v8.)\r\n}}}\r\n\r\nIf one re-runs that failing command with -opta-mcpu=v9 then of course it works.\r\n\r\nThe general rule is that any -mcpu flags passed to gcc at the compile stage also have to be passed to gcc at the assembly phase.\r\n\r\nLooking at the code it appears that the `-mcpu=v9` flag is passed for the `HCc` and `As` but not `SplitAs` phases. Of course the `SplitAs` phase is used during ghc bootstrapping which is where I found this failure. This is in ghc-6.8.3 but the code looks to be the same in 6.10 so I don't think it's already been fixed.\r\n\r\nThe workaround is to use `SRC_HC_OPTS=-opta-mcpu=v9` in `mk/build.mk`.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2873ghc-pkg list/dump --package-conf=missing returns successful error code2019-07-07T19:06:28Zduncanghc-pkg list/dump --package-conf=missing returns successful error codeIf the user supplies a missing package file then ghc-pkg should return a non-0 exit code to indicate failure.
```
$ ghc-pkg list --package-conf=missing
missing:
```
(I note that we need a trac component for "Package system" tickets.)
...If the user supplies a missing package file then ghc-pkg should return a non-0 exit code to indicate failure.
```
$ ghc-pkg list --package-conf=missing
missing:
```
(I note that we need a trac component for "Package system" tickets.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"ghc-pkg list/dump --package-conf=missing returns successful error code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If the user supplies a missing package file then ghc-pkg should return a non-0 exit code to indicate failure.\r\n\r\n{{{\r\n$ ghc-pkg list --package-conf=missing\r\nmissing:\r\n}}}\r\n\r\n(I note that we need a trac component for \"Package system\" tickets.)","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2874Error message doesn't mention extension that is missing2019-07-07T19:06:27ZguestError message doesn't mention extension that is missingIf you forget to turn on a language extension then the error message usually mentions the missing extension. Not this message:
```
Illegal polymorphic or qualified type: forall a.
(Tradeabl...If you forget to turn on a language extension then the error message usually mentions the missing extension. Not this message:
```
Illegal polymorphic or qualified type: forall a.
(Tradeable a) =>
a -> b
In the type signature for `withSomeAgingContract':
withSomeAgingContract :: (forall a. (Tradeable a) => a -> b)
-> SomeAgingContract -> b
```
It should mention Rank2Types (or RankNTypes).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Error message doesn't mention extension that is missing","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart@augustsson.net"],"type":"Bug","description":"If you forget to turn on a language extension then the error message usually mentions the missing extension. Not this message:\r\n{{{\r\n Illegal polymorphic or qualified type: forall a.\r\n (Tradeable a) =>\r\n a -> b\r\n In the type signature for `withSomeAgingContract':\r\n withSomeAgingContract :: (forall a. (Tradeable a) => a -> b)\r\n -> SomeAgingContract -> b\r\n}}}\r\nIt should mention Rank2Types (or RankNTypes).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2875Correct SYB's representation of Char2019-07-07T19:06:27ZdreixelCorrect SYB's representation of CharSYB uses `DataRep` to represent datatypes:
```
-- | Public representation of datatypes
data DataRep = AlgRep [Constr]
| IntRep
| FloatRep
| StringRep
| NoRep
``...SYB uses `DataRep` to represent datatypes:
```
-- | Public representation of datatypes
data DataRep = AlgRep [Constr]
| IntRep
| FloatRep
| StringRep
| NoRep
```
I believe that `StringRep` should be `CharRep`. Note that `IntRep` is used for the primitive `Int` and `Integer` datatypes, `FloatRep` for `Float` and `Double`, and `StringRep` (apparently) for `Char`. `String`, however, is represented as `AlgRep [[],(:)]`:
```
*Main> dataTypeOf 'p'
DataType {tycon = "Prelude.Char", datarep = StringRep}
*Main> dataTypeOf "p"
DataType {tycon = "Prelude.[]", datarep = AlgRep [[],(:)]}
```
This makes sense, since `String` is not a primitive datatype. But it causes the apparently wrong behavior:
```
*Main> fromConstr (mkStringConstr (dataTypeOf "a") "ab") :: String
"*** Exception: mkStringConstr
*Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: String
"*** Exception: constrIndex
```
The correct way of using `mkStringConstr` is to construct a `Char`. This, however, only works for strings with a single character:
```
*Main> fromConstr (mkStringConstr (dataTypeOf 'a') "b") :: Char
'b'
*Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: Char
*** Exception: gunfold
*Main> fromConstr (mkStringConstr (dataTypeOf 'a') "") :: Char
*** Exception: gunfold
```
I find this behavior counterintuitive. Therefore I propose to rename `StringRep` to `CharRep` and `mkStringConstr` to `mkCharConstr`. For backwards compatibility, this entails:
- Deprecating `mkStringConstr` and `StringConstr`
- Deprecating `mkStringRep` and `StringRep`
- Introducing `mkCharConstr` and `CharConstr`
- Introducing `mkCharRep` and `CharRep`
Additionally, due to deprecation warnings, the following have to change as well:
- libraries/template-haskell/Language/Haskell/TH/Quote.hs
- compiler/utils/Serialized.hs
I'm attaching a patch with the proposed changes. I propose a discussion period of 4 weeks, therefore until the 8th of January.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Correct SYB's representation of Char","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"SYB uses `DataRep` to represent datatypes:\r\n\r\n{{{\r\n -- | Public representation of datatypes\r\n data DataRep = AlgRep [Constr]\r\n | IntRep\r\n | FloatRep\r\n | StringRep\r\n | NoRep\r\n}}}\r\n\r\n\r\nI believe that `StringRep` should be `CharRep`. Note that `IntRep` is used for the primitive `Int` and `Integer` datatypes, `FloatRep` for `Float` and `Double`, and `StringRep` (apparently) for `Char`. `String`, however, is represented as `AlgRep [[],(:)]`:\r\n\r\n{{{\r\n *Main> dataTypeOf 'p'\r\n DataType {tycon = \"Prelude.Char\", datarep = StringRep}\r\n *Main> dataTypeOf \"p\"\r\n DataType {tycon = \"Prelude.[]\", datarep = AlgRep [[],(:)]}\r\n}}}\r\n\r\n\r\nThis makes sense, since `String` is not a primitive datatype. But it causes the apparently wrong behavior:\r\n \r\n{{{\r\n *Main> fromConstr (mkStringConstr (dataTypeOf \"a\") \"ab\") :: String\r\n \"*** Exception: mkStringConstr\r\n *Main> fromConstr (mkStringConstr (dataTypeOf 'a') \"ab\") :: String\r\n \"*** Exception: constrIndex\r\n}}}\r\n\r\n\r\nThe correct way of using `mkStringConstr` is to construct a `Char`. This, however, only works for strings with a single character:\r\n\r\n{{{\r\n *Main> fromConstr (mkStringConstr (dataTypeOf 'a') \"b\") :: Char\r\n 'b'\r\n *Main> fromConstr (mkStringConstr (dataTypeOf 'a') \"ab\") :: Char\r\n *** Exception: gunfold\r\n *Main> fromConstr (mkStringConstr (dataTypeOf 'a') \"\") :: Char\r\n *** Exception: gunfold\r\n}}}\r\n\r\nI find this behavior counterintuitive. Therefore I propose to rename `StringRep` to `CharRep` and `mkStringConstr` to `mkCharConstr`. For backwards compatibility, this entails:\r\n * Deprecating `mkStringConstr` and `StringConstr`\r\n * Deprecating `mkStringRep` and `StringRep`\r\n * Introducing `mkCharConstr` and `CharConstr`\r\n * Introducing `mkCharRep` and `CharRep`\r\n\r\nAdditionally, due to deprecation warnings, the following have to change as well:\r\n * libraries/template-haskell/Language/Haskell/TH/Quote.hs\r\n * compiler/utils/Serialized.hs\r\n\r\nI'm attaching a patch with the proposed changes. I propose a discussion period of 4 weeks, therefore until the 8th of January.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2876Inconsistent error message2019-07-07T19:06:27ZguestInconsistent error messageMost error messages mention language extensions needed, this one mentions a deprectaed flag:
```
Illegal instance declaration for `...'
(the Coverage Condition fails for one of the functional dependencies;
Use -fall...Most error messages mention language extensions needed, this one mentions a deprectaed flag:
```
Illegal instance declaration for `...'
(the Coverage Condition fails for one of the functional dependencies;
Use -fallow-undecidable-instances to permit this)
```
It should instead mention -XUndecidableInstances.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Inconsistent error message","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Most error messages mention language extensions needed, this one mentions a deprectaed flag:\r\n{{{\r\n Illegal instance declaration for `...'\r\n (the Coverage Condition fails for one of the functional dependencies;\r\n Use -fallow-undecidable-instances to permit this)\r\n}}}\r\nIt should instead mention -XUndecidableInstances.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2877crash when printig a list (IO ())2019-07-07T19:06:27Zguestcrash when printig a list (IO ())```
data InputSignal = IS1 |
IS2
data OutputSignal = OS1 Widget [Int] |
OS2 Widget [String]
type Widget = InputSignal -> OutputSignal
testWidgetSignalProcessor :: (Int, Int, Int) -> Widget
testW...```
data InputSignal = IS1 |
IS2
data OutputSignal = OS1 Widget [Int] |
OS2 Widget [String]
type Widget = InputSignal -> OutputSignal
testWidgetSignalProcessor :: (Int, Int, Int) -> Widget
testWidgetSignalProcessor pos@(x, y, z) IS1 = OS1 (testWidgetSignalProcessor pos) [1, 2, 3]
testWidgetSignalProcessor pos@(x, y, z) IS2 = OS2 (testWidgetSignalProcessor (666, 666, 666)) ["ich", "kack", "ab"]
makeTestWidget :: (Int, Int, Int) -> Widget
makeTestWidget pos = testWidgetSignalProcessor pos
display :: OutputSignal -> IO ()
display (OS1 widget list) = print list
display (OS2 widget list) = print list
test :: IO ()
test = do
let testWidget = makeTestWidget (0, 0, 0)
display $ testWidget IS1
display $ testWidget IS2
```
when i enter "test" at the interpreter-prompt (i'm using ghci from emacs), it crashes with the following message:
```
: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-mingw32):
loadObj: failed
```
}https://gitlab.haskell.org/ghc/ghc/-/issues/2878panic while compiling Cabal-1.6.0.12019-07-07T19:06:26Zdvogelpanic while compiling Cabal-1.6.0.1While compiling Cabal-1.6.0.1, as packaged with Cabal-0.6.0, I got:
```
[16 of 50] Compiling Distribution.Simple.Utils ( Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o )
ghc-6.8.2: panic! (the 'impossible' happened...While compiling Cabal-1.6.0.1, as packaged with Cabal-0.6.0, I got:
```
[16 of 50] Compiling Distribution.Simple.Utils ( Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o )
ghc-6.8.2: panic! (the 'impossible' happened)
(GHC version 6.8.2 for x86_64-unknown-linux):
applyTypeToArgs
unix-2.3.0.0:System.Posix.Signals.a38{v rov8} [gid]
(unix-2.3.0.0:System.Posix.Signals.a5{v rov7} [gid]
`cast` (base:GHC.Prim.sym{(w) tc 34v}
(base:Foreign.C.Types.:CoCInt{tc r1dN})
:: <pred>base:GHC.Int.Int32{tc 3V}
~
<nt>base:Foreign.C.Types.CInt{tc r17X}))
unix-2.3.0.0:System.Posix.Signals.Ignore{v rov6} [gid]
(base:Data.Maybe.Nothing{v r6E} [gid]
@ <nt>unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rov5})
eta{v apCg} [lid]
(# base:GHC.Prim.State#{(w) tc 32q}
base:GHC.Prim.RealWorld{(w) tc 31E},
<nt>unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rov5} #)
```https://gitlab.haskell.org/ghc/ghc/-/issues/2879ghci : set - unset2019-07-07T19:06:26Zrileyrgdevghci : set - unsetreading Real World Haskell one of the first "get comfortable" tasks is to modify the Haskell prompt.
I would have expected :unset to revert it. But it does not.
Prelude Data.Ratio\>:unset prompt
unknown option: 'prompt'
Being new to H...reading Real World Haskell one of the first "get comfortable" tasks is to modify the Haskell prompt.
I would have expected :unset to revert it. But it does not.
Prelude Data.Ratio\>:unset prompt
unknown option: 'prompt'
Being new to Haskell I'm not sure if I am wrong, this is a bug or this is a feature request.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci : set - unset","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"reading Real World Haskell one of the first \"get comfortable\" tasks is to modify the Haskell prompt.\r\n\r\nI would have expected :unset to revert it. But it does not.\r\n\r\nPrelude Data.Ratio>:unset prompt\r\nunknown option: 'prompt'\r\n\r\nBeing new to Haskell I'm not sure if I am wrong, this is a bug or this is a feature request.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2880GHC panic when printing Unique2019-07-07T19:06:26ZsebfGHC panic when printing UniqueThe following program causes panic:
```
import UniqSupply
main = mkSplitUniqSupply 'x' >>= print . uniqFromSupply
```
The error message is:
```
ghcbug: ghcbug: panic! (the 'impossible' happened)
(GHC version 6.10.1 f...The following program causes panic:
```
import UniqSupply
main = mkSplitUniqSupply 'x' >>= print . uniqFromSupply
```
The error message is:
```
ghcbug: ghcbug: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
Static flags have not been initialised!
Please call GHC.newSession or GHC.parseStaticFlags early enough.
```
I have encountered this on an Apple !MacBook with GHC 6.10.1 and could reproduce it on a Linux PC with the same GHC version.
The module !UniqSupply comes from the ghc package which is hidden by default. So before compiling it (or running it in GHCi) type
```
ghc-pkg expose ghc
```
in a shell.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"GHC panic when printing Unique","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program causes panic:\r\n{{{\r\n import UniqSupply\r\n main = mkSplitUniqSupply 'x' >>= print . uniqFromSupply\r\n}}}\r\nThe error message is:\r\n{{{\r\n ghcbug: ghcbug: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\t Static flags have not been initialised!\r\n Please call GHC.newSession or GHC.parseStaticFlags early enough.\r\n}}}\r\n\r\nI have encountered this on an Apple !MacBook with GHC 6.10.1 and could reproduce it on a Linux PC with the same GHC version.\r\n\r\nThe module !UniqSupply comes from the ghc package which is hidden by default. So before compiling it (or running it in GHCi) type\r\n{{{\r\n ghc-pkg expose ghc\r\n}}}\r\nin a shell.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2881Basic Fibonacci function using Word causes ghci to panic. - 6.10.12019-07-07T19:06:26ZAlex MasonBasic Fibonacci function using Word causes ghci to panic. - 6.10.1When inputting the function:
```
let fib :: Word -> Word; fib 0 = 1; fib 1 = 1; fib n = l + r where l = fib (n-2); r = fib (n-1)
```
GHCi produces a panic error:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i3...When inputting the function:
```
let fib :: Word -> Word; fib 0 = 1; fib 1 = 1; fib n = l + r where l = fib (n-2); r = fib (n-1)
```
GHCi produces a panic error:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
schemeE(AnnCase).my_discr __word 0
```
It has been confirmed on both OS X 10.5.5 and linux
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Basif Fibonacci function using Word causes ghci to panic. - 6.10.1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["Word","fibonacci","panic"],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"When inputting the function:\r\n\r\n{{{\r\nlet fib :: Word -> Word; fib 0 = 1; fib 1 = 1; fib n = l + r where l = fib (n-2); r = fib (n-1)\r\n}}}\r\n\r\nGHCi produces a panic error:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tschemeE(AnnCase).my_discr __word 0\r\n}}}\r\n\r\nIt has been confirmed on both OS X 10.5.5 and linux\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2882variable escaping in existential type error on 6.8 but not 6.102019-07-07T19:06:25Zckeenvariable escaping in existential type error on 6.8 but not 6.10I wrote a patch for darcs that does the following:
```
'l' -> do let selected = case get_choices pc of
(first_chs:>_:>last_chs) ->
if whichch == Last...I wrote a patch for darcs that does the following:
```
'l' -> do let selected = case get_choices pc of
(first_chs:>_:>last_chs) ->
if whichch == Last || whichch == FirstReversed
then last_chs else first_chs
putStrLn $ "---- Already selected "++things++" ----"
mapM_ putDocLn $ mapFL (\a ->
showPatch `unseal2` (seal2 $ tp_patch a)) selected
```
where
```
get_choices :: Patchy p => PatchChoices p C(x y) -> (FL (TaggedPatch p) :> FL (TaggedPatch p) :> FL (TaggedPatch p)) C(x y)
data (a1 :> a2) C(x y) = FORALL(z) (a1 C(x z)) :> (a2 C(z y))
data FL a C(x z) where
(:>:) :: a C(x y) -> FL a C(y z) -> FL a C(x z)
NilFL :: FL a C(x x)
```
This gives an error with ghc-6.8.2 on Mac OS X (others have reported errors with 6.8.3 as well):
```
Inferred type is less polymorphic than expected
Quantified type variable `z2' escapes
When checking an existential match that binds
first_chs :: FL (TaggedPatch p) x z1
last_chs :: FL (TaggedPatch p) z2 z
The pattern(s) have type(s): (:>)
(FL (TaggedPatch p))
(FL (TaggedPatch p) :> FL (TaggedPatch p))
x
z
The body has type: FL (TaggedPatch p) z2 z
In a case alternative:
(first_chs :> _ :> last_chs)
-> if whichch == Last || whichch == FirstReversed then
last_chs
else
first_chs
In the expression:
case get_choices pc of
(first_chs :> _ :> last_chs)
-> if whichch == Last || whichch == FirstReversed then
last_chs
else
first_chs
```
I have been convinced that this is indeed a programming error by the fine people on \#ghc. So the remaining question is: Why does it work on ghc-6.10.1?
I will try if I can construct a simpler test case.
Thanks,
Christian
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"variable escaping in existential type error on 6.8 but not 6.10","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I wrote a patch for darcs that does the following:\r\n{{{\r\n'l' -> do let selected = case get_choices pc of\r\n (first_chs:>_:>last_chs) ->\r\n if whichch == Last || whichch == FirstReversed\r\n then last_chs else first_chs\r\n putStrLn $ \"---- Already selected \"++things++\" ----\"\r\n mapM_ putDocLn $ mapFL (\\a ->\r\n showPatch `unseal2` (seal2 $ tp_patch a)) selected\r\n}}}\r\n\r\nwhere \r\n{{{\r\nget_choices :: Patchy p => PatchChoices p C(x y) -> (FL (TaggedPatch p) :> FL (TaggedPatch p) :> FL (TaggedPatch p)) C(x y)\r\ndata (a1 :> a2) C(x y) = FORALL(z) (a1 C(x z)) :> (a2 C(z y))\r\ndata FL a C(x z) where\r\n (:>:) :: a C(x y) -> FL a C(y z) -> FL a C(x z)\r\n NilFL :: FL a C(x x)\r\n\r\n}}}\r\n\r\nThis gives an error with ghc-6.8.2 on Mac OS X (others have reported errors with 6.8.3 as well):\r\n\r\n{{{\r\n Inferred type is less polymorphic than expected\r\n Quantified type variable `z2' escapes\r\n When checking an existential match that binds\r\n first_chs :: FL (TaggedPatch p) x z1\r\n last_chs :: FL (TaggedPatch p) z2 z\r\n The pattern(s) have type(s): (:>)\r\n (FL (TaggedPatch p))\r\n (FL (TaggedPatch p) :> FL (TaggedPatch p))\r\n x\r\n z\r\n The body has type: FL (TaggedPatch p) z2 z\r\n In a case alternative:\r\n (first_chs :> _ :> last_chs)\r\n -> if whichch == Last || whichch == FirstReversed then\r\n last_chs\r\n else\r\n first_chs\r\n In the expression:\r\n case get_choices pc of\r\n (first_chs :> _ :> last_chs)\r\n -> if whichch == Last || whichch == FirstReversed then\r\n last_chs\r\n else\r\n first_chs\r\n\r\n}}}\r\n\r\nI have been convinced that this is indeed a programming error by the fine people on #ghc. So the remaining question is: Why does it work on ghc-6.10.1?\r\n\r\nI will try if I can construct a simpler test case.\r\n\r\nThanks,\r\n\r\nChristian","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2883setitimer(ITIMER_VIRTUAL) is not always available2019-07-07T19:06:25Zsthibaulsetitimer(ITIMER_VIRTUAL) is not always availableOn some limited systems, setitimer(ITIMER_VIRTUAL) returns ENOSYS
because the kernel does not provide a way to schedule timers based on
virtual time. In such a case, rts/posix/Itimer.c should use
ITIMER_REAL.
<details><summary>Trac meta...On some limited systems, setitimer(ITIMER_VIRTUAL) returns ENOSYS
because the kernel does not provide a way to schedule timers based on
virtual time. In such a case, rts/posix/Itimer.c should use
ITIMER_REAL.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.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":"setitimer(ITIMER_VIRTUAL) is not always available","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On some limited systems, setitimer(ITIMER_VIRTUAL) returns ENOSYS\r\nbecause the kernel does not provide a way to schedule timers based on\r\nvirtual time. In such a case, rts/posix/Itimer.c should use\r\nITIMER_REAL.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2884Compiled code performance worsens when module names are long enough2019-07-07T19:06:25ZDaniel GorínCompiled code performance worsens when module names are long enoughAttached to this report is an example where by simply renaming a module, performance degrades 2.5 times.
```
#diff long-modname-ver.hs short-modname-ver.hs
2c2
< import VeryLongModuleName
---
> import ShortM
#diff VeryLongModuleName.hs...Attached to this report is an example where by simply renaming a module, performance degrades 2.5 times.
```
#diff long-modname-ver.hs short-modname-ver.hs
2c2
< import VeryLongModuleName
---
> import ShortM
#diff VeryLongModuleName.hs ShortM.hs
1c1
< module VeryLongModuleName
---
> module ShortM
#ghc --make -O2 -Wall long-modname-ver.hs
#ghc --make -O2 -Wall short-modname-ver.hs
#time -p ./long-modname-ver > /dev/null
real 55.90
user 55.17
sys 0.51
#time -p ./short-modname-ver > /dev/null
real 22.23
user 21.97
sys 0.10
```
According to some measures by dons, the threshold seems to be at module length 10 (see attached graph).
Some further disussion on this thread [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16037](http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16037).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Compiled code performance worsens when module names are long enough","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attached to this report is an example where by simply renaming a module, performance degrades 2.5 times.\r\n\r\n{{{\r\n#diff long-modname-ver.hs short-modname-ver.hs\r\n2c2\r\n< import VeryLongModuleName\r\n---\r\n> import ShortM\r\n\r\n#diff VeryLongModuleName.hs ShortM.hs\r\n1c1\r\n< module VeryLongModuleName\r\n---\r\n> module ShortM\r\n\r\n#ghc --make -O2 -Wall long-modname-ver.hs\r\n\r\n#ghc --make -O2 -Wall short-modname-ver.hs\r\n\r\n#time -p ./long-modname-ver > /dev/null\r\nreal 55.90\r\nuser 55.17\r\nsys 0.51\r\n\r\n#time -p ./short-modname-ver > /dev/null\r\nreal 22.23\r\nuser 21.97\r\nsys 0.10\r\n}}}\r\n\r\nAccording to some measures by dons, the threshold seems to be at module length 10 (see attached graph).\r\n\r\nSome further disussion on this thread [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16037].","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2885Late and confusing error on uncallable class method2019-07-07T19:06:25ZGhost UserLate and confusing error on uncallable class methodThis has been discussed on Haskell Café (http://www.haskell.org/pipermail/haskell-cafe/2008-December/051856.html), I'm reporting it here in case something can be done to help other confused souls in future.
In short, the error message r...This has been discussed on Haskell Café (http://www.haskell.org/pipermail/haskell-cafe/2008-December/051856.html), I'm reporting it here in case something can be done to help other confused souls in future.
In short, the error message reported by GHC (6.10.1):
```
Could not deduce (Container x y) from the context (Container x y1)
arising from a use of `wrapper' at Test.hs:11:22-30
Possible fix:
add (Container x y) to the context of
the type signature for `liftWrap'
In the expression: wrapper x
In the expression:
(if wrapper x then rewrap . f . unwrap else id) x
In the definition of `liftWrap':
liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x
```
does not begin to indicate that the actual problem with the following program is in the type class declaration:
```
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}
import Data.Maybe
class Container x y where
wrapper :: x -> Bool
unwrap :: x -> y
rewrap :: y -> x
liftWrap :: Container x y => (y -> y) -> (x -> x)
liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x
instance Container (Maybe x) x where
wrapper = isJust
unwrap = fromJust
rewrap = Just
main = print (liftWrap (succ :: Int -> Int) (Just 1 :: Maybe Int))
```
If the 'wrapper' method can never be called in any possible context, there should be an error report at the point where the method is declared. I don't think that's a controversial statement. Even if the compiler allows the declaration under the assumption that the useless method is never called, it should at least emit a strong warning.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Late and confusing error on uncallable class method","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This has been discussed on Haskell Café (http://www.haskell.org/pipermail/haskell-cafe/2008-December/051856.html), I'm reporting it here in case something can be done to help other confused souls in future.\r\n\r\nIn short, the error message reported by GHC (6.10.1):\r\n\r\n{{{\r\n Could not deduce (Container x y) from the context (Container x y1)\r\n arising from a use of `wrapper' at Test.hs:11:22-30\r\n Possible fix:\r\n add (Container x y) to the context of\r\n the type signature for `liftWrap'\r\n In the expression: wrapper x\r\n In the expression:\r\n (if wrapper x then rewrap . f . unwrap else id) x\r\n In the definition of `liftWrap':\r\n liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x\r\n}}}\r\n\r\ndoes not begin to indicate that the actual problem with the following program is in the type class declaration:\r\n\r\n{{{\r\n {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}\r\n\r\n import Data.Maybe\r\n\r\n class Container x y where\r\n wrapper :: x -> Bool\r\n unwrap :: x -> y\r\n rewrap :: y -> x\r\n\r\n liftWrap :: Container x y => (y -> y) -> (x -> x)\r\n liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x\r\n\r\n instance Container (Maybe x) x where\r\n wrapper = isJust\r\n unwrap = fromJust\r\n rewrap = Just\r\n\r\n main = print (liftWrap (succ :: Int -> Int) (Just 1 :: Maybe Int))\r\n}}}\r\n\r\nIf the 'wrapper' method can never be called in any possible context, there should be an error report at the point where the method is declared. I don't think that's a controversial statement. Even if the compiler allows the declaration under the assumption that the useless method is never called, it should at least emit a strong warning.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2886Haddock documentation missing for haskell982019-07-07T19:06:25ZNeil MitchellHaddock documentation missing for haskell98The random library is empty: http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98/Random.html
As is Ratio: http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98/Ratio.html
These issues were reported on the haskell@...The random library is empty: http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98/Random.html
As is Ratio: http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98/Ratio.html
These issues were reported on the haskell@ list by Ron Legere
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Haddock documentation missing for haskell98","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The random library is empty: http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98/Random.html\r\n\r\nAs is Ratio: http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98/Ratio.html\r\n\r\nThese issues were reported on the haskell@ list by Ron Legere ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2887Segfault while configuring Cabal 1.6.0.1 on OS X 10.52019-07-07T19:06:24ZozySegfault while configuring Cabal 1.6.0.1 on OS X 10.5An unknown issue prevents Cabal from being built successfully on PPC Macs. I've tried compiling GHC from source with no change in the behavior. The following output is from Cabal's included Setup program, run inside GDB:
```
(gdb) run c...An unknown issue prevents Cabal from being built successfully on PPC Macs. I've tried compiling GHC from source with no change in the behavior. The following output is from Cabal's included Setup program, run inside GDB:
```
(gdb) run configure --user +RTS -DSs
Starting program: [...]/Cabal-1.6.0.1/Setup configure --user +RTS -DSs
Reading symbols for shared libraries +++. done
new task (taskCount: 1)
task exiting
new task (taskCount: 1)
created thread 1, stack size = f1 words
new bound thread (1)
### NEW SCHEDULER LOOP (task: 0x7005a0, cap: 0x3e7d98)
-->> running thread 1 ThreadRunGHC ...
--<< thread 1 (ThreadRunGHC) stopped, StackOverflow
increasing stack size from 241 words to 1009.
-->> running thread 1 ThreadRunGHC ...
thread 1 did a safe foreign call
thread 1: re-entering RTS
--<< thread 1 (ThreadRunGHC) stopped, yielding
-->> running thread 1 ThreadRunGHC ...
--<< thread 1 (ThreadRunGHC) stopped, yielding
-->> running thread 1 ThreadRunGHC ...
--<< thread 1 (ThreadRunGHC) stopped, yielding
-->> running thread 1 ThreadRunGHC ...
--<< thread 1 (ThreadRunGHC) stopped, yielding
-->> running thread 1 ThreadRunGHC ...
thread 1 did a safe foreign call
thread 1: re-entering RTS
--<< thread 1 (ThreadRunGHC) stopped, yielding
-->> running thread 1 ThreadRunGHC ...
--<< thread 1 (ThreadRunGHC) stopped: HeapOverflow
all threads:
threads on capability 0:
thread 1 @ 0x97d000 is not blocked
other threads:
Setup: internal error: ASSERTION FAILED: file Sanity.c, line 241
(GHC version 6.10.1 for powerpc_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Program received signal SIGABRT, Aborted.
0x94e29af0 in __kill ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Segfault while configuring Cabal 1.6.0.1 on OS X 10.5","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"An unknown issue prevents Cabal from being built successfully on PPC Macs. I've tried compiling GHC from source with no change in the behavior. The following output is from Cabal's included Setup program, run inside GDB:\r\n\r\n{{{\r\n(gdb) run configure --user +RTS -DSs\r\nStarting program: [...]/Cabal-1.6.0.1/Setup configure --user +RTS -DSs\r\nReading symbols for shared libraries +++. done\r\nnew task (taskCount: 1)\r\ntask exiting\r\nnew task (taskCount: 1)\r\ncreated thread 1, stack size = f1 words\r\nnew bound thread (1)\r\n### NEW SCHEDULER LOOP (task: 0x7005a0, cap: 0x3e7d98)\r\n-->> running thread 1 ThreadRunGHC ...\r\n--<< thread 1 (ThreadRunGHC) stopped, StackOverflow\r\nincreasing stack size from 241 words to 1009.\r\n-->> running thread 1 ThreadRunGHC ...\r\nthread 1 did a safe foreign call\r\nthread 1: re-entering RTS\r\n--<< thread 1 (ThreadRunGHC) stopped, yielding\r\n-->> running thread 1 ThreadRunGHC ...\r\n--<< thread 1 (ThreadRunGHC) stopped, yielding\r\n-->> running thread 1 ThreadRunGHC ...\r\n--<< thread 1 (ThreadRunGHC) stopped, yielding\r\n-->> running thread 1 ThreadRunGHC ...\r\n--<< thread 1 (ThreadRunGHC) stopped, yielding\r\n-->> running thread 1 ThreadRunGHC ...\r\nthread 1 did a safe foreign call\r\nthread 1: re-entering RTS\r\n--<< thread 1 (ThreadRunGHC) stopped, yielding\r\n-->> running thread 1 ThreadRunGHC ...\r\n--<< thread 1 (ThreadRunGHC) stopped: HeapOverflow\r\nall threads:\r\nthreads on capability 0:\r\n\tthread 1 @ 0x97d000 is not blocked\r\nother threads:\r\nSetup: internal error: ASSERTION FAILED: file Sanity.c, line 241\r\n\r\n (GHC version 6.10.1 for powerpc_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nProgram received signal SIGABRT, Aborted.\r\n0x94e29af0 in __kill ()\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2888Source file that compiled fine no longer compiles after touching it.2019-07-07T19:06:24ZEelis-Source file that compiled fine no longer compiles after touching it.In the following session, `t.hs` first compiles fine, then after being touched, no longer does:
```
eelis ~/sand : cat M.hs
{-# LANGUAGE TypeFamilies #-}
module M where
class C a where data D :: * -> *
eelis ~/sand : cat t.hs...In the following session, `t.hs` first compiles fine, then after being touched, no longer does:
```
eelis ~/sand : cat M.hs
{-# LANGUAGE TypeFamilies #-}
module M where
class C a where data D :: * -> *
eelis ~/sand : cat t.hs
{-# LANGUAGE TypeFamilies #-}
import M
data Bla = Bla
instance C Bla where data D a = D
main = return ()
eelis ~/sand : ghc --make t.hs
[1 of 2] Compiling M ( M.hs, M.o )
[2 of 2] Compiling Main ( t.hs, t.o )
Linking t ...
eelis ~/sand : touch t.hs
eelis ~/sand : ghc --make t.hs
[2 of 2] Compiling Main ( t.hs, t.o )
t.hs:4:21:
Type indexes must match class instance head
Found a but expected Bla
In the associated type instance for `D'
In the instance declaration for `C Bla'
```
It seems to me that `t.hs` should either compile both times, or not compile at all, but not only part of the time.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Source file that compiled fine no longer compiles after touching it.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the following session, {{{t.hs}}} first compiles fine, then after being touched, no longer does:\r\n{{{\r\n eelis ~/sand : cat M.hs\r\n {-# LANGUAGE TypeFamilies #-}\r\n module M where\r\n class C a where data D :: * -> *\r\n\r\n eelis ~/sand : cat t.hs\r\n {-# LANGUAGE TypeFamilies #-}\r\n import M\r\n data Bla = Bla\r\n instance C Bla where data D a = D\r\n main = return ()\r\n\r\n eelis ~/sand : ghc --make t.hs\r\n [1 of 2] Compiling M ( M.hs, M.o )\r\n [2 of 2] Compiling Main ( t.hs, t.o )\r\n Linking t ...\r\n\r\n eelis ~/sand : touch t.hs\r\n\r\n eelis ~/sand : ghc --make t.hs\r\n [2 of 2] Compiling Main ( t.hs, t.o )\r\n\r\n t.hs:4:21:\r\n Type indexes must match class instance head\r\n Found a but expected Bla\r\n In the associated type instance for `D'\r\n In the instance declaration for `C Bla'\r\n}}}\r\nIt seems to me that {{{t.hs}}} should either compile both times, or not compile at all, but not only part of the time.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2889Compilation fails - Can't open temporary2019-07-07T19:06:24ZfobrockCompilation fails - Can't open temporaryWhen compiling (either a .hs or linking .o's), the following error is reported and the .exe is not created:
C:\\PROGRA\~1\\GHC\\bin/windres: can't open temporary file \`\\/cca02256.irc': Invalid argument
Although it does not seem to be...When compiling (either a .hs or linking .o's), the following error is reported and the .exe is not created:
C:\\PROGRA\~1\\GHC\\bin/windres: can't open temporary file \`\\/cca02256.irc': Invalid argument
Although it does not seem to be a disk space problme ("Invalid argument"), I tried -tmpdir and the error was still reported.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Compilation fails - Can't opne temporary","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling (either a .hs or linking .o's), the following error is reported and the .exe is not created:\r\n\r\nC:\\PROGRA~1\\GHC\\bin/windres: can't open temporary file `\\/cca02256.irc': Invalid argument\r\n\r\nAlthough it does not seem to be a disk space problme (\"Invalid argument\"), I tried -tmpdir and the error was still reported.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2890Library docs are missing source links2019-07-07T19:06:24ZSimon MarlowLibrary docs are missing source linksOur library docs used to have links to !HsColoured source code - what happened to them?Our library docs used to have links to !HsColoured source code - what happened to them?6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2891threadDelay appears to use excessive CPU in GHCi2019-07-07T19:06:23ZJeremyShawthreadDelay appears to use excessive CPU in GHCiI have the following simple program:
import Control.Concurrent
main = threadDelay (10\^6) \>\> main
If I run it in GHCi it requires 2-5% of my CPU. If i compile it, it
takes 0% of my CPU. It does not matter if I compile -O0, -O2,
-thre...I have the following simple program:
import Control.Concurrent
main = threadDelay (10\^6) \>\> main
If I run it in GHCi it requires 2-5% of my CPU. If i compile it, it
takes 0% of my CPU. It does not matter if I compile -O0, -O2,
-threaded, it always uses 0% (which is good).
I have only tested this under Linux (Ubuntu Hardy) and GHC 6.8.3 on one machine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| 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":"threadDelay appears to use excessive CPU in GHCi","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have the following simple program:\r\n\r\nimport Control.Concurrent\r\nmain = threadDelay (10^6) >> main\r\n\r\nIf I run it in GHCi it requires 2-5% of my CPU. If i compile it, it\r\ntakes 0% of my CPU. It does not matter if I compile -O0, -O2,\r\n-threaded, it always uses 0% (which is good).\r\n\r\nI have only tested this under Linux (Ubuntu Hardy) and GHC 6.8.3 on one machine.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2892(threadDelay (-1)) hangs2019-07-07T19:06:23Zdancor(threadDelay (-1)) hangsthreadDelay silently hangs forever given a negative delay interval. It seems like this should at least be documented, but further is probably suboptimal magical behavior that leads to harder-to-find bugs; instead this should be an error....threadDelay silently hangs forever given a negative delay interval. It seems like this should at least be documented, but further is probably suboptimal magical behavior that leads to harder-to-find bugs; instead this should be an error. Conceivably threadDelay could take Maybe Int but that seems kind of out there.
Here is some discussion from \#haskell:
```
06:39 < dancor> do other ppl agree that (threadDelay (-1)) hanging silently is
bug?
06:39 < dancor> i guess you might want infinite hang, hm
06:39 < Cale> dancor: I think I might agree with that, though now that you
mention it, it's very handy.
06:39 < Cale> dancor: A lot of things which would cause a thread to block
forever will throw an exception and kill the thread.
06:40 < Cale> (an exception which you'd often wish were silent)
06:40 < Cale> But threadDelay is the wrong place for that
06:40 < b_jonas> dancor: yeah, the thread should just be garbage-collected
06:42 * quicksilver uses "forever (threadDelay maxBound)"
```
I'm on Debian lenny:
```
~ uname -a
Linux pima 2.6.26-1-686-bigmem #1 SMP Sat Nov 8 19:46:36 UTC 2008 i686 GNU/Linux
~ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
~ cat threadHang.hs
import Control.Concurrent
main = threadDelay (-1)
```7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/2893Implement "Quantified constraints" proposal2019-07-07T19:06:23ZPorgesImplement "Quantified constraints" proposalSee: [Quantifiedconstraintswikipage](quantified-constraints)See: [Quantifiedconstraintswikipage](quantified-constraints)8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/2894Documentation for "even" missing2019-07-07T19:06:23ZNeil MitchellDocumentation for "even" missinghttp://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html
You can find odd, but not even. Probably caused by:
http://trac.haskell.org/haddock/ticket/69
<details><summary>Trac metadata</summary>
| Trac field | Va...http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html
You can find odd, but not even. Probably caused by:
http://trac.haskell.org/haddock/ticket/69
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Documentation for \"even\" missing","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html\r\n\r\nYou can find odd, but not even. Probably caused by:\r\n\r\nhttp://trac.haskell.org/haddock/ticket/69\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/2897HsFFI.h is not in the default include path for hsc2hs2019-07-07T19:06:22ZcjsHsFFI.h is not in the default include path for hsc2hsUsing the ghc 6.1.0 package for libedit2 downloaded from the GHC downloads page, on Ubuntu 8.04.1, attempting to compile an hsc file fails with:
```
In file included from /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_m...Using the ghc 6.1.0 package for libedit2 downloaded from the GHC downloads page, on Ubuntu 8.04.1, attempting to compile an hsc file fails with:
```
In file included from /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c:1:
/usr/local/lib/ghc-6.10.1/hsc2hs-0.67/template-hsc.h:4:19: error: HsFFI.h: No such file or directory
compiling /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c failed
command was: /usr/bin/gcc -c /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c -o /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.o
```
I note that the command does not include a -I option. Either running the command by hand with an appropriate -I option, or setting the environment variable `CPATH=/usr/local/lib/ghc-6.10.1/include` fixes the issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"HsFFI.h not found in include path","status":"New","operating_system":"Linux","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["ffi","hsffi.h","include"],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"Using the ghc 6.1.0 package for libedit2 downloaded from the GHC downloads page, on Ubuntu 8.04.1, attempting to compile an hsc file fails with:\r\n{{{\r\nIn file included from /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c:1:\r\n/usr/local/lib/ghc-6.10.1/hsc2hs-0.67/template-hsc.h:4:19: error: HsFFI.h: No such file or directory\r\ncompiling /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c failed\r\ncommand was: /usr/bin/gcc -c /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c -o /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.o\r\n}}}\r\nI note that the command does not include a -I option. Either running the command by hand with an appropriate -I option, or setting the environment variable {{{CPATH=/usr/local/lib/ghc-6.10.1/include}}} fixes the issue.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2898crash when interpreting2019-07-07T19:06:22Znolraicrash when interpretingwhen I interpret my file Utilities/ChoiceMonad.hs from ghci-haskline I get the following message:
```
[2 of 2][Compiling Utilities.ChoiceMonad ( Utilities/ChoiceMonad.hs, interpreted )
ghci-haskeline: panic! (the 'impossible' happened)
...when I interpret my file Utilities/ChoiceMonad.hs from ghci-haskline I get the following message:
```
[2 of 2][Compiling Utilities.ChoiceMonad ( Utilities/ChoiceMonad.hs, interpreted )
ghci-haskeline: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
ByteCodeGen.schemeE: unhandled case
\ (@ a1{tv a1qQ} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d})
(@ b1{tv a1qR} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d}) ->
case {tick (main:Utilities.ChoiceMonad, 169)}{v d1z7} [gid]
@ (ghc-prim:GHC.Prim.State#{(w) tc 32q}
ghc-prim:GHC.Prim.RealWorld{(w) tc 31E})
{(a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk])
-> main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
m{tv aQH} [sk] a1{tv a1qQ} [sk]
-> main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
m{tv aQH} [sk] b1{tv a1qR} [sk]}
of (tick{v s29j} [lid] :: ghc-prim:GHC.Prim.State#{(w) tc 32q}
ghc-prim:GHC.Prim.RealWorld{(w) tc 31E})
{ __DEFAULT ->
let {
sat_s20H{v} [lid] :: (a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk])
-> main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk]
-> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk]
[]
sat_s20H{v} [lid] =
base:GHC.Base.fmap{v r5G} [gid]
@ main:Utilities.LeafyTree.LeafyTree{tc rfw}
main:Utilities.LeafyTree.$f4{v rfq} [gid]
@ a1{tv a1qQ} [sk]
@ b1{tv a1qR} [sk] } in
let {
sat_s20F{v} [lid] :: (main:Utilities.LeafyTree.LeafyTree{tc rfw}
a1{tv a1qQ} [sk]
-> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk])
-> main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
m{tv aQH} [sk] a1{tv a1qQ} [sk]
-> main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
m{tv aQH} [sk] b1{tv a1qR} [sk]
[]
sat_s20F{v} [lid] =
main:Utilities.ChoiceMonad.inChoiceT{v rLn} [gid]
@ m{tv aQH} [sk]
@ a1{tv a1qQ} [sk]
@ b1{tv a1qR} [sk]
$dMonad1{v s20D} [lid] } in
base:GHC.Base..{v r4k} [gid]
@ (main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk]
-> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk])
@ (main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
m{tv aQH} [sk] a1{tv a1qQ} [sk]
-> main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
m{tv aQH} [sk] b1{tv a1qR} [sk])
@ (a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk])
sat_s20F{v} [lid]
sat_s20H{v} [lid]
}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
but if i do "ghc --make Utilities/ChoiceMonad.hs" that works and I can then load it with ghci-haskline, at least until I modify it and need to compile again.Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2899GADT type inference with existentials2019-07-07T19:06:22ZjochembGADT type inference with existentialsThe following code works in GHC 6.8.2:
```
{-# OPTIONS -fglasgow-exts #-}
module Test where
data Existential = forall a. Ex (GADT a)
data GADT :: * -> * where
GCon :: Int -> GADT ()
-- g :: Existential -> Int
g (Ex (GCon x)) ...The following code works in GHC 6.8.2:
```
{-# OPTIONS -fglasgow-exts #-}
module Test where
data Existential = forall a. Ex (GADT a)
data GADT :: * -> * where
GCon :: Int -> GADT ()
-- g :: Existential -> Int
g (Ex (GCon x)) = x
```
The compiler correctly infers the type of x in the definition of g, and correctly infers the type of g.
In GHC 6.10.1, however, this fails with:
```
Test.hs:10:12:
GADT pattern match with non-rigid result type `t'
Solution: add a type signature
In the definition of `g': g (Ex (GCon x)) = x
Failed, modules loaded: none.
```
The solution, to include the type signature of g (that I have commented out), works, but why can't GHC figure out the type of g? GHC 6.8.2 could!
An equivalent version with a non-GADT instead, works correctly:
```
data GADT a = GCon Int
```
Ticket #2206 might be related.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GADT type inference with existentials","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["GADT,","existential","types"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nThe following code works in GHC 6.8.2:\r\n\r\n{{{\r\n{-# OPTIONS -fglasgow-exts #-}\r\nmodule Test where\r\n\r\ndata Existential = forall a. Ex (GADT a)\r\n\r\ndata GADT :: * -> * where\r\n GCon :: Int -> GADT ()\r\n\r\n-- g :: Existential -> Int\r\ng (Ex (GCon x)) = x\r\n}}}\r\n\r\nThe compiler correctly infers the type of x in the definition of g, and correctly infers the type of g.\r\n\r\nIn GHC 6.10.1, however, this fails with:\r\n{{{\r\nTest.hs:10:12:\r\n GADT pattern match with non-rigid result type `t'\r\n Solution: add a type signature\r\n In the definition of `g': g (Ex (GCon x)) = x\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nThe solution, to include the type signature of g (that I have commented out), works, but why can't GHC figure out the type of g? GHC 6.8.2 could!\r\n\r\nAn equivalent version with a non-GADT instead, works correctly:\r\n{{{\r\ndata GADT a = GCon Int\r\n}}}\r\n\r\nTicket #2206 might be related.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2900Confusing error message for monadic function with wrong number of arguments2019-07-07T19:06:21Zchevalier@alum.wellesley.eduConfusing error message for monadic function with wrong number of argumentsIf I compile the following code:
```
import Control.Monad.State
foo :: MonadIO m => Int -> m ()
foo x y = return ()
```
I get the error message:
```
bug.hs:6:10:
Couldn't match expected type `()' against inferred type `m ()'
...If I compile the following code:
```
import Control.Monad.State
foo :: MonadIO m => Int -> m ()
foo x y = return ()
```
I get the error message:
```
bug.hs:6:10:
Couldn't match expected type `()' against inferred type `m ()'
In the expression: return ()
In the definition of `foo': foo x y = return ()
```
On the other hand, if I change foo's type signature to:
```
foo :: Int -> IO ()
```
I get the more helpful:
```
bug.hs:6:0:
The equation(s) for `foo' have two arguments,
but its type `Int -> IO ()' has only one
```
It would be good if the second error message appeared in the first case as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Confusing error message for monadic function with wrong number of arguments","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I compile the following code:\r\n\r\n{{{\r\nimport Control.Monad.State\r\n\r\nfoo :: MonadIO m => Int -> m ()\r\nfoo x y = return ()\r\n}}}\r\n\r\nI get the error message:\r\n\r\n{{{\r\nbug.hs:6:10:\r\n Couldn't match expected type `()' against inferred type `m ()'\r\n In the expression: return ()\r\n In the definition of `foo': foo x y = return ()\r\n}}}\r\n\r\nOn the other hand, if I change foo's type signature to:\r\n{{{\r\nfoo :: Int -> IO ()\r\n}}}\r\nI get the more helpful:\r\n{{{\r\nbug.hs:6:0:\r\n The equation(s) for `foo' have two arguments,\r\n but its type `Int -> IO ()' has only one\r\n}}}\r\n\r\nIt would be good if the second error message appeared in the first case as well.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2901GHC crashes with "impossible happened ... RnEnv.lookupImportedName" if using ...2019-07-07T19:06:21ZspookylukeyGHC crashes with "impossible happened ... RnEnv.lookupImportedName" if using DisambiguateRecordFields and qualifiersIf you specify DisambiguateRecordFields as an option, and then try to use qualifiers for field names in a data constructor, GHC crashes like this:
```
ghc-6.8.2: panic! (the 'impossible' happened)
(GHC version 6.8.2 for i386-unknown-l...If you specify DisambiguateRecordFields as an option, and then try to use qualifiers for field names in a data constructor, GHC crashes like this:
```
ghc-6.8.2: panic! (the 'impossible' happened)
(GHC version 6.8.2 for i386-unknown-linux):
RnEnv.lookupImportedName F.field{v}
```
See attached files for example -- simply do 'ghci Main.hs' to see the bug.
This bug means that if you use field disambiguation in part of a module, you have to use it everywhere in that module.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.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":"GHC crashes with \"impossible happened ... RnEnv.lookupImportedName\" if using DisambiguateRecordFields and qualifiers","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you specify DisambiguateRecordFields as an option, and then try to use qualifiers for field names in a data constructor, GHC crashes like this:\r\n\r\n{{{\r\nghc-6.8.2: panic! (the 'impossible' happened)\r\n (GHC version 6.8.2 for i386-unknown-linux):\r\n RnEnv.lookupImportedName F.field{v}\r\n}}}\r\n\r\nSee attached files for example -- simply do 'ghci Main.hs' to see the bug.\r\n\r\nThis bug means that if you use field disambiguation in part of a module, you have to use it everywhere in that module.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2902Example where ghc 6.10.1 fails to optimize recursive instance function calls2019-07-07T19:06:21ZSyzygiesExample where ghc 6.10.1 fails to optimize recursive instance function callsUsing ghc 6.10.1, I get over a 3x performance boost on the attached toy example, by moving instance function definitions out of the instance declaration, so that recursive calls avoid the class dictionary.
According to SPJ, ghc 6.10.1 i...Using ghc 6.10.1, I get over a 3x performance boost on the attached toy example, by moving instance function definitions out of the instance declaration, so that recursive calls avoid the class dictionary.
According to SPJ, ghc 6.10.1 is supposed to perform this optimization automatically. I am reporting it as a bug at his request, following a discussion on the glasgow-haskell-users\@haskell.org list.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Example where ghc 6.10.1 fails to optimize recursive instance function calls","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["class","instance"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using ghc 6.10.1, I get over a 3x performance boost on the attached toy example, by moving instance function definitions out of the instance declaration, so that recursive calls avoid the class dictionary.\r\n\r\nAccording to SPJ, ghc 6.10.1 is supposed to perform this optimization automatically. I am reporting it as a bug at his request, following a discussion on the glasgow-haskell-users@haskell.org list.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2903Incorrect length for CWStringLen on Win322019-07-07T19:06:21ZasklingeIncorrect length for CWStringLen on Win32The functions newCWStringLen and withCWStringLen return a CWStringLen with incorrect length on Win32 platform. The length returned is the length of the original Haskell String, but it should be the length of the UTF-16 encoded string (wh...The functions newCWStringLen and withCWStringLen return a CWStringLen with incorrect length on Win32 platform. The length returned is the length of the original Haskell String, but it should be the length of the UTF-16 encoded string (which may be longer if the original string contained any code points \> 0xFFFF).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect length for CWStringLen on Win32","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The functions newCWStringLen and withCWStringLen return a CWStringLen with incorrect length on Win32 platform. The length returned is the length of the original Haskell String, but it should be the length of the UTF-16 encoded string (which may be longer if the original string contained any code points > 0xFFFF).","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/2904Broken pipe when quitting "ghc --show-iface file.hi | less"2019-07-07T19:06:20ZSyzygiesBroken pipe when quitting "ghc --show-iface file.hi | less"Here is an example of a very minor rough edge in ghc:
```
% ghc --show-iface Matrix.hi | less
ghc: <stdout>: hFlush: resource vanished (Broken pipe)
```
If one quits *less* before reading all the output (a likely scenario), one sees th...Here is an example of a very minor rough edge in ghc:
```
% ghc --show-iface Matrix.hi | less
ghc: <stdout>: hFlush: resource vanished (Broken pipe)
```
If one quits *less* before reading all the output (a likely scenario), one sees this predictable error message.
I'd argue that one should suppress this message, so users learn to pay attention to the messages they do see.
A work-around is
```
% ghc --show-iface Matrix.hi 2> /dev/null | less
```
but this suppresses other messages one might want to see. My attempts at a more precise work-around get me into "damned if you do, damned if you don't" territory. For example,
```
% (ghc --show-iface Matrix.hi 2| grep -v 'Broken') | less
```
doesn't work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Broken pipe when quitting \"ghc --show-iface file.hi | less\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is an example of a very minor rough edge in ghc:\r\n{{{\r\n% ghc --show-iface Matrix.hi | less\r\nghc: <stdout>: hFlush: resource vanished (Broken pipe)\r\n}}}\r\nIf one quits ''less'' before reading all the output (a likely scenario), one sees this predictable error message.\r\n\r\nI'd argue that one should suppress this message, so users learn to pay attention to the messages they do see.\r\n\r\nA work-around is\r\n{{{\r\n% ghc --show-iface Matrix.hi 2> /dev/null | less\r\n}}}\r\nbut this suppresses other messages one might want to see. My attempts at a more precise work-around get me into \"damned if you do, damned if you don't\" territory. For example,\r\n{{{\r\n% (ghc --show-iface Matrix.hi 2| grep -v 'Broken') | less\r\n}}}\r\ndoesn't work.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2906.hc code generated for Parser.hs is 2MB big2019-07-07T19:06:20Zbenl.hc code generated for Parser.hs is 2MB bigWhen compiling GHC 6.10.1 with GHC 6.8.3 on the SPARC T2, the intermediate C code emitted for Parser.hs is a bit over 2MB (that's megabytes) big. GCC 4.2.1 then takes over 2 hrs to compile this single source file.
<details><summary>Trac...When compiling GHC 6.10.1 with GHC 6.8.3 on the SPARC T2, the intermediate C code emitted for Parser.hs is a bit over 2MB (that's megabytes) big. GCC 4.2.1 then takes over 2 hrs to compile this single source file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| 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":".hc code generated for Parser.hs is 2MB big","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling GHC 6.10.1 with GHC 6.8.3 on the SPARC T2, the intermediate C code emitted for Parser.hs is a bit over 2MB (that's megabytes) big. GCC 4.2.1 then takes over 2 hrs to compile this single source file.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2907generalized newtype deriving not working with polymorphic component2019-07-07T19:06:20ZWolfgang Jeltschgeneralized newtype deriving not working with polymorphic componentI’d like generalized newtype deriving to work also with polymorphic components like in this example:
```
{-# LANGUAGE GeneralizedNewtypeDeriving, RankNTypes #-}
import Control.Monad.Cont
newtype PolyContT monad o = PolyContT (forall r...I’d like generalized newtype deriving to work also with polymorphic components like in this example:
```
{-# LANGUAGE GeneralizedNewtypeDeriving, RankNTypes #-}
import Control.Monad.Cont
newtype PolyContT monad o = PolyContT (forall result. ContT result monad o)
deriving (Monad)
```
Would this be possible?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"generalized newtype deriving not working with polymorphic component","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I’d like generalized newtype deriving to work also with polymorphic components like in this example:\r\n{{{\r\n{-# LANGUAGE GeneralizedNewtypeDeriving, RankNTypes #-}\r\n\r\nimport Control.Monad.Cont\r\n\r\nnewtype PolyContT monad o = PolyContT (forall result. ContT result monad o)\r\n deriving (Monad)\r\n}}}\r\nWould this be possible?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2908typo "reqwest" in documentation2019-07-07T19:06:19Zbancrofttypo "reqwest" in documentationWhile reading through the documentation for base-4.0.0.0: Basic libraries, Control Concurrent,
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html
I noticed a slightly manged "reqwest" in the paragraph,...While reading through the documentation for base-4.0.0.0: Basic libraries, Control Concurrent,
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html
I noticed a slightly manged "reqwest" in the paragraph,
> "The System.IO library manages multiplexing in its own way. On Windows systems it uses safe foreign calls to ensure that threads doing I/O operations don't block the whole runtime, whereas on Unix systems all the currently blocked I/O ***reqwests*** are managed by a single thread (the IO manager thread) using select."
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"typo \"reqwest\" in documentation","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While reading through the documentation for base-4.0.0.0: Basic libraries, Control Concurrent,\r\n\r\n http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html\r\n\r\nI noticed a slightly manged \"reqwest\" in the paragraph,\r\n\r\n \"The System.IO library manages multiplexing in its own way. On Windows systems it uses safe foreign calls to ensure that threads doing I/O operations don't block the whole runtime, whereas on Unix systems all the currently blocked I/O '''''reqwests''''' are managed by a single thread (the IO manager thread) using select.\"\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2909long list of names -> linkBCO: >= 64k insns in BCO2019-07-07T19:06:19Zjowenslong list of names -> linkBCO: >= 64k insns in BCODoing Project Euler 22. Simple program, gives me:
classico 9679$ runghc 22.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
> linkBCO: \>= 64k insns in BCO
Please report this as a GHC bug: http...Doing Project Euler 22. Simple program, gives me:
classico 9679$ runghc 22.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
> linkBCO: \>= 64k insns in BCO
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Attached as 22.hs.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"long list of names -> linkBCO: >= 64k insns in BCO","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Doing Project Euler 22. Simple program, gives me:\r\n\r\nclassico 9679$ runghc 22.hs \r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n linkBCO: >= 64k insns in BCO\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nAttached as 22.hs.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2910throwTo can block indefinitely when target thread finishes with exceptions bl...2019-07-07T19:06:19ZBertram FelgenhauerthrowTo can block indefinitely when target thread finishes with exceptions blocked`throwTo` can block indefinitely when the target thread has exceptions blocked at thread creation time. The following test program demonstrates this problem.
```
import Control.Exception
import GHC.Conc
main = do
t1 <- block $ fo...`throwTo` can block indefinitely when the target thread has exceptions blocked at thread creation time. The following test program demonstrates this problem.
```
import Control.Exception
import GHC.Conc
main = do
t1 <- block $ forkIO yield
t2 <- forkIO $ killThread t1
threadDelay 1000000
threadStatus t1 >>= print
threadStatus t2 >>= print
```
can print (and does fairly reliably for me)
```
ThreadFinished
ThreadBlocked BlockedOnException
```
See also http://www.haskell.org/pipermail/reactive/2009-January/000197.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"throwTo can block indefinitely when target thread finishes with exceptions blocked","status":"New","operating_system":"Linux","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"{{{throwTo}}} can block indefinitely when the target thread has exceptions blocked at thread creation time. The following test program demonstrates this problem.\r\n\r\n{{{\r\nimport Control.Exception\r\nimport GHC.Conc\r\n \r\nmain = do\r\n t1 <- block $ forkIO yield\r\n t2 <- forkIO $ killThread t1\r\n threadDelay 1000000\r\n threadStatus t1 >>= print\r\n threadStatus t2 >>= print\r\n}}}\r\ncan print (and does fairly reliably for me)\r\n{{{\r\nThreadFinished\r\nThreadBlocked BlockedOnException\r\n}}}\r\nSee also http://www.haskell.org/pipermail/reactive/2009-January/000197.html","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2911Error messages have the wrong qualified names2019-07-07T19:06:19ZIan Lynagh <igloo@earth.li>Error messages have the wrong qualified namesThis module:
```
module Foo where
import Data.ByteString.Lazy (ByteString)
import qualified Data.ByteString.Lazy as BS
import qualified Data.ByteString.Lazy.Char8 as BSC
check :: ByteString -> Bool
check bs = BS.empty bs
```
produces...This module:
```
module Foo where
import Data.ByteString.Lazy (ByteString)
import qualified Data.ByteString.Lazy as BS
import qualified Data.ByteString.Lazy.Char8 as BSC
check :: ByteString -> Bool
check bs = BS.empty bs
```
produces this type error:
```
$ ghci -v0 q.hs
q.hs:9:11:
Couldn't match expected type `ByteString -> Bool'
against inferred type `ByteString'
In the expression: BSC.empty bs
In the definition of `check': check bs = BSC.empty bs
```
i.e. it claims that the expression is `BSC.empty bs`, whereas the program text says `BS.empty bs`.
Similarly, in this module:
```
module Foo where
import Data.ByteString.Lazy (ByteString)
import qualified Data.ByteString.Lazy as BS
import Data.ByteString.Lazy.Char8
check :: ByteString -> Bool
check bs = BS.empty bs
```
the qualifier has disappeared completely in the error message:
```
$ ghci -v0 q.hs
q.hs:9:11:
Couldn't match expected type `ByteString -> Bool'
against inferred type `ByteString'
In the expression: empty bs
In the definition of `check': check bs = empty bs
Prelude>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"Error messages have the wrong qualified names","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This module:\r\n{{{\r\nmodule Foo where\r\n\r\nimport Data.ByteString.Lazy (ByteString)\r\nimport qualified Data.ByteString.Lazy as BS\r\nimport qualified Data.ByteString.Lazy.Char8 as BSC\r\n\r\ncheck :: ByteString -> Bool\r\ncheck bs = BS.empty bs\r\n}}}\r\nproduces this type error:\r\n{{{\r\n$ ghci -v0 q.hs\r\n\r\nq.hs:9:11:\r\n Couldn't match expected type `ByteString -> Bool'\r\n against inferred type `ByteString'\r\n In the expression: BSC.empty bs\r\n In the definition of `check': check bs = BSC.empty bs\r\n}}}\r\ni.e. it claims that the expression is `BSC.empty bs`, whereas the program text says `BS.empty bs`.\r\n\r\nSimilarly, in this module:\r\n{{{\r\nmodule Foo where\r\n\r\nimport Data.ByteString.Lazy (ByteString)\r\nimport qualified Data.ByteString.Lazy as BS\r\nimport Data.ByteString.Lazy.Char8\r\n\r\ncheck :: ByteString -> Bool\r\ncheck bs = BS.empty bs\r\n}}}\r\nthe qualifier has disappeared completely in the error message:\r\n{{{\r\n$ ghci -v0 q.hs\r\n\r\nq.hs:9:11:\r\n Couldn't match expected type `ByteString -> Bool'\r\n against inferred type `ByteString'\r\n In the expression: empty bs\r\n In the definition of `check': check bs = empty bs\r\nPrelude> \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/2912GHCi bug: bus error when executing some gsl-random code2019-07-07T19:06:18ZfdeweerdtGHCi bug: bus error when executing some gsl-random codeWhen compiling this simple program, the resulting executable runs fine, while running it under ghci causes a crash.
It's gsl-random related obviously, but the difference in behaviour between plain ghc and ghci is somewhat odd.
```
$ cat...When compiling this simple program, the resulting executable runs fine, while running it under ghci causes a crash.
It's gsl-random related obviously, but the difference in behaviour between plain ghc and ghci is somewhat odd.
```
$ cat a.hs
import Control.Monad
import Control.Monad.MC
import Control.Monad.MC.Class
import GHC.Word
seed = 57
buildRow el l = (sampleSubset el l [1..]) `evalMC` (mt19937 seed)
main = do
mapM_ putStrLn (map show ((buildRow 2 10) :: [Double]))
$ ghc --make a.hs
[1 of 1] Compiling Main ( a.hs, a.o )
Linking a ...
$ ./a
1.0
6.0
$ ghci a.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Ok, modules loaded: Main.
Prelude Main> main
Loading package syb ... linking ... done.
Loading package base-3.0.3.0 ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package gsl-random-0.2.3 ... linking ... done.
Loading package uvector-0.1.0.3 ... linking ... done.
Loading package monte-carlo-0.2 ... linking ... done.
zsh: bus error ghci a.hs
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| 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 bug: bus error when executing some gsl-random core","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling this simple program, the resulting executable runs fine, while running it under ghci causes a crash.\r\nIt's gsl-random related obviously, but the difference in behaviour between plain ghc and ghci is somewhat odd.\r\n\r\n{{{\r\n$ cat a.hs\r\nimport Control.Monad\r\nimport Control.Monad.MC\r\nimport Control.Monad.MC.Class\r\nimport GHC.Word\r\n\r\nseed = 57\r\nbuildRow el l = (sampleSubset el l [1..]) `evalMC` (mt19937 seed)\r\n\r\nmain = do\r\n mapM_ putStrLn (map show ((buildRow 2 10) :: [Double]))\r\n\r\n$ ghc --make a.hs\r\n[1 of 1] Compiling Main ( a.hs, a.o )\r\nLinking a ...\r\n$ ./a \r\n1.0\r\n6.0\r\n$ ghci a.hs \r\nGHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\nOk, modules loaded: Main.\r\nPrelude Main> main\r\nLoading package syb ... linking ... done.\r\nLoading package base-3.0.3.0 ... linking ... done.\r\nLoading package array-0.2.0.0 ... linking ... done.\r\nLoading package mtl-1.1.0.2 ... linking ... done.\r\nLoading package gsl-random-0.2.3 ... linking ... done.\r\nLoading package uvector-0.1.0.3 ... linking ... done.\r\nLoading package monte-carlo-0.2 ... linking ... done.\r\nzsh: bus error ghci a.hs\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/2913OldException's catch etc should treat new Exception types as DynException's2019-07-07T19:06:18ZIan Lynagh <igloo@earth.li>OldException's catch etc should treat new Exception types as DynException's`OldException`'s catch etc should treat new `Exception` types as `DynException`'s. Currently new style exceptions are just not caught, which is a bug. It also means that cleaning up with functions like `finally` doesn't work properly.
A...`OldException`'s catch etc should treat new `Exception` types as `DynException`'s. Currently new style exceptions are just not caught, which is a bug. It also means that cleaning up with functions like `finally` doesn't work properly.
Additionally, functions like `bracket`, `onException`, `finally` which don't actually exposed the exception type could just use the new functions directly, rather than reimplementing them.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"OldException's catch etc should treat new Exception types as DynException's","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"6.10.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`OldException`'s catch etc should treat new `Exception` types as `DynException`'s. Currently new style exceptions are just not caught, which is a bug. It also means that cleaning up with functions like `finally` doesn't work properly.\r\n\r\nAdditionally, functions like `bracket`, `onException`, `finally` which don't actually exposed the exception type could just use the new functions directly, rather than reimplementing them.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2914RecordWildCards doesn't work with associated datatypes inside class instances2019-07-07T19:06:18ZganeshRecordWildCards doesn't work with associated datatypes inside class instancesIt seems like record wildcards (the ".." notation) don't work in the following scenario.
I tried with a standalone associated datatype and it works fine.
Tested with 6.10.1 and 6.11.20090103.
```
{-# LANGUAGE TypeFamilies, RecordWildC...It seems like record wildcards (the ".." notation) don't work in the following scenario.
I tried with a standalone associated datatype and it works fine.
Tested with 6.10.1 and 6.11.20090103.
```
{-# LANGUAGE TypeFamilies, RecordWildCards #-}
module AssocWildCards where
class FooClass a where
data FooType a
instance FooClass Int where
data FooType Int = FooInt { fooIntVal :: Int }
fooInt :: Int -> FooType Int
fooInt fooIntVal = FooInt{..}
fromFooInt :: FooType Int -> Int
fromFooInt FooInt{..} = fooIntVal
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ganesh.sittampalam@credit-suisse.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"RecordWildCards doesn't work with associated datatypes inside class instances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ganesh.sittampalam@credit-suisse.com"],"type":"Bug","description":"It seems like record wildcards (the \"..\" notation) don't work in the following scenario.\r\n\r\nI tried with a standalone associated datatype and it works fine.\r\n\r\nTested with 6.10.1 and 6.11.20090103.\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies, RecordWildCards #-}\r\nmodule AssocWildCards where\r\n\r\nclass FooClass a where\r\n data FooType a\r\n\r\ninstance FooClass Int where\r\n data FooType Int = FooInt { fooIntVal :: Int }\r\n\r\nfooInt :: Int -> FooType Int\r\nfooInt fooIntVal = FooInt{..}\r\n\r\nfromFooInt :: FooType Int -> Int\r\nfromFooInt FooInt{..} = fooIntVal\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2915Arity is smaller than need be2020-02-26T21:25:31ZSimon Peyton JonesArity is smaller than need beConsider
```
h x = let f = case x of { True -> t1; False -> t2 }
in (f,f)
```
where `t1` and `t2` have arity 1. You'd think that `f` should have arity 1, but it doesn't. (Reason: `exprArity`, used in `Simplify.addNonRecWithUn...Consider
```
h x = let f = case x of { True -> t1; False -> t2 }
in (f,f)
```
where `t1` and `t2` have arity 1. You'd think that `f` should have arity 1, but it doesn't. (Reason: `exprArity`, used in `Simplify.addNonRecWithUnf`, doesn't look through the case.)
Fix this as part of the upcoming arity cleanup.
Simon
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Arity is smaller than need be","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider \r\n{{{\r\nh x = let f = case x of { True -> t1; False -> t2 }\r\n in (f,f)\r\n}}}\r\nwhere `t1` and `t2` have arity 1. You'd think that `f` should have arity 1, but it doesn't. (Reason: `exprArity`, used in `Simplify.addNonRecWithUnf`, doesn't look through the case.)\r\n\r\nFix this as part of the upcoming arity cleanup.\r\n\r\nSimon","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/2916Adding "-auto-all" when using "-O2 -prof" causes "<<loop>>"2019-07-07T19:06:17ZBenMoseleyAdding "-auto-all" when using "-O2 -prof" causes "<<loop>>"The program below works fine (and outputs "ZeroPmt") when compiled with "-O2 -prof -fno-cse", but when you add in "-auto-all" it causes "\<\<loop\>\>".
There are many ways to workaround the problem, uncommenting pretty much any of the c...The program below works fine (and outputs "ZeroPmt") when compiled with "-O2 -prof -fno-cse", but when you add in "-auto-all" it causes "\<\<loop\>\>".
There are many ways to workaround the problem, uncommenting pretty much any of the commented-out lines avoids the issue, but my impression is that adding "-auto-all" shouldn't cause this.
This is with stock 6.10.1. "-dcore-lint" has no effect.
```
--
-- Compile with : ghc -O2 -prof -auto-all -fno-cse --make ~/loop.hs
--
-- ...and it breaks, outputting <<loop>>
-- ...compile without "-auto-all" and you get ZeroPmt
--
import Data.IORef
import qualified Data.Map as Map
import System.IO
import System.IO.Unsafe
import System.Mem.StableName
main :: IO ()
main = do
-- putStrLn $ show $ unHC $ mkHC ZeroPmt -- Works OK
putStrLn $ show $ unHC $ mkHC $ unHC $ mkHC ZeroPmt
data Expr = Add | ZeroPmt deriving (Ord, Eq, Show)
data ExprHC = ExprHC { unStableName :: !(StableName Expr), unHC ::
!Expr} deriving (Eq)
-- {-# NOINLINE mkHC #-} -- Works OK
-- mkHC e = hashConser e -- Works OK
mkHC = hashConser
{-# NOINLINE hashConser #-}
hashConser :: Expr -> ExprHC
hashConser e = deepSeq e (unsafePerformIO $ mkHC' e)
-- hashConser e = seq (e == e) (unsafePerformIO $ mkHC' e)
where
refTbl = unsafePerformIO $ newIORef Map.empty
mkHC' e = do
tbl <- readIORef refTbl
case Map.lookup e tbl of
Just ehc -> return ehc
Nothing -> do
sn <- makeStableName e
let ehc = ExprHC sn e
writeIORef refTbl $ Map.insert e ehc tbl
return ehc
deepSeq :: Eq e => e -> x -> x
deepSeq e x = seq (e == e) x
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ben@moseley.name |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Adding \"-auto-all\" when using \"-O2 -prof\" causes \"<<loop>>\"","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["auto-all","loop"],"differentials":[],"test_case":"","architecture":"","cc":["ben@moseley.name"],"type":"Bug","description":"The program below works fine (and outputs \"ZeroPmt\") when compiled with \"-O2 -prof -fno-cse\", but when you add in \"-auto-all\" it causes \"<<loop>>\".\r\n\r\nThere are many ways to workaround the problem, uncommenting pretty much any of the commented-out lines avoids the issue, but my impression is that adding \"-auto-all\" shouldn't cause this.\r\n\r\nThis is with stock 6.10.1. \"-dcore-lint\" has no effect.\r\n\r\n{{{\r\n--\r\n-- Compile with : ghc -O2 -prof -auto-all -fno-cse --make ~/loop.hs\r\n--\r\n-- ...and it breaks, outputting <<loop>>\r\n-- ...compile without \"-auto-all\" and you get ZeroPmt\r\n--\r\nimport Data.IORef\r\nimport qualified Data.Map as Map\r\nimport System.IO\r\nimport System.IO.Unsafe\r\nimport System.Mem.StableName\r\n\r\nmain :: IO ()\r\nmain = do\r\n\r\n -- putStrLn $ show $ unHC $ mkHC ZeroPmt -- Works OK\r\n putStrLn $ show $ unHC $ mkHC $ unHC $ mkHC ZeroPmt\r\n\r\ndata Expr = Add | ZeroPmt deriving (Ord, Eq, Show)\r\ndata ExprHC = ExprHC { unStableName :: !(StableName Expr), unHC ::\r\n!Expr} deriving (Eq)\r\n\r\n-- {-# NOINLINE mkHC #-} -- Works OK\r\n-- mkHC e = hashConser e -- Works OK\r\nmkHC = hashConser\r\n\r\n{-# NOINLINE hashConser #-}\r\nhashConser :: Expr -> ExprHC\r\nhashConser e = deepSeq e (unsafePerformIO $ mkHC' e)\r\n-- hashConser e = seq (e == e) (unsafePerformIO $ mkHC' e)\r\n where\r\n refTbl = unsafePerformIO $ newIORef Map.empty\r\n\r\n mkHC' e = do\r\n tbl <- readIORef refTbl\r\n case Map.lookup e tbl of\r\n Just ehc -> return ehc\r\n Nothing -> do\r\n sn <- makeStableName e\r\n let ehc = ExprHC sn e\r\n writeIORef refTbl $ Map.insert e ehc tbl\r\n return ehc\r\n\r\ndeepSeq :: Eq e => e -> x -> x\r\ndeepSeq e x = seq (e == e) x\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/2917alloca and allocaArray do not respect alignment2019-07-07T19:06:17Zguestalloca and allocaArray do not respect alignmentWhen allocating memory with alloca or allocaArray the alignment of the Storable is not respected, alignment seems to be on 8 byte boundary. malloc and mallocArray seem to have the same problem. And because of this functions like withArra...When allocating memory with alloca or allocaArray the alignment of the Storable is not respected, alignment seems to be on 8 byte boundary. malloc and mallocArray seem to have the same problem. And because of this functions like withArray etc also break the alignment restriction of the array element.
Run this and look at the pointer.
```
import Foreign.Ptr
import Foreign.Storable
import Foreign.Marshal.Array
import Foreign.Marshal
data Foo = Foo
instance Storable Foo where
sizeOf _ = 8
alignment _ = 256
main =
allocaArray 5 $ \ p -> do
let _ = p :: Ptr Foo
print p
q <- mallocArray 5
let _ = q :: Ptr Foo
print q
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"alloca and allocaArray do not respect alignment","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":["lennart@augustsson.net"],"type":"Bug","description":"When allocating memory with alloca or allocaArray the alignment of the Storable is not respected, alignment seems to be on 8 byte boundary. malloc and mallocArray seem to have the same problem. And because of this functions like withArray etc also break the alignment restriction of the array element.\r\n\r\nRun this and look at the pointer.\r\n{{{\r\nimport Foreign.Ptr\r\nimport Foreign.Storable\r\nimport Foreign.Marshal.Array\r\nimport Foreign.Marshal\r\n\r\ndata Foo = Foo\r\n\r\ninstance Storable Foo where\r\n sizeOf _ = 8\r\n alignment _ = 256\r\n\r\nmain =\r\n allocaArray 5 $ \\ p -> do\r\n let _ = p :: Ptr Foo\r\n print p\r\n q <- mallocArray 5\r\n let _ = q :: Ptr Foo\r\n print q\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2918Storable alignment for Double is 42019-07-07T19:06:17ZguestStorable alignment for Double is 4The alignment for Double is 4. This makes little sense, it should be 8. That's the alignment that guarantees best performance, and is also necessary on some architectures.
(On x86 a Double can be byte align, so any value from 1 and up wo...The alignment for Double is 4. This makes little sense, it should be 8. That's the alignment that guarantees best performance, and is also necessary on some architectures.
(On x86 a Double can be byte align, so any value from 1 and up works for the alignment, but 8 is the natural one.)
```
import Foreign.Storable
main = print (alignment (0::Double))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Storable alignment for Double is 4","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart@augustsson.net"],"type":"Bug","description":"The alignment for Double is 4. This makes little sense, it should be 8. That's the alignment that guarantees best performance, and is also necessary on some architectures.\r\n(On x86 a Double can be byte align, so any value from 1 and up works for the alignment, but 8 is the natural one.)\r\n\r\n{{{\r\nimport Foreign.Storable\r\n\r\nmain = print (alignment (0::Double))\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/2919ghc panic while compiling Crypto2019-07-07T19:06:17Zwchoggghc panic while compiling CryptoWhile compiling the Crypto 4.1.0 library from hackage I received the following error
\[4 of 4\] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i3...While compiling the Crypto 4.1.0 library from hackage I received the following error
\[4 of 4\] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
> RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
What more information will be useful?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"ghc panic while compiling Crypto","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While compiling the Crypto 4.1.0 library from hackage I received the following error\r\n\r\n[4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-unknown-linux):\r\n RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nWhat more information will be useful?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2920old-time on hackage is incorrectly packaged2019-07-07T19:06:17Zdonsold-time on hackage is incorrectly packagedold-time is missing its ./configure script:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/old-time
```
$ tar xzf old-time-1.0.0.0.tar.gz
$ cd old-time-1.0.0.0
$ ls
LICENSE Setup.hs System cbits include old-time.cabal...old-time is missing its ./configure script:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/old-time
```
$ tar xzf old-time-1.0.0.0.tar.gz
$ cd old-time-1.0.0.0
$ ls
LICENSE Setup.hs System cbits include old-time.cabal
```
It needs:
```
$ cd ghc/libraries/old-time
$ ls
LICENSE System aclocal.m4 cbits configure.ac old-time.cabal
Setup.hs _darcs autom4te.cache configure include prologue.t
```
i.e. its ./configure script.
This leads to cabal install failures, for example
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/old-time |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"old-time on hackage is incorrectly packaged","status":"New","operating_system":"","component":"libraries/old-time","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"old-time is missing its ./configure script:\r\n\r\nhttp://hackage.haskell.org/cgi-bin/hackage-scripts/package/old-time\r\n\r\n{{{\r\n$ tar xzf old-time-1.0.0.0.tar.gz \r\n$ cd old-time-1.0.0.0\r\n$ ls\r\nLICENSE Setup.hs System cbits include old-time.cabal\r\n}}}\r\n\r\nIt needs:\r\n\r\n{{{\r\n$ cd ghc/libraries/old-time \r\n$ ls\r\nLICENSE System aclocal.m4 cbits configure.ac old-time.cabal\r\nSetup.hs _darcs autom4te.cache configure include prologue.t\r\n}}}\r\n\r\ni.e. its ./configure script.\r\n\r\nThis leads to cabal install failures, for example","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2921__GLASGOW_HASKELL__ undefined2019-07-07T19:06:16Zguest__GLASGOW_HASKELL__ undefinedAfter manually forcing adding HsFFI.h to the search path of hsc2hs -- which is also broken, as reported in another bug -- __GLASGOW_HASKELL__ still seems to be undefined, breaking detections.
<details><summary>Trac metadata</summary>
|...After manually forcing adding HsFFI.h to the search path of hsc2hs -- which is also broken, as reported in another bug -- __GLASGOW_HASKELL__ still seems to be undefined, breaking detections.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"__GLASGOW_HASKELL__ undefined","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"After manually forcing adding HsFFI.h to the search path of hsc2hs -- which is also broken, as reported in another bug -- __GLASGOW_HASKELL__ still seems to be undefined, breaking detections.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2922GHC panic: Non-exhaustive patterns in function printTarget2019-07-07T19:06:16ZmatthijsGHC panic: Non-exhaustive patterns in function printTargetWhen running ghci or ghc on Translator.hs (given below) and running it, they crash with a panic.
```
$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
$ ghci -package ghc Translator.hs
GHCi, version 6.10....When running ghci or ghc on Translator.hs (given below) and running it, they crash with a panic.
```
$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
$ ghci -package ghc Translator.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package syb ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package containers-0.2.0.0 ... linking ... done.
Loading package filepath-1.1.0.1 ... linking ... done.
Loading package old-locale-1.0.0.1 ... linking ... done.
Loading package old-time-1.0.0.1 ... linking ... done.
Loading package unix-2.3.1.0 ... linking ... done.
Loading package directory-1.0.0.2 ... linking ... done.
Loading package pretty-1.0.1.0 ... linking ... done.
Loading package process-1.0.1.0 ... linking ... done.
Loading package Cabal-1.6.0.1 ... linking ... done.
Loading package bytestring-0.9.1.4 ... linking ... done.
Loading package editline-0.2.1.0 ... linking ... done.
Loading package random-1.0.0.1 ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package hpc-0.5.0.2 ... linking ... done.
Loading package packedstring-0.1.0.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package ghc-6.10.1 ... linking ... done.
[1 of 1] Compiling Main ( Translator.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package ghc-paths-0.1.0.5 ... linking ... done.
<interactive>: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
Translator.hs:(20,0)-(21,16): Non-exhaustive patterns in function printTarget
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*** Exception: ExitFailure 1
*Main>
```
and ghc:
```
$ ghc -L/usr/local/ghc-6.10.1/lib/ghc-paths-0.1.0.5/ghc-6.10.1 -lHSghc-paths-0.1.0.5 -package ghc Translator.hs
$ ./a.out
a.out: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
Translator.hs:(20,0)-(21,16): Non-exhaustive patterns in function printTarget
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The file is based on the GHC as a library example and tries to extract some data from a Target, which fails. It can probably be reduced somewhat, but I'm still too much stumbling around to effecitvely do this. The file that's being compiled ("noexist.hs" in the file) need not exist, but results are not any different when it does.
Here's Translator.hs:
```
module Main(main) where
import GHC
import MonadUtils ( liftIO )
import Outputable ( showSDoc, ppr )
import GHC.Paths ( libdir )
import DynFlags ( defaultDynFlags )
main =
do
defaultErrorHandler defaultDynFlags $ do
runGhc (Just libdir) $ do
dflags <- getSessionDynFlags
setSessionDynFlags dflags
target <- guessTarget "noexist.hs" Nothing
--liftIO (print (showSDoc (ppr (target))))
liftIO $ printTarget target
setTargets [target]
load LoadAllTargets
printTarget (Target id obj (Just (buf, time))) =
print $ show buf
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| 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":"GHC panic: Non-exhaustive patterns in function printTarget","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When running ghci or ghc on Translator.hs (given below) and running it, they crash with a panic.\r\n\r\n{{{\r\n$ ghci --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.1\r\n$ ghci -package ghc Translator.hs \r\nGHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package syb ... linking ... done.\r\nLoading package array-0.2.0.0 ... linking ... done.\r\nLoading package containers-0.2.0.0 ... linking ... done.\r\nLoading package filepath-1.1.0.1 ... linking ... done.\r\nLoading package old-locale-1.0.0.1 ... linking ... done.\r\nLoading package old-time-1.0.0.1 ... linking ... done.\r\nLoading package unix-2.3.1.0 ... linking ... done.\r\nLoading package directory-1.0.0.2 ... linking ... done.\r\nLoading package pretty-1.0.1.0 ... linking ... done.\r\nLoading package process-1.0.1.0 ... linking ... done.\r\nLoading package Cabal-1.6.0.1 ... linking ... done.\r\nLoading package bytestring-0.9.1.4 ... linking ... done.\r\nLoading package editline-0.2.1.0 ... linking ... done.\r\nLoading package random-1.0.0.1 ... linking ... done.\r\nLoading package haskell98 ... linking ... done.\r\nLoading package hpc-0.5.0.2 ... linking ... done.\r\nLoading package packedstring-0.1.0.1 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\nLoading package ghc-6.10.1 ... linking ... done.\r\n[1 of 1] Compiling Main ( Translator.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> main\r\nLoading package ghc-paths-0.1.0.5 ... linking ... done.\r\n<interactive>: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-unknown-linux):\r\n Translator.hs:(20,0)-(21,16): Non-exhaustive patterns in function printTarget\r\n\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n*** Exception: ExitFailure 1\r\n*Main>\r\n}}}\r\n\r\nand ghc:\r\n{{{\r\n$ ghc -L/usr/local/ghc-6.10.1/lib/ghc-paths-0.1.0.5/ghc-6.10.1 -lHSghc-paths-0.1.0.5 -package ghc Translator.hs\r\n$ ./a.out \r\na.out: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-unknown-linux):\r\n Translator.hs:(20,0)-(21,16): Non-exhaustive patterns in function printTarget\r\n\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe file is based on the GHC as a library example and tries to extract some data from a Target, which fails. It can probably be reduced somewhat, but I'm still too much stumbling around to effecitvely do this. The file that's being compiled (\"noexist.hs\" in the file) need not exist, but results are not any different when it does.\r\n\r\nHere's Translator.hs:\r\n{{{\r\nmodule Main(main) where\r\nimport GHC\r\nimport MonadUtils ( liftIO )\r\nimport Outputable ( showSDoc, ppr )\r\nimport GHC.Paths ( libdir )\r\nimport DynFlags ( defaultDynFlags )\r\n \r\nmain = \r\n do\r\n defaultErrorHandler defaultDynFlags $ do\r\n runGhc (Just libdir) $ do\r\n dflags <- getSessionDynFlags\r\n setSessionDynFlags dflags\r\n target <- guessTarget \"noexist.hs\" Nothing\r\n --liftIO (print (showSDoc (ppr (target))))\r\n liftIO $ printTarget target\r\n setTargets [target]\r\n load LoadAllTargets\r\n\r\nprintTarget (Target id obj (Just (buf, time))) =\r\n print $ show buf\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2923Documentation contains (broken) links to /home/ian2019-07-07T19:06:16ZmatthijsDocumentation contains (broken) links to /home/ianThe GHC API documentation (and possibly other modules as well) contain broken links. In particular, all links to "!FilePath" on http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html point to http://www.haskell.org/home/ian/6...The GHC API documentation (and possibly other modules as well) contain broken links. In particular, all links to "!FilePath" on http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html point to http://www.haskell.org/home/ian/6.10.1/ghc-6.10.1/libraries/base/dist/doc/html/base/System-IO.html\#t%3AFilePath which is a broken link.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Documentation contains (broken) links to /home/ian","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC API documentation (and possibly other modules as well) contain broken links. In particular, all links to \"!FilePath\" on http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html point to http://www.haskell.org/home/ian/6.10.1/ghc-6.10.1/libraries/base/dist/doc/html/base/System-IO.html#t%3AFilePath which is a broken link.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2924createDirectory: permission denied2019-07-07T19:06:16ZSimon MarlowcreateDirectory: permission deniedThe following program results in an odd "permission denied" error from `createDirectory` on Windows. It is derived from the `createDirectoryIfMIssing001` test, but doesn't involve calling `createDirectoryIfMissing`, only `createDirectory...The following program results in an odd "permission denied" error from `createDirectory` on Windows. It is derived from the `createDirectoryIfMIssing001` test, but doesn't involve calling `createDirectoryIfMissing`, only `createDirectory`.
There are two threads, each of which is repeatedly creating a directory and using `removeDirectoryRecursive` to remove it.
Test program:
```
import System.IO
import System.Directory
import Control.Monad
import Control.Concurrent
import Control.Exception
import System.IO.Error
testdir = "foo"
main = do
cleanup
m <- newEmptyMVar
forkIO $ do replicateM_ 1000 (do create; cleanup); putMVar m ()
forkIO $ do replicateM_ 1000 (do create; cleanup); putMVar m ()
replicateM_ 2 $ takeMVar m
cleanup
create =
tryJust (guard . isAlreadyExistsError) $ createDirectory testdir
cleanup =
tryJust (guard . isDoesNotExistError) $ removeDirectoryRecursive testdir
```
The result is usually:
```
test.exe: CreateDirectory: permission denied (Access is denied.)
```
It's not clear (to me at least) why we get this error. Running the program under !ProcMon shows that there is a `CreateFile` call that returns `DELETE PENDING`, but as far as I can tell this doesn't give rise to an `ERROR_DELETE_PENDING` return from `CreateDirectory`, because that would give a different error message. Perhaps somewhere in the bowels of the Win32 API a `DELETE_PENDING` is being turned into a permission denied, or something.
This deserves investigation, because I think it might be related to other spurious "permission denied" errors we occasionally see on Windows.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"createDirectory: permission denied","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program results in an odd \"permission denied\" error from `createDirectory` on Windows. It is derived from the `createDirectoryIfMIssing001` test, but doesn't involve calling `createDirectoryIfMissing`, only `createDirectory`.\r\n\r\nThere are two threads, each of which is repeatedly creating a directory and using `removeDirectoryRecursive` to remove it. \r\n\r\nTest program:\r\n\r\n{{{\r\nimport System.IO\r\nimport System.Directory\r\nimport Control.Monad\r\nimport Control.Concurrent\r\nimport Control.Exception\r\nimport System.IO.Error\r\n\r\ntestdir = \"foo\"\r\n\r\nmain = do\r\n cleanup\r\n m <- newEmptyMVar\r\n forkIO $ do replicateM_ 1000 (do create; cleanup); putMVar m ()\r\n forkIO $ do replicateM_ 1000 (do create; cleanup); putMVar m ()\r\n replicateM_ 2 $ takeMVar m\r\n cleanup\r\n\r\ncreate =\r\n tryJust (guard . isAlreadyExistsError) $ createDirectory testdir\r\n\r\ncleanup =\r\n tryJust (guard . isDoesNotExistError) $ removeDirectoryRecursive testdir\r\n}}}\r\n\r\nThe result is usually:\r\n\r\n{{{\r\ntest.exe: CreateDirectory: permission denied (Access is denied.)\r\n}}}\r\n\r\nIt's not clear (to me at least) why we get this error. Running the program under !ProcMon shows that there is a `CreateFile` call that returns `DELETE PENDING`, but as far as I can tell this doesn't give rise to an `ERROR_DELETE_PENDING` return from `CreateDirectory`, because that would give a different error message. Perhaps somewhere in the bowels of the Win32 API a `DELETE_PENDING` is being turned into a permission denied, or something.\r\n\r\nThis deserves investigation, because I think it might be related to other spurious \"permission denied\" errors we occasionally see on Windows.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3https://gitlab.haskell.org/ghc/ghc/-/issues/2925Linker mmap failure on FreeBSD/x86_642019-07-07T19:06:15ZSimon MarlowLinker mmap failure on FreeBSD/x86_64We have some experimental fixes in the Linker to work around the lack of `MAP_32BIT` (see #2013, #2063 for background, also #2512), but still FreeBSD is presenting difficulties.
See
- [http://www.haskell.org/pipermail/glasgow-haskell-u...We have some experimental fixes in the Linker to work around the lack of `MAP_32BIT` (see #2013, #2063 for background, also #2512), but still FreeBSD is presenting difficulties.
See
- [http://www.haskell.org/pipermail/glasgow-haskell-users/2008-December/thread.html](http://www.haskell.org/pipermail/glasgow-haskell-users/2008-December/thread.html)
- [http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016438.html](http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016438.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Linker mmap failure on FreeBSD/x86_64","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.10.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We have some experimental fixes in the Linker to work around the lack of `MAP_32BIT` (see #2013, #2063 for background, also #2512), but still FreeBSD is presenting difficulties.\r\n\r\nSee \r\n * [http://www.haskell.org/pipermail/glasgow-haskell-users/2008-December/thread.html]\r\n * [http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016438.html]\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2927Bug in network library, uncaught exception when dealing with ipv6 sockets2019-07-07T19:06:15ZtphyahooBug in network library, uncaught exception when dealing with ipv6 socketsThere is an uncaught exception in the network library which is causing
my HAppS demo website
http://happstutorial.com
to crash every couple of days. This has affected other people using
HAppS as well, as described on postings to the HA...There is an uncaught exception in the network library which is causing
my HAppS demo website
http://happstutorial.com
to crash every couple of days. This has affected other people using
HAppS as well, as described on postings to the HAppS users list.
The bug, and workarounds, is described at
http://code.google.com/p/happs/issues/detail?id=40
Initially reported patch at
http://www.haskell.org/pipermail/libraries/2009-January/011103.html
Patch is attached.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/network |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bug in network library, uncaught exception when dealing with ipv6 sockets","status":"New","operating_system":"","component":"libraries/network","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["ipv6"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is an uncaught exception in the network library which is causing\r\nmy HAppS demo website\r\n\r\nhttp://happstutorial.com\r\n\r\nto crash every couple of days. This has affected other people using\r\nHAppS as well, as described on postings to the HAppS users list.\r\n\r\nThe bug, and workarounds, is described at\r\n\r\nhttp://code.google.com/p/happs/issues/detail?id=40\r\n\r\nInitially reported patch at\r\n\r\nhttp://www.haskell.org/pipermail/libraries/2009-January/011103.html\r\n\r\nPatch is attached.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHCbosboshttps://gitlab.haskell.org/ghc/ghc/-/issues/2928internal error: schedule: invalid what_next field2019-07-07T19:06:15Zgsaninternal error: schedule: invalid what_next fieldTest.hs:
```
import Control.Monad
main = forever $ print $ sum [1 .. 100000]
```
```
$ ghc --make Test.hs && ./Test
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
5000050000
5000050000
5000050000
<snip>
500005...Test.hs:
```
import Control.Monad
main = forever $ print $ sum [1 .. 100000]
```
```
$ ghc --make Test.hs && ./Test
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
5000050000
5000050000
5000050000
<snip>
5000050000
5000050000
5000050000
Test: internal error: schedule: invalid what_next field
(GHC version 6.10.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
```
This only happens when the program is compiled without optimization or -threaded. The number of iterations (\~50) before the error changes slightly and seems not to be affected by -H RTS option.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"internal error: schedule: invalid what_next field","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Test.hs:\r\n{{{\r\nimport Control.Monad\r\nmain = forever $ print $ sum [1 .. 100000]\r\n}}}\r\n{{{\r\n$ ghc --make Test.hs && ./Test\r\n[1 of 1] Compiling Main ( Test.hs, Test.o )\r\nLinking Test ...\r\n5000050000\r\n5000050000\r\n5000050000\r\n<snip>\r\n5000050000\r\n5000050000\r\n5000050000\r\nTest: internal error: schedule: invalid what_next field\r\n (GHC version 6.10.1 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted\r\n}}}\r\n\r\nThis only happens when the program is compiled without optimization or -threaded. The number of iterations (~50) before the error changes slightly and seems not to be affected by -H RTS option.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2929INFINITY used in .hc files without -std=c992019-07-07T19:06:14ZduncanINFINITY used in .hc files without -std=c99The C macro `INFINITY` is apparently defined by the C99 standard. On Solaris they take a strict interpretation of this and only define it conditionally:
```
#if defined(_STDC_C99) || _XOPEN_SOURCE - 0 >= 600 || defined(__C99FEATURES__)
...The C macro `INFINITY` is apparently defined by the C99 standard. On Solaris they take a strict interpretation of this and only define it conditionally:
```
#if defined(_STDC_C99) || _XOPEN_SOURCE - 0 >= 600 || defined(__C99FEATURES__)
```
ghc does not use `gcc -std=c99` but perhaps it should? This bug is triggered by test 1861 (See #1861).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| 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":"INFINITY used in .hc files without -std=c99","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The C macro `INFINITY` is apparently defined by the C99 standard. On Solaris they take a strict interpretation of this and only define it conditionally:\r\n{{{\r\n#if defined(_STDC_C99) || _XOPEN_SOURCE - 0 >= 600 || defined(__C99FEATURES__)\r\n}}}\r\n\r\nghc does not use `gcc -std=c99` but perhaps it should? This bug is triggered by test 1861 (See #1861).","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2930System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch2019-07-07T19:06:14ZwferiSystem.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch`formatCalendarTime` references strftime(3), and `man strftime` says
that `%s` is "the number of seconds since the Epoch, that is, since 1970-01-01 00:00:00 UTC."
However, under GHC 6.8.2 it is restricted to the 00-59 range, as the follo...`formatCalendarTime` references strftime(3), and `man strftime` says
that `%s` is "the number of seconds since the Epoch, that is, since 1970-01-01 00:00:00 UTC."
However, under GHC 6.8.2 it is restricted to the 00-59 range, as the following demonstrates.
`epoch.hs` is the following:
```
import System.Time
main = putStrLn $ formatCalendarTime undefined "%Y-%m-%d %T (%s)" (toUTCTime $ TOD 62 0)
```
And now:
```
$ runghc epoch.hs
1970-01-01 00:01:02 (02)
$ date --utc -d @62 +"%Y-%m-%d %T (%s)"
1970-01-01 00:01:02 (62)
```
I think *GNU date* is right, *System.Time* is wrong.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/old-time |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch","status":"New","operating_system":"","component":"libraries/old-time","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`formatCalendarTime` references strftime(3), and `man strftime` says\r\nthat `%s` is \"the number of seconds since the Epoch, that is, since 1970-01-01 00:00:00 UTC.\"\r\nHowever, under GHC 6.8.2 it is restricted to the 00-59 range, as the following demonstrates.\r\n\r\n`epoch.hs` is the following:\r\n{{{\r\nimport System.Time\r\nmain = putStrLn $ formatCalendarTime undefined \"%Y-%m-%d %T (%s)\" (toUTCTime $ TOD 62 0)\r\n}}}\r\nAnd now:\r\n{{{\r\n$ runghc epoch.hs \r\n1970-01-01 00:01:02 (02)\r\n$ date --utc -d @62 +\"%Y-%m-%d %T (%s)\"\r\n1970-01-01 00:01:02 (62)\r\n}}}\r\nI think ''GNU date'' is right, ''System.Time'' is wrong.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2931Template Haskell: Quoting single letter identifier leads to a parse error at ...2019-07-07T19:06:14ZBertram FelgenhauerTemplate Haskell: Quoting single letter identifier leads to a parse error at end of input.To reproduce the bug with ghci:
```
Prelude> :set -XTemplateHaskell
Prelude> let a = 1
Prelude> :t 'a
<interactive>:1:1:
lexical error in string/character literal at character 'a'
```
As a module, the following source code works i...To reproduce the bug with ghci:
```
Prelude> :set -XTemplateHaskell
Prelude> let a = 1
Prelude> :t 'a
<interactive>:1:1:
lexical error in string/character literal at character 'a'
```
As a module, the following source code works if the last line has no newline:
```
{-# LANGUAGE TemplateHaskell #-}
a = 1
b = 'a
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Template Haskell: Quoting single letter identifier leads to a parse error at end of input.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To reproduce the bug with ghci:\r\n{{{\r\nPrelude> :set -XTemplateHaskell\r\nPrelude> let a = 1\r\nPrelude> :t 'a\r\n\r\n<interactive>:1:1:\r\n lexical error in string/character literal at character 'a'\r\n}}}\r\nAs a module, the following source code works if the last line has no newline:\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\na = 1\r\nb = 'a\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2932Control.Arrow.Quantum, new version which compiles with GHC 6.102019-07-07T19:06:14Zdave@daveboden.comControl.Arrow.Quantum, new version which compiles with GHC 6.10The enclosed file contains a version of Quantum.hs with minor changes as per the instructions here: http://www.haskell.org/haskellwiki/Upgrading_packages\#Arrow_instances
The file now compiles with GHC 6.10. This page shows the errors t...The enclosed file contains a version of Quantum.hs with minor changes as per the instructions here: http://www.haskell.org/haskellwiki/Upgrading_packages\#Arrow_instances
The file now compiles with GHC 6.10. This page shows the errors that version 0.0.4 is experiencing under 6.10:
http://hackage.haskell.org/packages/archive/quantum-arrow/0.0.4/logs/failure/ghc-6.10
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Control.Arrow.Quantum, new version which compiles with GHC 6.10","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"The enclosed file contains a version of Quantum.hs with minor changes as per the instructions here: http://www.haskell.org/haskellwiki/Upgrading_packages#Arrow_instances\r\n\r\nThe file now compiles with GHC 6.10. This page shows the errors that version 0.0.4 is experiencing under 6.10:\r\n\r\nhttp://hackage.haskell.org/packages/archive/quantum-arrow/0.0.4/logs/failure/ghc-6.10","type_of_failure":"OtherFailure","blocking":[]} -->luquiluquihttps://gitlab.haskell.org/ghc/ghc/-/issues/2934HEAP_ALLOCED() is not thread-safe2019-07-07T19:06:13ZanishHEAP_ALLOCED() is not thread-safe Hi,
I have a program that seems to run into occasional garbage
collection-related core dumps. The problem typically only occurs after the
program has been running for a while and is consuming a large amount of
memory (5 - 16GB). The lar... Hi,
I have a program that seems to run into occasional garbage
collection-related core dumps. The problem typically only occurs after the
program has been running for a while and is consuming a large amount of
memory (5 - 16GB). The large memory consumption is expected because the
program analyzes very large traces from verilog simulation and needs to
maintain !IntMaps with hundreds of thousands of entries.
Is this a bug that I should report?I am afraid that my employer will not
allow me to share my source code. I do have a stack trace, below.
This was obtained using ghc 6.10.1, RTS -N2 on an x86-64 RHEL 4 machine.
Is there something I can do trace the problem or avoid it?
Thanks.
PS: This is my first Haskell program and one of the most complicated I
ever wrote, in any language. Using Haskell has been (mostly :-)) a joy.
```
(gdb) where
#0 0x0000000000612f40 in slowIsHeapAlloced ()
#1 0x000000000060f868 in evacuate ()
#2 0x0000000000618d12 in scavenge_block ()
#3 0x0000000000617c8d in scavenge_loop ()
#4 0x0000000000610b25 in scavenge_until_all_done ()
#5 0x0000000000610d02 in gc_thread_entry ()
#6 0x000000000064859d in start_thread (arg=<value optimized out>)
at pthread_create.c:297
#7 0x000000000069e739 in clone ()
#8 0x0000000000000000 in ?? ()
```6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2935"A lazy (~) pattern cannot bind existential type variables" happens for non-e...2019-07-07T19:06:13Zganesh"A lazy (~) pattern cannot bind existential type variables" happens for non-existential GADTsThis program:
```
{-# LANGUAGE GADTs #-}
module Foo where
data Foo a where
Foo :: a -> Foo (a, Int)
foo :: Foo (a, Int) -> a
foo ~(Foo a) = a
```
causes this error:
```
Foo.hs:8:4:
A lazy (~) pattern cannot bind existential t...This program:
```
{-# LANGUAGE GADTs #-}
module Foo where
data Foo a where
Foo :: a -> Foo (a, Int)
foo :: Foo (a, Int) -> a
foo ~(Foo a) = a
```
causes this error:
```
Foo.hs:8:4:
A lazy (~) pattern cannot bind existential type variables
`a' is a rigid type variable bound by
the constructor `Foo' at Foo.hs:8:6
In the pattern: ~(Foo a)
In the definition of `foo': foo ~(Foo a) = a
```
This doesn't seem like an existential, as there aren't any type variables in the arguments to Foo that aren't in the result type.
If easy it would be nice if the restriction were relaxed to allow for this case, otherwise I think the error message should be improved.
Tested with ghc 6.10.1.20081209 and ghc 6.11.20090107.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"\"A lazy (~) pattern cannot bind existential type variables\" happens for non-existential GADTs","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program:\r\n{{{\r\n{-# LANGUAGE GADTs #-}\r\nmodule Foo where\r\n\r\ndata Foo a where\r\n Foo :: a -> Foo (a, Int)\r\n\r\nfoo :: Foo (a, Int) -> a\r\nfoo ~(Foo a) = a\r\n}}}\r\ncauses this error:\r\n{{{\r\nFoo.hs:8:4:\r\n A lazy (~) pattern cannot bind existential type variables\r\n `a' is a rigid type variable bound by\r\n the constructor `Foo' at Foo.hs:8:6\r\n In the pattern: ~(Foo a)\r\n In the definition of `foo': foo ~(Foo a) = a\r\n}}}\r\n\r\nThis doesn't seem like an existential, as there aren't any type variables in the arguments to Foo that aren't in the result type.\r\n\r\nIf easy it would be nice if the restriction were relaxed to allow for this case, otherwise I think the error message should be improved.\r\n\r\nTested with ghc 6.10.1.20081209 and ghc 6.11.20090107.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2936System.IO.Error needs to be imported unconditionally2019-07-07T19:06:13ZguestSystem.IO.Error needs to be imported unconditionallyThe recent patch "Avoid using IOError internals" placed import of System.IO.Error in files Network/BSD.hsc and Network/Socket.hsc within a preprocessor conditional block, in the way that only GHC imports System.IO.Error. This causes erro...The recent patch "Avoid using IOError internals" placed import of System.IO.Error in files Network/BSD.hsc and Network/Socket.hsc within a preprocessor conditional block, in the way that only GHC imports System.IO.Error. This causes errors when Hugs processes these files.
Suggested: unconditionally import System.IO.Error in these modules.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/network |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.IO.Error needs to be imported unconditionally","status":"New","operating_system":"","component":"libraries/network","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The recent patch \"Avoid using IOError internals\" placed import of System.IO.Error in files Network/BSD.hsc and Network/Socket.hsc within a preprocessor conditional block, in the way that only GHC imports System.IO.Error. This causes errors when Hugs processes these files.\r\n\r\nSuggested: unconditionally import System.IO.Error in these modules.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2937source file that compiled fine fails to recompile after touching it (yes, ano...2019-07-07T19:06:13Zrwbartonsource file that compiled fine fails to recompile after touching it (yes, another one)I'm using the development snapshot `ghc-6.11.20090107` and ran into a bug very similar to #2888, but I think it is different because I could not reproduce that bug in my version.
The setup is very similar: File `A.hs` contains
```
{-# ...I'm using the development snapshot `ghc-6.11.20090107` and ran into a bug very similar to #2888, but I think it is different because I could not reproduce that bug in my version.
The setup is very similar: File `A.hs` contains
```
{-# LANGUAGE TypeFamilies #-}
module A where
class Foo a where
data Bar a :: * -> *
```
and file `B.hs` contains
```
{-# LANGUAGE TypeFamilies #-}
module B where
import A
instance Foo Int where
data Bar Int x where
Baz :: Bar Int String
```
Then:
```
rwbarton@functor:/tmp/a$ ghc --make B
[1 of 2] Compiling A ( A.hs, A.o )
[2 of 2] Compiling B ( B.hs, B.o )
rwbarton@functor:/tmp/a$ touch B.hs
rwbarton@functor:/tmp/a$ ghc --make B
[2 of 2] Compiling B ( B.hs, B.o )
B.hs:8:2:
Arguments that do not correspond to a class parameter must be variables
Instead of a variable, found Int
In the associated type instance for `Bar'
In the instance declaration for `Foo Int'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"source file that compiled fine fails to recompile after touching it (yes, another one)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm using the development snapshot `ghc-6.11.20090107` and ran into a bug very similar to #2888, but I think it is different because I could not reproduce that bug in my version.\r\n\r\nThe setup is very similar: File `A.hs` contains\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule A where\r\nclass Foo a where\r\n data Bar a :: * -> *\r\n}}}\r\nand file `B.hs` contains\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule B where\r\nimport A\r\ninstance Foo Int where\r\n data Bar Int x where\r\n Baz :: Bar Int String\r\n}}}\r\nThen:\r\n{{{\r\nrwbarton@functor:/tmp/a$ ghc --make B\r\n[1 of 2] Compiling A ( A.hs, A.o )\r\n[2 of 2] Compiling B ( B.hs, B.o )\r\nrwbarton@functor:/tmp/a$ touch B.hs\r\nrwbarton@functor:/tmp/a$ ghc --make B\r\n[2 of 2] Compiling B ( B.hs, B.o )\r\n\r\nB.hs:8:2:\r\n Arguments that do not correspond to a class parameter must be variables\r\n Instead of a variable, found Int\r\n In the associated type instance for `Bar'\r\n In the instance declaration for `Foo Int'\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/2938excessive use of stack space with longer source lists2019-07-07T19:06:12Zrkexcessive use of stack space with longer source listsghc does not handle long lists in a good way at the moment
compiling the attached file take to much stack space ...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------...ghc does not handle long lists in a good way at the moment
compiling the attached file take to much stack space ...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"excessive use of stack space with longer source lists","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc does not handle long lists in a good way at the moment\r\n\r\ncompiling the attached file take to much stack space ...","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2939Example in library doco for Control.Exception.handle is no longer supported i...2019-07-07T19:06:12Znr@eecs.harvard.eduExample in library doco for Control.Exception.handle is no longer supported in GHC 6.10The library documentation for `Control.Exception` includes an example that does not compile in GHC 6.10:
```
Prelude Control.Exception System> do handle (\e -> exitWith (ExitFailure 1)) $ undefined
<interactive>:1:3:
Ambiguous type...The library documentation for `Control.Exception` includes an example that does not compile in GHC 6.10:
```
Prelude Control.Exception System> do handle (\e -> exitWith (ExitFailure 1)) $ undefined
<interactive>:1:3:
Ambiguous type variable `e' in the constraint:
`Exception e'
arising from a use of `handle' at <interactive>:1:3-41
Probable fix: add a type signature that fixes these type variable(s)
Prelude Control.Exception System>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Example in library doco for Control.Exception.handle is no longer supported in GHC 6.10","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The library documentation for {{{Control.Exception}}} includes an example that does not compile in GHC 6.10:\r\n\r\n{{{\r\nPrelude Control.Exception System> do handle (\\e -> exitWith (ExitFailure 1)) $ undefined\r\n\r\n<interactive>:1:3:\r\n Ambiguous type variable `e' in the constraint:\r\n `Exception e'\r\n arising from a use of `handle' at <interactive>:1:3-41\r\n Probable fix: add a type signature that fixes these type variable(s)\r\nPrelude Control.Exception System> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2940Do CSE after CorePrep2019-07-07T19:06:12ZSimon Peyton JonesDo CSE after CorePrepCommon sub-expression analysis is deliberately conservative, but it's really *too* conservative: we are missing obvious opportunities. Consider
```
{-# OPTIONS_GHC -XBangPatterns -XMagicHash #-}
module Foo where
import GHC.Base
-- Co...Common sub-expression analysis is deliberately conservative, but it's really *too* conservative: we are missing obvious opportunities. Consider
```
{-# OPTIONS_GHC -XBangPatterns -XMagicHash #-}
module Foo where
import GHC.Base
-- CorePrep evaluates (reverse xs) twice
f xs = let !v1 = reverse (reverse xs)
!v2 = filter id (reverse xs)
in (v1, v2)
-- Even CSE inside CorePrep would not get this right;
-- the strict evaluation of (reverse xs) doesn't scope
-- over the non-strict version
g xs = reverse (reverse xs) ++ filter id (reverse xs)
-- Duplicate evaluation of (x +# 1#)
h :: Int# -> ( Int, Int )
h x = ( I# (x +# 1#), I# ((x +# 1#) *# 2#) )
```
If you compile this you'll see that there are obvious missed CSE opportunities in `f`, `g` and `h`; but they only show up after `CorePrep`.
I guess the right thing is to CSE after `CorePrep`, but then CSE would have to maintain the `CorePrep` invariants, which isn't trivial. Something to think about.
Simon
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Do CSE after CorePrep","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Common sub-expression analysis is deliberately conservative, but it's really ''too'' conservative: we are missing obvious opportunities. Consider\r\n{{{\r\n{-# OPTIONS_GHC -XBangPatterns -XMagicHash #-}\r\n\r\nmodule Foo where\r\n\r\nimport GHC.Base\r\n\r\n-- CorePrep evaluates (reverse xs) twice\r\nf xs = let !v1 = reverse (reverse xs)\r\n \t !v2 = filter id (reverse xs)\r\n in (v1, v2)\r\n\r\n-- Even CSE inside CorePrep would not get this right;\r\n-- the strict evaluation of (reverse xs) doesn't scope\r\n-- over the non-strict version\r\ng xs = reverse (reverse xs) ++ filter id (reverse xs)\r\n\r\n\r\n-- Duplicate evaluation of (x +# 1#)\r\nh :: Int# -> ( Int, Int )\r\nh x = ( I# (x +# 1#), I# ((x +# 1#) *# 2#) )\r\n}}}\r\nIf you compile this you'll see that there are obvious missed CSE opportunities in `f`, `g` and `h`; but they only show up after `CorePrep`. \r\n\r\nI guess the right thing is to CSE after `CorePrep`, but then CSE would have to maintain the `CorePrep` invariants, which isn't trivial. Something to think about.\r\n\r\nSimon","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/2941HsBase.h includes termios.h which prevents us including curses.h on solaris2019-07-07T19:06:12ZduncanHsBase.h includes termios.h which prevents us including curses.h on solarisEvery .hc file includes `HsBase.h` from the base package.
Unfortunately on Solaris something that this header defines or includes makes `curses.h` invalid.
```
#include "HsBase.h"
#include <curses.h>
#include <term.h>
int main () { r...Every .hc file includes `HsBase.h` from the base package.
Unfortunately on Solaris something that this header defines or includes makes `curses.h` invalid.
```
#include "HsBase.h"
#include <curses.h>
#include <term.h>
int main () { return 0; }
```
Gives us:
```
GHCDIR=/opt/ghc/lib/ghc-6.8.3
gcc -c foo.c -I${GHCDIR}/include -I${GHCDIR}/lib/base-3.0.2.0/include
In file included from foo.c:5:
/usr/include/term.h:1060: error: field ‘Ottyb’ has incomplete type
/usr/include/term.h:1061: error: field ‘Nttyb’ has incomplete type
```
whereas if we omit `#include "HsBase.h"` from `foo.c` then it compiles fine.
If we narrow this down a bit we find that it's because we cannot compile this file:
```
#include <termios.h>
#include <curses.h>
#include <term.h>
int main () { return 0; }
```
That is, if we include termios.h before curses.h
The reason is that `curses.h` has:
```
#ifndef VINTR
#include <termio.h>
#endif /* VINTR */
typedef struct termio SGTTY;
typedef struct termios SGTTYS;
```
and `termios.h` defines VINTR, however it is `termio.h` that defines `struct termio`. Hence the `SGTTY` typedef is undefined, or incomplete in C parlance.
If we instead do:
```
#include <curses.h>
#include <term.h>
#include <termios.h>
int main () { return 0; }
```
Then it compiles fine. Indeed if we edit the .hc file that originally tickled this bug to put the includes in the other order then it all works fine.
The nearest reports elsewhere on the net that I've found are:
http://www.nabble.com/Can't-build-pl-5.6.63-td20943886.html
http://www.nabble.com/minor-build-issue-with-5.6.61-on-Solaris-10-6-06-td19698590.html
This bug prevents the terminfo package from building on Solaris. In turn that blocks haskeline and ghci-haskeline. So it's a blocker for ghc adopting haskeline on Solaris at the moment. That blocker may go away if we get -fasm working and drop support for -fvia-C.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"HsBase.h includes termios.h which prevents us including curses.h on solaris","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Every .hc file includes `HsBase.h` from the base package.\r\n\r\nUnfortunately on Solaris something that this header defines or includes makes `curses.h` invalid.\r\n\r\n{{{\r\n#include \"HsBase.h\"\r\n\r\n#include <curses.h>\r\n#include <term.h>\r\n\r\nint main () { return 0; }\r\n}}}\r\n\r\nGives us:\r\n\r\n{{{\r\nGHCDIR=/opt/ghc/lib/ghc-6.8.3\r\ngcc -c foo.c -I${GHCDIR}/include -I${GHCDIR}/lib/base-3.0.2.0/include\r\nIn file included from foo.c:5:\r\n/usr/include/term.h:1060: error: field ‘Ottyb’ has incomplete type\r\n/usr/include/term.h:1061: error: field ‘Nttyb’ has incomplete type\r\n}}}\r\n\r\nwhereas if we omit `#include \"HsBase.h\"` from `foo.c` then it compiles fine.\r\n\r\nIf we narrow this down a bit we find that it's because we cannot compile this file:\r\n\r\n{{{\r\n#include <termios.h>\r\n\r\n#include <curses.h>\r\n#include <term.h>\r\n\r\nint main () { return 0; }\r\n}}}\r\n\r\nThat is, if we include termios.h before curses.h\r\n\r\nThe reason is that `curses.h` has:\r\n{{{\r\n#ifndef VINTR\r\n#include <termio.h>\r\n#endif /* VINTR */\r\ntypedef struct termio SGTTY;\r\ntypedef struct termios SGTTYS;\r\n}}}\r\n\r\nand `termios.h` defines VINTR, however it is `termio.h` that defines `struct termio`. Hence the `SGTTY` typedef is undefined, or incomplete in C parlance.\r\n\r\nIf we instead do:\r\n{{{\r\n#include <curses.h>\r\n#include <term.h>\r\n\r\n#include <termios.h>\r\n\r\nint main () { return 0; }\r\n}}}\r\n\r\nThen it compiles fine. Indeed if we edit the .hc file that originally tickled this bug to put the includes in the other order then it all works fine.\r\n\r\nThe nearest reports elsewhere on the net that I've found are:\r\nhttp://www.nabble.com/Can't-build-pl-5.6.63-td20943886.html\r\nhttp://www.nabble.com/minor-build-issue-with-5.6.61-on-Solaris-10-6-06-td19698590.html\r\n\r\nThis bug prevents the terminfo package from building on Solaris. In turn that blocks haskeline and ghci-haskeline. So it's a blocker for ghc adopting haskeline on Solaris at the moment. That blocker may go away if we get -fasm working and drop support for -fvia-C.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2942witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case-se...2019-07-07T19:06:12Zthorkilnaurwitten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case-sensitive file systemThe `make install` of the binary distribution http://www.haskell.org/ghc/dist/6.10.1/witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2 (see http://www.haskell.org/ghc/download_ghc_6_10_1.html) for PPC Max OS X 10.5 (Leopard) fails on a case...The `make install` of the binary distribution http://www.haskell.org/ghc/dist/6.10.1/witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2 (see http://www.haskell.org/ghc/download_ghc_6_10_1.html) for PPC Max OS X 10.5 (Leopard) fails on a case-sensitive file system with this error message:
```
make -C haddock install
/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1-powerpc-apple-darwin/ghc-6.10.1/dist/utils/installPackage/install-inplace/bin/installPackage install \
'/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1-powerpc-apple-darwin/ghc-6.10.1/dist/utils/ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg' \
'/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1/package.conf' \
'' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1' \
'/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/bin' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1' \
'/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1' '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1' \
'/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/share/doc/ghc' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/share/doc/ghc' '' \
--distpref dist-install \
--enable-shell-wrappers
Installing library in
/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1/haddock-2.3.0
Installing executable(s) in
/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/bin
installPackage: dist-install/build/haddock/haddock: copyFile: does not exist (No such file or directory)
make[2]: *** [install] Error 1
make[1]: *** [install.haddock] Error 2
make: *** [install] Error 2
```
As a work-around, I created the following symbolic link:
```
thorkil-naurs-mac-mini:/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1-powerpc-apple-darwin/ghc-6.10.1/dist thorkilnaur$ ls -l utils/haddock/dist-install/build/haddock
lrwxr-xr-x 1 thorkilnaur 501 7 Jan 12 23:31 utils/haddock/dist-install/build/haddock -> Haddock
thorkil-naurs-mac-mini:/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1-powerpc-apple-darwin/ghc-6.10.1/dist thorkilnaur$
```
With this link, the `make install` succeeds.
Thanks and best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case-sensitive file system","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The {{{make install}}} of the binary distribution http://www.haskell.org/ghc/dist/6.10.1/witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2 (see http://www.haskell.org/ghc/download_ghc_6_10_1.html) for PPC Max OS X 10.5 (Leopard) fails on a case-sensitive file system with this error message:\r\n{{{\r\nmake -C haddock install\r\n/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1-powerpc-apple-darwin/ghc-6.10.1/dist/utils/installPackage/install-inplace/bin/installPackage install \\\r\n '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1-powerpc-apple-darwin/ghc-6.10.1/dist/utils/ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg' \\\r\n '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1/package.conf' \\\r\n '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1' \\\r\n '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/bin' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1' \\\r\n '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1' '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1' \\\r\n '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/share/doc/ghc' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/share/doc/ghc' '' \\\r\n --distpref dist-install \\\r\n --enable-shell-wrappers\r\nInstalling library in\r\n/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1/haddock-2.3.0\r\nInstalling executable(s) in\r\n/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/bin\r\ninstallPackage: dist-install/build/haddock/haddock: copyFile: does not exist (No such file or directory)\r\nmake[2]: *** [install] Error 1\r\nmake[1]: *** [install.haddock] Error 2\r\nmake: *** [install] Error 2\r\n}}}\r\nAs a work-around, I created the following symbolic link:\r\n{{{\r\nthorkil-naurs-mac-mini:/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1-powerpc-apple-darwin/ghc-6.10.1/dist thorkilnaur$ ls -l utils/haddock/dist-install/build/haddock\r\nlrwxr-xr-x 1 thorkilnaur 501 7 Jan 12 23:31 utils/haddock/dist-install/build/haddock -> Haddock\r\nthorkil-naurs-mac-mini:/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1-powerpc-apple-darwin/ghc-6.10.1/dist thorkilnaur$\r\n}}}\r\nWith this link, the {{{make install}}} succeeds.\r\n\r\nThanks and best regards\r\nThorkil\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2943Socket related IO cannot be be interrupted on Windows2019-07-07T19:06:12Zh.holtmannSocket related IO cannot be be interrupted on WindowsWhile playing with socket communication, I noticed that socket IO cannot be interrupted or killed.
The attached program simply hangs, irregardless whether is was complied using the -threaded flag or not.
<details><summary>Trac metadata<...While playing with socket communication, I noticed that socket IO cannot be interrupted or killed.
The attached program simply hangs, irregardless whether is was complied using the -threaded flag or not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/network |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Socket related IO cannot be be interrupted on Windows","status":"New","operating_system":"","component":"libraries/network","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While playing with socket communication, I noticed that socket IO cannot be interrupted or killed.\r\nThe attached program simply hangs, irregardless whether is was complied using the -threaded flag or not.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2944Mutually recursive equality constraints2019-07-07T19:06:11ZMartijnVanSteenbergenMutually recursive equality constraintsGiven this piece of code:
```
{-# LANGUAGE TypeFamilies #-}
class C a where
type T a :: *
f1 :: T a ~ () => a
f1 = f2
f2 :: T a ~ () => a
f2 = f1
```
GHC complains:
```
Couldn't match expected type `T a ~ ()'
again...Given this piece of code:
```
{-# LANGUAGE TypeFamilies #-}
class C a where
type T a :: *
f1 :: T a ~ () => a
f1 = f2
f2 :: T a ~ () => a
f2 = f1
```
GHC complains:
```
Couldn't match expected type `T a ~ ()'
against inferred type `T a1 ~ ()'
When matching the contexts of the signatures for
f1 :: forall a. (T a ~ ()) => a
f2 :: forall a. (T a ~ ()) => a
The signature contexts in a mutually recursive group should all be identical
When generalising the type(s) for f1, f2
```
Is this a bug? Enabling RelaxedPolyRec fixes the problem. Should TypeFamilies—just like GADTs—imply RelaxedPolyRec?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Mutually recursive equality constraints","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Given this piece of code:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\nclass C a where\r\n type T a :: *\r\n\r\nf1 :: T a ~ () => a\r\nf1 = f2\r\n\r\nf2 :: T a ~ () => a\r\nf2 = f1\r\n}}}\r\n\r\nGHC complains:\r\n\r\n{{{\r\n Couldn't match expected type `T a ~ ()'\r\n against inferred type `T a1 ~ ()'\r\n When matching the contexts of the signatures for\r\n f1 :: forall a. (T a ~ ()) => a\r\n f2 :: forall a. (T a ~ ()) => a\r\n The signature contexts in a mutually recursive group should all be identical\r\n When generalising the type(s) for f1, f2\r\n}}}\r\n\r\nIs this a bug? Enabling RelaxedPolyRec fixes the problem. Should TypeFamilies—just like GADTs—imply RelaxedPolyRec?\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2947infix precedence of backtick functions defined in ghci is not reported by :info2019-07-07T19:06:11ZEyalLoteminfix precedence of backtick functions defined in ghci is not reported by :infoexcerpt from ghci:
```
Prelude> let infixr 9 `f` ; f = (+)
let infixr 9 `f` ; f = (+)
Prelude> 5 * 3 `f` 4
35
Prelude> :info f
f :: Integer -> Integer -> Integer
-- Defined at <interactive>:1:19
Prelude> :info `f`
f :: Integer -> Int...excerpt from ghci:
```
Prelude> let infixr 9 `f` ; f = (+)
let infixr 9 `f` ; f = (+)
Prelude> 5 * 3 `f` 4
35
Prelude> :info f
f :: Integer -> Integer -> Integer
-- Defined at <interactive>:1:19
Prelude> :info `f`
f :: Integer -> Integer -> Integer
-- Defined at <interactive>:1:19
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| 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":"infix precedence of backtick functions defined in ghci is not reported by :info","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"excerpt from ghci:\r\n{{{\r\nPrelude> let infixr 9 `f` ; f = (+)\r\nlet infixr 9 `f` ; f = (+)\r\nPrelude> 5 * 3 `f` 4\r\n35\r\nPrelude> :info f\r\nf :: Integer -> Integer -> Integer\r\n \t-- Defined at <interactive>:1:19\r\nPrelude> :info `f`\r\nf :: Integer -> Integer -> Integer\r\n \t-- Defined at <interactive>:1:19\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriotti