GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-10-20T08:03:16Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/11260Re-compilation driver/recomp11 test fails2023-10-20T08:03:16ZPeter Trommlerptrommler@acm.orgRe-compilation driver/recomp11 test failsrecomp011:
```
[1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed]
Linking Main ...
4343
+Linking Main ...
4343
```recomp011:
```
[1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed]
Linking Main ...
4343
+Linking Main ...
4343
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/182Old setup procedure for Windows2023-10-19T15:38:18ZnobodyOld setup procedure for Windows```
The document user_guide.pdf in the GHC 6.01 for
Windows package describes the install procedure for
version 5.02, setup.exe instead of ghc-6-0-1.msi.
```
<details><summary>Trac metadata</summary>
| Trac field | Valu...```
The document user_guide.pdf in the GHC 6.01 for
Windows package describes the install procedure for
version 5.02, setup.exe instead of ghc-6-0-1.msi.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Old setup procedure for Windows","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe document user_guide.pdf in the GHC 6.01 for \nWindows package describes the install procedure for \nversion 5.02, setup.exe instead of ghc-6-0-1.msi. \n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/4820"Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch2023-10-19T07:01:36Zdleuschner"Invalid object in isRetainer" when doing retainer profiling in GHC 7 branchNow that issue #4362 is fixed I was doing some retainer profiling with the current GHC 7 branch with Bryans patches from #4514 applied. After some clients start connecting to our server it aborts with one of the following messages:
```
...Now that issue #4362 is fixed I was doing some retainer profiling with the current GHC 7 branch with Bryans patches from #4514 applied. After some clients start connecting to our server it aborts with one of the following messages:
```
SalviaDerivationGateway_p: internal error: Invalid object in isRetainer(): 39
(GHC version 7.0.1.20101203 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
SalviaDerivationGateway_p: internal error: Invalid object in isRetainer(): 812
(GHC version 7.0.1.20101203 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
SalviaDerivationGateway_p: internal error: scavenge_mark_stack: unimplemented/strange closure type 71648289 @ 0x7f74206961a8
(GHC version 7.0.1.20101203 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I compiled with -O3 -funbox-strict-fields -prof and tried with and without -threaded but that doesn't make a difference.
Is there anything I could do to help to diagnose the problem? Our test program from #4362 runs fine with retainer profiling. If it is of any help I can install the patched GHC 7 branch and our application onto our test server and give to access to it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | wehr@factisresearch.com |
| Operating system | Linux |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"Invalid object in isRetainer\" when doing retainer profiling in GHC 7 branch","status":"New","operating_system":"Linux","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["wehr@factisresearch.com"],"type":"Bug","description":"Now that issue #4362 is fixed I was doing some retainer profiling with the current GHC 7 branch with Bryans patches from #4514 applied. After some clients start connecting to our server it aborts with one of the following messages:\r\n\r\n{{{\r\nSalviaDerivationGateway_p: internal error: Invalid object in isRetainer(): 39\r\n (GHC version 7.0.1.20101203 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nSalviaDerivationGateway_p: internal error: Invalid object in isRetainer(): 812\r\n (GHC version 7.0.1.20101203 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nSalviaDerivationGateway_p: internal error: scavenge_mark_stack: unimplemented/strange closure type 71648289 @ 0x7f74206961a8\r\n (GHC version 7.0.1.20101203 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\nI compiled with -O3 -funbox-strict-fields -prof and tried with and without -threaded but that doesn't make a difference.\r\n\r\nIs there anything I could do to help to diagnose the problem? Our test program from #4362 runs fine with retainer profiling. If it is of any help I can install the patched GHC 7 branch and our application onto our test server and give to access to it.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/13841ADOPT pragma for silencing orphan instances warnings per instance2023-10-15T19:52:12ZMoritz KieferADOPT pragma for silencing orphan instances warnings per instanceCurrently GHC only allows enabling and disabling the warnings about orphan instances on a module level. I’d like to have an ADOPT pragma that allows disabling the warning for specific instance:
```haskell
instance {-# ADOPT #-} C Int
``...Currently GHC only allows enabling and disabling the warnings about orphan instances on a module level. I’d like to have an ADOPT pragma that allows disabling the warning for specific instance:
```haskell
instance {-# ADOPT #-} C Int
```
Apart from disabling the warning about orphan instances for this specific instance, this pragma should have no effect.
I already hacked together a [prototype](https://github.com/cocreature/ghc/tree/adopt-pragma) and I’m willing to clean that up and submit a diff if other people like this.
This does change the surface language but disabling a warning seem too small of an effect for the ghc proposals process (I’m happy to make a proposal if you disagree).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.3 |
| 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":"ADOPT pragma for silencing orphan instances warnings per instance","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently GHC only allows enabling and disabling the warnings about orphan instances on a module level. I’d like to have an ADOPT pragma that allows disabling the warning for specific instance:\r\n\r\n\r\n{{{#!haskell\r\ninstance {-# ADOPT #-} C Int\r\n}}}\r\n\r\nApart from disabling the warning about orphan instances for this specific instance, this pragma should have no effect.\r\n\r\nI already hacked together a [https://github.com/cocreature/ghc/tree/adopt-pragma prototype] and I’m willing to clean that up and submit a diff if other people like this.\r\n\r\nThis does change the surface language but disabling a warning seem too small of an effect for the ghc proposals process (I’m happy to make a proposal if you disagree).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13218<$ is bad in derived functor instances2023-10-02T09:12:24ZDavid Feuer<$ is bad in derived functor instances`Functor` deriving derives the definition of `fmap`, leaving the definition of `<$` to the default. This is quite bad for recursive types:
```hs
data Tree a = Bin !(Tree a) a !(Tree a) | Tip deriving Functor
```
produces
```
Replace.$...`Functor` deriving derives the definition of `fmap`, leaving the definition of `<$` to the default. This is quite bad for recursive types:
```hs
data Tree a = Bin !(Tree a) a !(Tree a) | Tip deriving Functor
```
produces
```
Replace.$fFunctorTree_$c<$ =
\ (@ a_aGl) (@ b_aGm) (eta_aGn :: a_aGl) (eta1_B1 :: Tree b_aGm) ->
Replace.$fFunctorTree_$cfmap
@ b_aGm @ a_aGl (\ _ [Occ=Dead] -> eta_aGn) eta1_B1
```
Why is this bad? It fills the tree with thunks keeping the original values (which we never use again) alive. What we want to generate is
```hs
x <$ Bin l _ r = Bin (x <$ l) x (x <$ r)
```
When there are other functor types in the constructor, like
```hs
| Whatever (Tree (Tree a))
```
we will need to insert `fmap (x <$) t`. The overall shape should be basically the same as `fmap` deriving.
Note: there are some types for which we will not realistically be able to derive optimal definitions. In particular, fixed-shape, undecorated types that appear in nested types allow special treatment:
```hs
data Pair a = Pair a a deriving Functor
data Tree2 a = Z a | S (Tree2 (Pair a)) deriving Functor
```
The ideal definition for this type is
```hs
x <$ Z _ = Z x
x <$ S t = S (Pair x x <$ t)
```
but that requires cleverness. We should probably settle for
```hs
x <$ Z _ = Z x
x <$ S t = S (fmap (x <$) t)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"<$ is bad in derived functor instances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dfeuer"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`Functor` deriving derives the definition of `fmap`, leaving the definition of `<$` to the default. This is quite bad for recursive types:\r\n\r\n{{{#!hs\r\ndata Tree a = Bin !(Tree a) a !(Tree a) | Tip deriving Functor\r\n}}}\r\n\r\nproduces\r\n\r\n{{{\r\nReplace.$fFunctorTree_$c<$ =\r\n \\ (@ a_aGl) (@ b_aGm) (eta_aGn :: a_aGl) (eta1_B1 :: Tree b_aGm) ->\r\n Replace.$fFunctorTree_$cfmap\r\n @ b_aGm @ a_aGl (\\ _ [Occ=Dead] -> eta_aGn) eta1_B1\r\n}}}\r\n\r\nWhy is this bad? It fills the tree with thunks keeping the original values (which we never use again) alive. What we want to generate is\r\n\r\n{{{#!hs\r\nx <$ Bin l _ r = Bin (x <$ l) x (x <$ r)\r\n}}}\r\n\r\nWhen there are other functor types in the constructor, like\r\n\r\n{{{#!hs\r\n | Whatever (Tree (Tree a))\r\n}}}\r\n\r\nwe will need to insert `fmap (x <$) t`. The overall shape should be basically the same as `fmap` deriving.\r\n\r\nNote: there are some types for which we will not realistically be able to derive optimal definitions. In particular, fixed-shape, undecorated types that appear in nested types allow special treatment:\r\n\r\n{{{#!hs\r\ndata Pair a = Pair a a deriving Functor\r\ndata Tree2 a = Z a | S (Tree2 (Pair a)) deriving Functor\r\n}}}\r\n\r\nThe ideal definition for this type is\r\n\r\n{{{#!hs\r\n x <$ Z _ = Z x\r\n x <$ S t = S (Pair x x <$ t)\r\n}}}\r\n\r\nbut that requires cleverness. We should probably settle for\r\n\r\n{{{#!hs\r\n x <$ Z _ = Z x\r\n x <$ S t = S (fmap (x <$) t)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/14903RISC-V port2023-09-29T08:03:09ZBen GamariRISC-V portAt least three people recently mentioned interest in a RISC-V port of GHC. As it turns out, I started down this road one weekend last year. This ticket will track this effort.
<details><summary>Trac metadata</summary>
| Trac field ...At least three people recently mentioned interest in a RISC-V port of GHC. As it turns out, I started down this road one weekend last year. This ticket will track this effort.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"RISC-V port","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"At least three people recently mentioned interest in a RISC-V port of GHC. As it turns out, I started down this road one weekend last year. This ticket will track this effort.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11322Dysfunctional `__GLASGOW_HASKELL_TH` macro2023-09-23T03:33:57ZHerbert Valerio Riedelhvr@gnu.orgDysfunctional `__GLASGOW_HASKELL_TH` macrosee commit messagesee commit message8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11958Improved testing of cross-compiler2023-09-20T15:12:48ZerikdImproved testing of cross-compilerIt is already possible to build cross compiler eg from x86_64/linux to armhf/linux or arm64/linux, but there is currently no way to run the test suite.
However, at least for the host and targets above, it should be possible to run the t...It is already possible to build cross compiler eg from x86_64/linux to armhf/linux or arm64/linux, but there is currently no way to run the test suite.
However, at least for the host and targets above, it should be possible to run the test executables under the Qemu user space emulation. I know this works, because in my own personal jenkins build instance, I test exactly this by doing (for x86_64/linux to amr64/linux cross):
```
echo -e 'main :: IO ()\nmain = putStrLn "Hello World"\n' > hello-world.hs
inplace/bin/ghc-stage1 hello-world.hs -o hello-world
test $(file hello-world | grep -c 'ARM aarch64, version 1') -eq 1
./hello-world
```
The linux machine I run the above test on is x86_64/linux but has Qemu and `binfmt` stuff set up so that it can run some foreign binaries. For instance, if GHC worked as a Linux to Windows cross-compiler the resulting windows binaries should work under Wine.
To get this working, I suspect that just about all the required work is in the build system. Not sure if it might not be better to wait until the Shake based build system is in better shape.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Improved testing of cross-compiler","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":["cross-compile"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"It is already possible to build cross compiler eg from x86_64/linux to armhf/linux or arm64/linux, but there is currently no way to run the test suite.\r\n\r\nHowever, at least for the host and targets above, it should be possible to run the test executables under the Qemu user space emulation. I know this works, because in my own personal jenkins build instance, I test exactly this by doing (for x86_64/linux to amr64/linux cross):\r\n\r\n{{{\r\necho -e 'main :: IO ()\\nmain = putStrLn \"Hello World\"\\n' > hello-world.hs\r\ninplace/bin/ghc-stage1 hello-world.hs -o hello-world\r\ntest $(file hello-world | grep -c 'ARM aarch64, version 1') -eq 1\r\n./hello-world\r\n}}}\r\n\r\nThe linux machine I run the above test on is x86_64/linux but has Qemu and `binfmt` stuff set up so that it can run some foreign binaries. For instance, if GHC worked as a Linux to Windows cross-compiler the resulting windows binaries should work under Wine.\r\n\r\nTo get this working, I suspect that just about all the required work is in the build system. Not sure if it might not be better to wait until the Shake based build system is in better shape.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/433ghc-6.4.1.20050801: panic!2023-09-20T14:47:58Zggdghc-6.4.1.20050801: panic!```
Hi!
I've pulled the latest Yi code from the darcs
repository and tried to compile it with 'make
way=static' using ghc-6.4.1.20050801 compiler.
Here is the result:
[...]
ghc -Wall -Werror -Icbits -Imk -funbox-s...```
Hi!
I've pulled the latest Yi code from the darcs
repository and tried to compile it with 'make
way=static' using ghc-6.4.1.20050801 compiler.
Here is the result:
[...]
ghc -Wall -Werror -Icbits -Imk -funbox-strict-fields
-O2 -fasm -threaded -package-conf yi.conf
-package yi -i -Icbits -Imk -c Yi.hs -o Yi.o -ohi Yi.hi
ghc -Wall -Werror -Icbits -Imk -funbox-strict-fields
-O2 -fasm -threaded -package-conf yi.conf
-package yi -c Main.hs -o Main.o -ohi Main.hi
./Yi.hi :
Interface file inconsistency:
home-package module `Yi.Editor' is mentioned,
but does not appear in the dependencies of the
interface
ghc-6.4.1.20050801: panic! (the `impossible'
happened, GHC version 6.4.1.20050801):
forkM Declaration for staticzumain{v}
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Sincerely,
Gour
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-6.4.1.20050801: panic!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nHi! \n \nI've pulled the latest Yi code from the darcs \nrepository and tried to compile it with 'make \nway=static' using ghc-6.4.1.20050801 compiler. \n \nHere is the result: \n \n[...] \nghc -Wall -Werror -Icbits -Imk -funbox-strict-fields \n-O2 -fasm -threaded -package-conf yi.conf \n-package yi -i -Icbits -Imk -c Yi.hs -o Yi.o -ohi Yi.hi \nghc -Wall -Werror -Icbits -Imk -funbox-strict-fields \n-O2 -fasm -threaded -package-conf yi.conf \n-package yi -c Main.hs -o Main.o -ohi Main.hi \n./Yi.hi : \n Interface file inconsistency: \n home-package module `Yi.Editor' is mentioned, \n but does not appear in the dependencies of the \ninterface \nghc-6.4.1.20050801: panic! (the `impossible' \nhappened, GHC version 6.4.1.20050801): \n forkM Declaration for staticzumain{v} \n \nPlease report it as a compiler bug to \nglasgow-haskell-bugs@haskell.org, \nor http://sourceforge.net/projects/ghc/. \n \n \nSincerely, \nGour \n \n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/11240Simplifier ticks exhausted on Y combinator2023-09-18T10:01:18Zsweirich@cis.upenn.eduSimplifier ticks exhausted on Y combinatorThe code from this stackoverflow question:
https://programmers.stackexchange.com/questions/215712/type-checking-and-recursive-types-writing-the-y-combinator-in-haskell-ocaml
i.e.
```hs
newtype Mu a = Roll { unroll :: Mu a -> a }
fix :...The code from this stackoverflow question:
https://programmers.stackexchange.com/questions/215712/type-checking-and-recursive-types-writing-the-y-combinator-in-haskell-ocaml
i.e.
```hs
newtype Mu a = Roll { unroll :: Mu a -> a }
fix :: (a -> a) -> a
fix = \f -> (\x -> f (unroll x x)) $ Roll (\x -> f (unroll x x))
```
produces the following output when compiled with
GHC 7.10.2 or 7.10.3:
```
sweirich$ ghc --make Mu.hs
[1 of 1] Compiling Mu ( Mu.hs, Mu.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-apple-darwin):
Simplifier ticks exhausted
When trying UnfoldingDone a_sml
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 4962
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The code compiles with newtype replaces by data.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Simplifier ticks exhausted on Y combinator","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The code from this stackoverflow question: \r\nhttps://programmers.stackexchange.com/questions/215712/type-checking-and-recursive-types-writing-the-y-combinator-in-haskell-ocaml\r\n\r\ni.e.\r\n{{{#!hs\r\nnewtype Mu a = Roll { unroll :: Mu a -> a }\r\n\r\nfix :: (a -> a) -> a\r\nfix = \\f -> (\\x -> f (unroll x x)) $ Roll (\\x -> f (unroll x x))\r\n}}}\r\n\r\nproduces the following output when compiled with \r\nGHC 7.10.2 or 7.10.3:\r\n\r\n{{{\r\nsweirich$ ghc --make Mu.hs\r\n[1 of 1] Compiling Mu ( Mu.hs, Mu.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.3 for x86_64-apple-darwin):\r\n\tSimplifier ticks exhausted\r\n When trying UnfoldingDone a_sml\r\n To increase the limit, use -fsimpl-tick-factor=N (default 100)\r\n If you need to do this, let GHC HQ know, and what factor you needed\r\n To see detailed counts use -ddump-simpl-stats\r\n Total ticks: 4962\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe code compiles with newtype replaces by data.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8833GHC (compilation mode) crashes2023-09-18T10:01:18ZguestGHC (compilation mode) crashes```
module Main where {
newtype Rec a b = Rec {deRec :: Rec a b -> a};
infixl 1 >|>;
infixl 1 <|<;
(>|>) = Rec;
(<|<) (Rec x) = x;
fix f = (\x -> f (x <|< x)) (Rec (\x -> f (x <|< x)));
factorial = fix (\f x -> if x<=1 then 1 else x*...```
module Main where {
newtype Rec a b = Rec {deRec :: Rec a b -> a};
infixl 1 >|>;
infixl 1 <|<;
(>|>) = Rec;
(<|<) (Rec x) = x;
fix f = (\x -> f (x <|< x)) (Rec (\x -> f (x <|< x)));
factorial = fix (\f x -> if x<=1 then 1 else x*f(x-1));
main = do {
x <- getLine;
putStrLn (show (factorial (read x)))
}
}
```
GHC crashes with this error:
```
[1 of 1] Compiling Main ( /Users/iOne/Documents/Test.hs, /Users/iOne/Documents/Test.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for x86_64-apple-darwin):
Simplifier ticks exhausted
When trying UnfoldingDone a_sMx{v} [lid]
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 7121
```
(This works fine in GHCi).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"GHC (compilation mode) crashes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n{{{\r\nmodule Main where {\r\n\r\nnewtype Rec a b = Rec {deRec :: Rec a b -> a};\r\n\r\ninfixl 1 >|>;\r\ninfixl 1 <|<;\r\n(>|>) = Rec;\r\n(<|<) (Rec x) = x;\r\n\r\nfix f = (\\x -> f (x <|< x)) (Rec (\\x -> f (x <|< x)));\r\n\r\nfactorial = fix (\\f x -> if x<=1 then 1 else x*f(x-1));\r\n\r\nmain = do {\r\n x <- getLine;\r\n putStrLn (show (factorial (read x)))\r\n }\r\n\r\n}\r\n}}}\r\n\r\nGHC crashes with this error:\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( /Users/iOne/Documents/Test.hs, /Users/iOne/Documents/Test.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.6.3 for x86_64-apple-darwin):\r\n\tSimplifier ticks exhausted\r\n When trying UnfoldingDone a_sMx{v} [lid]\r\n To increase the limit, use -fsimpl-tick-factor=N (default 100)\r\n If you need to do this, let GHC HQ know, and what factor you needed\r\n To see detailed counts use -ddump-simpl-stats\r\n Total ticks: 7121\r\n}}}\r\n(This works fine in GHCi).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/7369Simplifier bug(?)2023-09-18T10:01:18Zsweirich@cis.upenn.eduSimplifier bug(?)Not sure if it is really a bug. I was playing around with the following infinite loop in GHC 7.6:
```
{-# LANGUAGE GADTs, KindSignatures #-}
data False
data I (c :: * -> *)
data R (c :: *) where
R :: (a (I a) -> False) -> R (I a)
...Not sure if it is really a bug. I was playing around with the following infinite loop in GHC 7.6:
```
{-# LANGUAGE GADTs, KindSignatures #-}
data False
data I (c :: * -> *)
data R (c :: *) where
R :: (a (I a) -> False) -> R (I a)
delta :: R (I R) -> False
delta = \ (R f) -> f (R f)
omega :: False
omega = delta (R delta)
main :: IO ()
main = seq omega (return ())
```
And I got the following result. It's supposed to be an infinite loop, though, so maybe it is ok. GHC 7.4 just hangs on this example.
```
spaceman:haskell sweirich$ ghc inj4.hs
[1 of 1] Compiling Main ( inj4.hs, inj4.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.1 for i386-apple-darwin):
Simplifier ticks exhausted
When trying UnfoldingDone main:Main.$WR{v reV} [gid[DataConWrapper]]
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 5160
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Simplifier bug(?)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Not sure if it is really a bug. I was playing around with the following infinite loop in GHC 7.6:\r\n\r\n{{{\r\n\r\n{-# LANGUAGE GADTs, KindSignatures #-}\r\n\r\ndata False\r\n\r\ndata I (c :: * -> *)\r\n\r\ndata R (c :: *) where\r\n R :: (a (I a) -> False) -> R (I a)\r\n\r\ndelta :: R (I R) -> False\r\ndelta = \\ (R f) -> f (R f)\r\n\r\nomega :: False\r\nomega = delta (R delta)\r\n\r\nmain :: IO ()\r\nmain = seq omega (return ())\r\n\r\n}}}\r\n\r\nAnd I got the following result. It's supposed to be an infinite loop, though, so maybe it is ok. GHC 7.4 just hangs on this example.\r\n\r\n{{{\r\nspaceman:haskell sweirich$ ghc inj4.hs\r\n[1 of 1] Compiling Main ( inj4.hs, inj4.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.6.1 for i386-apple-darwin):\r\n\tSimplifier ticks exhausted\r\n When trying UnfoldingDone main:Main.$WR{v reV} [gid[DataConWrapper]]\r\n To increase the limit, use -fsimpl-tick-factor=N (default 100)\r\n If you need to do this, let GHC HQ know, and what factor you needed\r\n To see detailed counts use -ddump-simpl-stats\r\n Total ticks: 5160\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14003Allow more worker arguments in SpecConstr2023-09-14T10:25:31ZchoenerzsAllow more worker arguments in SpecConstrStarting with GHC 8.2 (rc1 -- head) I noticed that the SpecConstr pass does not always optimize completely with SpecConstr-heavy code.
Setting ```-fmax-worker-args=100``` leads to complete specialization again.
However, given that code ...Starting with GHC 8.2 (rc1 -- head) I noticed that the SpecConstr pass does not always optimize completely with SpecConstr-heavy code.
Setting ```-fmax-worker-args=100``` leads to complete specialization again.
However, given that code annotated with ```SPEC``` should be optimized until no more ```SPEC``` arguments are alive, shouldn't ```callToNewPats``` in ```compiler/specialise/SpecConstr.hs``` specialize \*irrespective\* of the size of the worker argument list?
Code that actually fails to specialize is fairly large, hence no test case -- though I have some files with core output showing insufficient specialization.
(I'd be willing to write a patch for this)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1-rc3 |
| 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":"Allow more worker arguments in SpecConstr","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc3","keywords":["Fusion","JoinPoints,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Starting with GHC 8.2 (rc1 -- head) I noticed that the SpecConstr pass does not always optimize completely with SpecConstr-heavy code.\r\nSetting ```-fmax-worker-args=100``` leads to complete specialization again.\r\n\r\nHowever, given that code annotated with ```SPEC``` should be optimized until no more ```SPEC``` arguments are alive, shouldn't ```callToNewPats``` in ```compiler/specialise/SpecConstr.hs``` specialize *irrespective* of the size of the worker argument list?\r\n\r\nCode that actually fails to specialize is fairly large, hence no test case -- though I have some files with core output showing insufficient specialization.\r\n\r\n(I'd be willing to write a patch for this)","type_of_failure":"OtherFailure","blocking":[]} -->9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/448compiler panic2023-09-11T21:09:58Znobodycompiler panic```
I played with cyclic lists in GHCI.
My session looked like:
% ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | |...```
I played with cyclic lists in GHCI.
My session looked like:
% ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version
6.4, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> let cl = cycle [1..5]
Prelude> take 100 cl
[1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5]
Prelude> let cl = cycle [-2,2]
Prelude> take 100 cl
[-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2]
Prelude> let cl = cycle [-2..2]
Prelude> sum $ take 1000 cl
0
Prelude> sum $ take 10000 cl
0
Prelude> sum $ take 100000 cl
0
Prelude> sum $ take 1000000 cl
*** Exception: stack overflow
Prelude> sum $! take 1000000 cl
*** Exception: stack overflow
Prelude> foldl' (+) 0 $! take 1000000 cl
<interactive>:1:0: Not in scope: `foldl''
Prelude> List.foldl' (+) 0 $! take 1000000 cl
<interactive>:1:0: Not in scope: `List.foldl''
Prelude> Data.List.foldl' (+) 0 $! take 1000000 cl
0
Prelude> Data.List.foldl' (+) 0 $! take 10000000 cl
0
Prelude> Data.List.foldl' (+) 0 $! take 100000000 cl
0
Prelude> Data.List.foldl' (+) 0 $! take 100000000 cl
0
Prelude> Data.List.foldl' (+) 0 $! take 1000000 cl
0
Prelude> Data.List.foldl (+) 0 $! take 1000000 cl
*** Exception: stack overflow
*********************
After that I read "TyingTheKnot" page of HaWiki and
desided to repeat example with double linked list. So i
created file. It already contained some garbage from my
previous experiments but I decided it's irrelevant:
% cat test13.hs
import Control.Exception as C
data DL a = DL {prev_dl::DL, el::a, next_dl::DL}
mkDL :: [a] -> DL a
mkDL xs = let (first,last) = go last xs first
in first
go :: DL a -> [a] -> DL a -> (DL a,DL a)
go prev [] next = (prev, next)
go prev (x:xs) next = let this = DL prev x rest
(rest,fin) = go this xs next
in this
takeF 0 lst = []
takeF n lst = (el lst):takeF (n-1) next_dl lst
takeR 0 lst = []
takeR n lst = (el lst):takeF (n-1) prev_dl lst
main = do putStrLn "hello"
r <- getLine
C.catch (action r) handler
action :: String -> IO()
action r = if (r=="") then C.ioError (userError "input
void")
else print $ r++r
handler :: Exception -> IO()
% cat test14.hs
~/coding/Haskell
% cat test13.hs
~/coding/Haskell
import Control.Exception as C
data DL a = DL {prev_dl::DL, el::a, next_dl::DL}
mkDL :: [a] -> DL a
mkDL xs = let (first,last) = go last xs first
in first
go :: DL a -> [a] -> DL a -> (DL a,DL a)
go prev [] next = (prev, next)
go prev (x:xs) next = let this = DL prev x rest
(rest,fin) = go this xs next
in this
takeF 0 lst = []
takeF n lst = (el lst):takeF (n-1) next_dl lst
takeR 0 lst = []
takeR n lst = (el lst):takeF (n-1) prev_dl lst
main = do putStrLn "hello"
r <- getLine
C.catch (action r) handler
action :: String -> IO()
action r = if (r=="") then C.ioError (userError "input
void")
else print $ r++r
handler :: Exception -> IO()
*** end of test13.hs
After file was ready I tried to load it in my ghci
session and got this:
Prelude> :l test13.hs
Compiling Main ( test13.hs, interpreted )
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
Unify.unifyTauTyLists: mismatched type lists!
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
>
>
Some info about my system.
% uname -a
Linux mausov_comp 2.6.10-as5 #1 Fri Jun 24 13:45:31 MSD
2005 i686 Intel(R) Celeron(R) CPU 2.30GHz GenuineIntel
GNU/Linux
% gcc -v
Reading specs from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs
Configured with:
/var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure
--prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info
--enable-shared --host=i686-pc-linux-gnu
--target=i686-pc-linux-gnu --with-system-zlib
--enable-languages=c,c++ --enable-threads=posix
--enable-long-long --disable-checking
--disable-libunwind-exceptions --enable-cstdio=stdio
--enable-version-specific-runtime-libs
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3
--with-local-prefix=/usr/local --enable-shared
--enable-nls --without-included-gettext
--disable-multilib --enable-__cxa_atexit
--enable-clocale=generic
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1,
ssp-3.3.2-2, pie-8.7.6)
I compiled ghc-6.4 using ghc-6.2.2
My email is v_dmitry@list.ru
Hope that'l help
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedDuplicate |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"compiler panic","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"ResolvedDuplicate","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI played with cyclic lists in GHCI.\nMy session looked like:\n\n% ghci \n \n ___ ___ _\n / _ \\ /\\ /\\/ __(_)\n / /_\\// /_/ / / | | GHC Interactive, version\n6.4, for Haskell 98.\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\n\\____/\\/ /_/\\____/|_| Type :? for help.\n\nLoading package base-1.0 ... linking ... done.\nPrelude> let cl = cycle [1..5]\nPrelude> take 100 cl\n[1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5]\nPrelude> let cl = cycle [-2,2]\nPrelude> take 100 cl\n[-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2]\nPrelude> let cl = cycle [-2..2]\nPrelude> sum $ take 1000 cl\n0\nPrelude> sum $ take 10000 cl\n0\nPrelude> sum $ take 100000 cl\n0\nPrelude> sum $ take 1000000 cl\n*** Exception: stack overflow\nPrelude> sum $! take 1000000 cl\n*** Exception: stack overflow\nPrelude> foldl' (+) 0 $! take 1000000 cl\n\n<interactive>:1:0: Not in scope: `foldl''\nPrelude> List.foldl' (+) 0 $! take 1000000 cl\n\n<interactive>:1:0: Not in scope: `List.foldl''\nPrelude> Data.List.foldl' (+) 0 $! take 1000000 cl\n0\nPrelude> Data.List.foldl' (+) 0 $! take 10000000 cl\n0\nPrelude> Data.List.foldl' (+) 0 $! take 100000000 cl\n0\nPrelude> Data.List.foldl' (+) 0 $! take 100000000 cl\n0\nPrelude> Data.List.foldl' (+) 0 $! take 1000000 cl\n0\nPrelude> Data.List.foldl (+) 0 $! take 1000000 cl\n*** Exception: stack overflow\n\n*********************\n\nAfter that I read \"TyingTheKnot\" page of HaWiki and\ndesided to repeat example with double linked list. So i\ncreated file. It already contained some garbage from my\nprevious experiments but I decided it's irrelevant:\n\n% cat test13.hs \n \nimport Control.Exception as C\n\ndata DL a = DL {prev_dl::DL, el::a, next_dl::DL}\n\nmkDL :: [a] -> DL a\nmkDL xs = let (first,last) = go last xs first\n in first\n\ngo :: DL a -> [a] -> DL a -> (DL a,DL a)\ngo prev [] next = (prev, next) \ngo prev (x:xs) next = let this = DL prev x rest\n (rest,fin) = go this xs next\n in this\n\ntakeF 0 lst = []\ntakeF n lst = (el lst):takeF (n-1) next_dl lst\n\ntakeR 0 lst = []\ntakeR n lst = (el lst):takeF (n-1) prev_dl lst\n\n\n\n\n\nmain = do putStrLn \"hello\"\n r <- getLine\n C.catch (action r) handler\n \naction :: String -> IO()\naction r = if (r==\"\") then C.ioError (userError \"input\nvoid\") \n else print $ r++r\n\nhandler :: Exception -> IO()\n% cat test14.hs \n \n~/coding/Haskell \n% cat test13.hs \n \n~/coding/Haskell \nimport Control.Exception as C\n\ndata DL a = DL {prev_dl::DL, el::a, next_dl::DL}\n\nmkDL :: [a] -> DL a\nmkDL xs = let (first,last) = go last xs first\n in first\n\ngo :: DL a -> [a] -> DL a -> (DL a,DL a)\ngo prev [] next = (prev, next) \ngo prev (x:xs) next = let this = DL prev x rest\n (rest,fin) = go this xs next\n in this\n\ntakeF 0 lst = []\ntakeF n lst = (el lst):takeF (n-1) next_dl lst\n\ntakeR 0 lst = []\ntakeR n lst = (el lst):takeF (n-1) prev_dl lst\n\n\n\n\n\nmain = do putStrLn \"hello\"\n r <- getLine\n C.catch (action r) handler\n \naction :: String -> IO()\naction r = if (r==\"\") then C.ioError (userError \"input\nvoid\") \n else print $ r++r\n\nhandler :: Exception -> IO()\n\n*** end of test13.hs\n\nAfter file was ready I tried to load it in my ghci\nsession and got this:\n\nPrelude> :l test13.hs\nCompiling Main ( test13.hs, interpreted )\nghc-6.4: panic! (the `impossible' happened, GHC version\n6.4):\n Unify.unifyTauTyLists: mismatched type lists!\n\nPlease report it as a compiler bug to\nglasgow-haskell-bugs@haskell.org,\nor http://sourceforge.net/projects/ghc/.\n\n>\n>\n\nSome info about my system.\n\n% uname -a \n \nLinux mausov_comp 2.6.10-as5 #1 Fri Jun 24 13:45:31 MSD\n2005 i686 Intel(R) Celeron(R) CPU 2.30GHz GenuineIntel\nGNU/Linux\n\n% gcc -v \n \nReading specs from\n/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs\nConfigured with:\n/var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure\n--prefix=/usr\n--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3\n--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include\n--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3\n--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man\n--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info\n--enable-shared --host=i686-pc-linux-gnu\n--target=i686-pc-linux-gnu --with-system-zlib\n--enable-languages=c,c++ --enable-threads=posix\n--enable-long-long --disable-checking\n--disable-libunwind-exceptions --enable-cstdio=stdio\n--enable-version-specific-runtime-libs\n--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3\n--with-local-prefix=/usr/local --enable-shared\n--enable-nls --without-included-gettext\n--disable-multilib --enable-__cxa_atexit\n--enable-clocale=generic\nThread model: posix\ngcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1,\nssp-3.3.2-2, pie-8.7.6)\n\nI compiled ghc-6.4 using ghc-6.2.2\n\nMy email is v_dmitry@list.ru\n\nHope that'l help\n\n\n\n\n\n\n\n\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/9817signal handlers in unix are passed garbage when using the signle threaded rts2023-09-09T22:39:58Zrednebsignal handlers in unix are passed garbage when using the signle threaded rtsWhen a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` stru...When a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` struct that was originally passed to the underlying os signal handler. Unfortunately, this only seems to work correctly in the threaded rts. In the single-threaded rts, the buffer contains garbage. This can be demonstrated by the following program:
```hs
import Control.Concurrent
import System.Posix.Signals
main :: IO ()
main = do
wait <- newEmptyMVar
_ <- flip (installHandler sig) Nothing $ CatchInfo $ \info -> do
putStrLn $ "Received a signal " ++ show (siginfoSignal info)
putMVar wait ()
raiseSignal sig
putStrLn $ "Sending myself a signal " ++ show sig
takeMVar wait
where
sig = sigUSR2
```
If you compile the program with the `-threaded` flag then everything works just fine:
```
Sending myself a signal 12
Received a signal 12
```
but without it, the signal handler will print a totaly random signal number:
```
Sending myself a signal 12
Received a signal 138644296
```
I was able to track this down to the function `startSignalHandlers` in `rts/posix/Signals.c`. This function (which is only used by the single threaded rts) allocates a buffer and copies the `siginfo_t` struct to it and then schedules `GHC.Conc.Signal.runHandlers` to be run in a new thread. The problem is that while `GHC.Conc.Signal.runHandlers` expects a `ForeignPtr Word8`, here it is given a `Ptr Word8`. This has two implications: the signal handler is given invalid data, and nobody is deallocating the buffer so we are leaking memory every time a signal is received that has a custom handler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"signal handlers in unix are passed garbage when using the signle threaded rts","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"When a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` struct that was originally passed to the underlying os signal handler. Unfortunately, this only seems to work correctly in the threaded rts. In the single-threaded rts, the buffer contains garbage. This can be demonstrated by the following program:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport System.Posix.Signals\r\n\r\nmain :: IO ()\r\nmain = do\r\n wait <- newEmptyMVar\r\n _ <- flip (installHandler sig) Nothing $ CatchInfo $ \\info -> do\r\n putStrLn $ \"Received a signal \" ++ show (siginfoSignal info)\r\n putMVar wait ()\r\n raiseSignal sig\r\n putStrLn $ \"Sending myself a signal \" ++ show sig\r\n takeMVar wait\r\n where\r\n sig = sigUSR2\r\n}}}\r\n\r\nIf you compile the program with the `-threaded` flag then everything works just fine:\r\n{{{\r\nSending myself a signal 12\r\nReceived a signal 12\r\n}}}\r\nbut without it, the signal handler will print a totaly random signal number:\r\n{{{\r\nSending myself a signal 12\r\nReceived a signal 138644296\r\n}}}\r\n\r\nI was able to track this down to the function `startSignalHandlers` in `rts/posix/Signals.c`. This function (which is only used by the single threaded rts) allocates a buffer and copies the `siginfo_t` struct to it and then schedules `GHC.Conc.Signal.runHandlers` to be run in a new thread. The problem is that while `GHC.Conc.Signal.runHandlers` expects a `ForeignPtr Word8`, here it is given a `Ptr Word8`. This has two implications: the signal handler is given invalid data, and nobody is deallocating the buffer so we are leaking memory every time a signal is received that has a custom handler.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/9248Document -XHaskell98 and -XHaskell2010 in flag reference2023-09-09T20:17:07ZRichard Eisenbergrae@richarde.devDocument -XHaskell98 and -XHaskell2010 in flag reference<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure ...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.2 |
| 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":"Document -XHaskell98 and -XHaskell2010 in flag reference","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"","type_of_failure":"OtherFailure","blocking":[]} -->Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/16Extensionsflags2023-09-07T13:45:20ZaxelkrExtensionsflags```
Hi!
Is it possible to enable the various ghc-extensions
one-by-one via a compilerflag (sth. like --ffi or
--namespaces). The advantage i see is being able to
develop with ghc and use only those extensions hugs or
nhc provide (and no...```
Hi!
Is it possible to enable the various ghc-extensions
one-by-one via a compilerflag (sth. like --ffi or
--namespaces). The advantage i see is being able to
develop with ghc and use only those extensions hugs or
nhc provide (and not exclusively in
-glasgow-extensions).
Thanks & bye,
Axel
```6.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/15Minor Posix.getEffectiveUserID doc-bug2023-09-07T13:45:20ZvolkersfMinor Posix.getEffectiveUserID doc-bug```
"<ProgramListing>
getEffectiveUserID :: IO UserID
</ProgramListing>
</Para>
<Para>
<Function>getRealUserID</Function> ..."
should read
"...<Function>getEffectiveUserID</Function>...".
```
<details><summary>Trac metadata</summar...```
"<ProgramListing>
getEffectiveUserID :: IO UserID
</ProgramListing>
</Para>
<Para>
<Function>getRealUserID</Function> ..."
should read
"...<Function>getEffectiveUserID</Function>...".
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 5.02 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Minor Posix.getEffectiveUserID doc-bug","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"5.02","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\n\"<ProgramListing>\ngetEffectiveUserID :: IO UserID\n</ProgramListing>\n\n</Para>\n\n<Para>\n<Function>getRealUserID</Function> ...\"\n\nshould read\n\n\"...<Function>getEffectiveUserID</Function>...\".\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/14Case missing in garbage collector2023-09-07T13:45:20ZjosefsCase missing in garbage collector```
I'm on a sparc running solaris 2.7. The problem shows
up for a recent ghc built from cvs.
When I compile some files I get the following error
message:
ghc-5.03: fatal error: evacuate: THUNK_SELECTOR:
strange selectee 10
The error g...```
I'm on a sparc running solaris 2.7. The problem shows
up for a recent ghc built from cvs.
When I compile some files I get the following error
message:
ghc-5.03: fatal error: evacuate: THUNK_SELECTOR:
strange selectee 10
The error goes away if I remove the -O flag.
This is especially annoying when bootstrapping the
compiler. Sample module for which this problem arises
are:
PrelWord
PrelCTypes
PrelCString
PrelCError
PrelHandle
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Case missing in garbage collector","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI'm on a sparc running solaris 2.7. The problem shows\nup for a recent ghc built from cvs.\n\nWhen I compile some files I get the following error\nmessage:\nghc-5.03: fatal error: evacuate: THUNK_SELECTOR:\nstrange selectee 10\n\nThe error goes away if I remove the -O flag.\n\nThis is especially annoying when bootstrapping the\ncompiler. Sample module for which this problem arises\nare:\nPrelWord\nPrelCTypes\nPrelCString\nPrelCError\nPrelHandle\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/13ghc 5.02 trats import hiding wrong2023-09-07T13:45:20Znorpanghc 5.02 trats import hiding wrong```
When a module is imported hiding a few symbols, they
are not accessible even by qualifying the name. This
worked in ghc 5.00.2, but does not work in 5.02.
Also, the Haskell 98 report (section 5.3) says:"The
hiding clause only applie...```
When a module is imported hiding a few symbols, they
are not accessible even by qualifying the name. This
worked in ghc 5.00.2, but does not work in 5.02.
Also, the Haskell 98 report (section 5.3) says:"The
hiding clause only applies to unqualified names."
This, is clearly a bug. This is also reported on the
mailing list:
http://www.haskell.org/pipermail/glasgow-haskell-bugs/2001-September/000763.html
I think this is a very serious bug, it causes my
program to not compile and it's not easy to fix it
other than importing one of the modules with the
clashing symbol as "qualified", which is not that nice.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 5.02 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc 5.02 trats import hiding wrong","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"5.02","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen a module is imported hiding a few symbols, they\nare not accessible even by qualifying the name. This\nworked in ghc 5.00.2, but does not work in 5.02.\n\nAlso, the Haskell 98 report (section 5.3) says:\"The\nhiding clause only applies to unqualified names.\"\n\nThis, is clearly a bug. This is also reported on the\nmailing list:\nhttp://www.haskell.org/pipermail/glasgow-haskell-bugs/2001-September/000763.html\n\nI think this is a very serious bug, it causes my\nprogram to not compile and it's not easy to fix it\nother than importing one of the modules with the\nclashing symbol as \"qualified\", which is not that nice.\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobody