GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:18:32Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/311gmp's memory management2019-07-07T19:18:32Zas49gmp's memory managementI assume ghc allocates the lumps of gmp integers still
on ghc's heap, making it impossible (or very awkward)
to interface to C libraries that use gmp themselves. Is
there a chance that you could use the default memory
allocator for lumps...I assume ghc allocates the lumps of gmp integers still
on ghc's heap, making it impossible (or very awkward)
to interface to C libraries that use gmp themselves. Is
there a chance that you could use the default memory
allocator for lumps starting from ghc 6.4? That would
make my life much easier.
Thanks,
Axel.6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/593Cache contents of package.conf in a binary file2019-07-07T19:17:43ZSimon MarlowCache contents of package.conf in a binary fileGHC takes about 0.1 secs to read package.conf each time it starts up. This could be improved by caching package.conf in binary format using GHC's binary serialiser, perhaps in `~/.ghc`.
<details><summary>Trac metadata</summary>
| Trac ...GHC takes about 0.1 secs to read package.conf each time it starts up. This could be improved by caching package.conf in binary format using GHC's binary serialiser, perhaps in `~/.ghc`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cache contents of package.conf in a binary file","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"GHC takes about 0.1 secs to read package.conf each time it starts up. This could be improved by caching package.conf in binary format using GHC's binary serialiser, perhaps in {{{~/.ghc}}}.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/714Inconsistency between handling functional dependencies in class and signature...2019-07-07T19:17:18Zclaus.reinke@talk21.comInconsistency between handling functional dependencies in class and signature constraintsthe user's guide claims
1. 4.2 3. There are no restrictions on the context in a class declaration (which introduces superclasses), except that the class hierarchy must be acyclic.
and we also have
1. 4.3.1 1. Each universally quantif...the user's guide claims
1. 4.2 3. There are no restrictions on the context in a class declaration (which introduces superclasses), except that the class hierarchy must be acyclic.
and we also have
1. 4.3.1 1. Each universally quantified type variable tvi must be reachable from type
suggesting that FDs are taken into account when considering reachability
but that only seems to work for signature, not for class constraints,
as the attached example shows. I wouldn't go so far as claiming this
as a bug, but it prevents an otherwise straightforward encoding of
ATS in FDs (where the superclass encodes the type function, see last
month's discussion on haskell-cafe).
\[grr, there isn't a button for attachment on this form, so I'll paste the code\]
```
{-# OPTIONS_GHC -fglasgow-exts #-}
class C a b | a -> b
class C a b => D a
f :: C a b => a
f = undefined
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.5 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"inconsistency between handling of class and signature constraints","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"the user's guide claims\r\n\r\n7.4.2 3. There are no restrictions on the context in a class declaration (which introduces superclasses), except that the class hierarchy must be acyclic. \r\n\r\nand we also have \r\n\r\n7.4.3.1 1. Each universally quantified type variable tvi must be reachable from type\r\nsuggesting that FDs are taken into account when considering reachability\r\n\r\nbut that only seems to work for signature, not for class constraints,\r\nas the attached example shows. I wouldn't go so far as claiming this\r\nas a bug, but it prevents an otherwise straightforward encoding of\r\nATS in FDs (where the superclass encodes the type function, see last\r\nmonth's discussion on haskell-cafe).\r\n\r\n[grr, there isn't a button for attachment on this form, so I'll paste the code]\r\n{{{\r\n{-# OPTIONS_GHC -fglasgow-exts #-}\r\nclass C a b | a -> b\r\nclass C a b => D a\r\nf :: C a b => a\r\nf = undefined\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/723The package database should be a directory of files instead of a single file2019-07-07T19:17:16ZSimon MarlowThe package database should be a directory of files instead of a single fileThis would help package systems that want to install packages by just unpacking a bunch of files onto the filesystem, amongst other things.
See: [http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html](http://www...This would help package systems that want to install packages by just unpacking a bunch of files onto the filesystem, amongst other things.
See: [http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html](http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"The package database should be a directory of files instead of a single file","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"This would help package systems that want to install packages by just unpacking a bunch of files onto the filesystem, amongst other things.\r\n\r\nSee: [http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html]","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1259Accessing undefined value in DiffArray returns misleading error message2019-07-07T19:14:27ZguestAccessing undefined value in DiffArray returns misleading error message```
Prelude> :m + Data.Array.Diff
Prelude Data.Array.Diff> :t array
array :: (Ix i, IArray a e) => (i, i) -> [(i, e)] -> a i e
Prelude Data.Array.Diff> array (1,1) [] :: DiffArray Int Int
array (1,1) [(1,*** Exception: MArray: undefined ...```
Prelude> :m + Data.Array.Diff
Prelude Data.Array.Diff> :t array
array :: (Ix i, IArray a e) => (i, i) -> [(i, e)] -> a i e
Prelude Data.Array.Diff> array (1,1) [] :: DiffArray Int Int
array (1,1) [(1,*** Exception: MArray: undefined array element
```
Since DiffArray isn't a MArray(it implements IArray), this is misleading. It should either say IArray or better DiffArray: undefined array element.6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1501Panic in RegisterAlloc2019-07-07T19:13:10ZguestPanic in RegisterAllocThe following code causes a panic when compiling with the NCG (i.e. with `-fasm`).
```
stg_ap_0_fast {
bits32 y, x;
c7: y = bits32[x];
goto c7;
}
```
The panic is
```
ghc-6.7.20070620: panic! (the 'impossible' happened...The following code causes a panic when compiling with the NCG (i.e. with `-fasm`).
```
stg_ap_0_fast {
bits32 y, x;
c7: y = bits32[x];
goto c7;
}
```
The panic is
```
ghc-6.7.20070620: panic! (the 'impossible' happened)
(GHC version 6.7.20070620 for i386-unknown-linux):
RegisterAlloc.joinToTargets
```
I do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic in RegisterAlloc","status":"New","operating_system":"Multiple","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code causes a panic when compiling with the NCG (i.e. with {{{-fasm}}}).\r\n\r\n{{{\r\nstg_ap_0_fast {\r\n bits32 y, x;\r\n c7: y = bits32[x];\r\n goto c7;\r\n}\r\n}}}\r\n\r\nThe panic is\r\n{{{\r\nghc-6.7.20070620: panic! (the 'impossible' happened)\r\n (GHC version 6.7.20070620 for i386-unknown-linux):\r\n RegisterAlloc.joinToTargets\r\n}}}\r\n\r\nI do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchbenlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/1633Improve error message for kind mismatches2019-07-07T19:12:29ZguestImprove error message for kind mismatches```
ext :: Ev st Request res -> ServerPart (EvPar res st) Request Result
ext x = Handle $ \req -> do f <- ask
liftIO $ f x req
```
That's from HAppS/Protocols/HTTP.hs
While trying to bend my head around the ...```
ext :: Ev st Request res -> ServerPart (EvPar res st) Request Result
ext x = Handle $ \req -> do f <- ask
liftIO $ f x req
```
That's from HAppS/Protocols/HTTP.hs
While trying to bend my head around the involved types, feeling understanding already creeping somewhere, I, in a desperate attempt, copied the code into my source and changed it to
```
ext' :: Ev st Request res -> ServerPart (EvPar res st) Request Result
ext' x = Handle $ \req -> req
```
hoping to get a clean, expressive and enlightening type error,
I got this:
```
Kind mis-match
Expected kind `* -> *', but `Result' has kind `*'
In the type `ServerPart (EvPar res st) Request Result'
In the type `Ev st Request res
-> ServerPart (EvPar res st) Request Result'
In the type signature for `ext'':
ext' :: Ev st Request res
-> ServerPart (EvPar res st) Request Result
```
Which made me wonder, google and then groan, as I couldn't even figure out what the heck a kind-mismatch is or means, not to mention why ghc points me to the type instead of the code.
My request is for the documentation section "Error messages and their meaning" aka "RTF this if you got that". The terminology of some ghc errors is just begging for references to papers.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Now where does this error come from","status":"New","operating_system":"Unknown","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{\r\next :: Ev st Request res -> ServerPart (EvPar res st) Request Result\r\next x = Handle $ \\req -> do f <- ask\r\n liftIO $ f x req\r\n}}}\r\n\r\nThat's from HAppS/Protocols/HTTP.hs\r\n\r\nWhile trying to bend my head around the involved types, feeling understanding already creeping somewhere, I, in a desperate attempt, copied the code into my source and changed it to\r\n{{{\r\next' :: Ev st Request res -> ServerPart (EvPar res st) Request Result\r\next' x = Handle $ \\req -> req\r\n}}}\r\nhoping to get a clean, expressive and enlightening type error, \r\n\r\nI got this:\r\n{{{\r\n Kind mis-match\r\n Expected kind `* -> *', but `Result' has kind `*'\r\n In the type `ServerPart (EvPar res st) Request Result'\r\n In the type `Ev st Request res\r\n -> ServerPart (EvPar res st) Request Result'\r\n In the type signature for `ext'':\r\n ext' :: Ev st Request res\r\n -> ServerPart (EvPar res st) Request Result\r\n}}}\r\nWhich made me wonder, google and then groan, as I couldn't even figure out what the heck a kind-mismatch is or means, not to mention why ghc points me to the type instead of the code.\r\n\r\nMy request is for the documentation section \"Error messages and their meaning\" aka \"RTF this if you got that\". The terminology of some ghc errors is just begging for references to papers.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1653GHCi ':set' completion does not list all options2019-07-07T19:12:23ZStefan O'Rear <stefanor@cox.net>GHCi ':set' completion does not list all optionsIn particular, the new -X options are missing:
```
stefan@stefans:/tmp$ ghci
GHCi, version 6.7.20070829: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :set -XTyp(TAB TAB, with no effect)
un...In particular, the new -X options are missing:
```
stefan@stefans:/tmp$ ghci
GHCi, version 6.7.20070829: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :set -XTyp(TAB TAB, with no effect)
unrecognised flags: -XTyp
Prelude> :set -XTypeFamilies
Prelude> Leaving GHCi.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | sorear |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi ':set' completion does not list all options","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sorear"],"type":"Bug","description":"In particular, the new -X options are missing:\r\n\r\n{{{\r\nstefan@stefans:/tmp$ ghci\r\nGHCi, version 6.7.20070829: http://www.haskell.org/ghc/ :? for help\r\nLoading package base ... linking ... done.\r\nPrelude> :set -XTyp(TAB TAB, with no effect)\r\nunrecognised flags: -XTyp\r\nPrelude> :set -XTypeFamilies\r\nPrelude> Leaving GHCi.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1673Template Haskell support for type families2019-07-07T19:12:12Zg9ks157k@acme.softbase.orgTemplate Haskell support for type familiesWould it be possible to add support for analyzing and generating type family stuff to Template Haskell?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------...Would it be possible to add support for analyzing and generating type family stuff to Template Haskell?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell support for type families","status":"New","operating_system":"Linux","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"FeatureRequest","description":"Would it be possible to add support for analyzing and generating type family stuff to Template Haskell?","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1735unused binding changes program behaviour2019-07-07T19:11:57ZIan Lynagh <igloo@earth.li>unused binding changes program behaviourI'm not 100% sure this is a bug, but it's certainly surprising. If I add an unused function to my module:
```
#ifdef FOO
rigidTests :: Maybe (Maybe [YesNo])
rigidTests =
mkTest [Elem "No" []] (Just [No])
#endif
```
(mkTest has a type...I'm not 100% sure this is a bug, but it's certainly surprising. If I add an unused function to my module:
```
#ifdef FOO
rigidTests :: Maybe (Maybe [YesNo])
rigidTests =
mkTest [Elem "No" []] (Just [No])
#endif
```
(mkTest has a type signature, and all the datatypes are plain old Haskell 98) then the behaviour of the program changes:
Without the function:
```
$ tar -zxf unused_bind_bug.tar.gz
$ cd unused_bind_bug
$ ghc -cpp --make Main
[1 of 6] Compiling SYBWC.Context ( SYBWC/Context.hs, SYBWC/Context.o )
[2 of 6] Compiling SYBWC.Basics ( SYBWC/Basics.hs, SYBWC/Basics.o )
[3 of 6] Compiling SYBWC.Instances ( SYBWC/Instances.hs, SYBWC/Instances.o )
[4 of 6] Compiling State ( State.hs, State.o )
[5 of 6] Compiling Xml ( Xml.hs, Xml.o )
[6 of 6] Compiling Main ( Main.hs, Main.o )
Linking Main ...
$ ./Main
Nothing
```
With the function:
```
$ tar -zxf unused_bind_bug.tar.gz
$ cd unused_bind_bug
$ ghc -cpp -DFOO --make Main
[1 of 6] Compiling SYBWC.Context ( SYBWC/Context.hs, SYBWC/Context.o )
[2 of 6] Compiling SYBWC.Basics ( SYBWC/Basics.hs, SYBWC/Basics.o )
[3 of 6] Compiling SYBWC.Instances ( SYBWC/Instances.hs, SYBWC/Instances.o )
[4 of 6] Compiling State ( State.hs, State.o )
[5 of 6] Compiling Xml ( Xml.hs, Xml.o )
[6 of 6] Compiling Main ( Main.hs, Main.o )
Linking Main ...
$ ./Main
Stack space overflow: current size 8388608 bytes.
Use `+RTS -Ksize' to increase it.
```
I suspect that the stack overflow is caused by my
```
instance (Xml a, Xml [a]) => Xml [a] where
```
hack to get around #1470 (and if so, that bug is more important to me).
This is with
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.0.20070923
```
but I had the same problem with 6.6.1.
Standalone testcase attached.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"unused binding changes program behaviour","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I'm not 100% sure this is a bug, but it's certainly surprising. If I add an unused function to my module:\r\n{{{\r\n#ifdef FOO\r\nrigidTests :: Maybe (Maybe [YesNo])\r\nrigidTests =\r\n mkTest [Elem \"No\" []] (Just [No])\r\n#endif\r\n}}}\r\n(mkTest has a type signature, and all the datatypes are plain old Haskell 98) then the behaviour of the program changes:\r\n\r\nWithout the function:\r\n{{{\r\n$ tar -zxf unused_bind_bug.tar.gz\r\n$ cd unused_bind_bug\r\n$ ghc -cpp --make Main\r\n[1 of 6] Compiling SYBWC.Context ( SYBWC/Context.hs, SYBWC/Context.o )\r\n[2 of 6] Compiling SYBWC.Basics ( SYBWC/Basics.hs, SYBWC/Basics.o )\r\n[3 of 6] Compiling SYBWC.Instances ( SYBWC/Instances.hs, SYBWC/Instances.o )\r\n[4 of 6] Compiling State ( State.hs, State.o )\r\n[5 of 6] Compiling Xml ( Xml.hs, Xml.o )\r\n[6 of 6] Compiling Main ( Main.hs, Main.o )\r\nLinking Main ...\r\n$ ./Main\r\nNothing\r\n}}}\r\n\r\nWith the function:\r\n{{{\r\n$ tar -zxf unused_bind_bug.tar.gz\r\n$ cd unused_bind_bug\r\n$ ghc -cpp -DFOO --make Main\r\n[1 of 6] Compiling SYBWC.Context ( SYBWC/Context.hs, SYBWC/Context.o )\r\n[2 of 6] Compiling SYBWC.Basics ( SYBWC/Basics.hs, SYBWC/Basics.o )\r\n[3 of 6] Compiling SYBWC.Instances ( SYBWC/Instances.hs, SYBWC/Instances.o )\r\n[4 of 6] Compiling State ( State.hs, State.o )\r\n[5 of 6] Compiling Xml ( Xml.hs, Xml.o )\r\n[6 of 6] Compiling Main ( Main.hs, Main.o )\r\nLinking Main ...\r\n$ ./Main\r\nStack space overflow: current size 8388608 bytes.\r\nUse `+RTS -Ksize' to increase it.\r\n}}}\r\n\r\nI suspect that the stack overflow is caused by my\r\n{{{\r\ninstance (Xml a, Xml [a]) => Xml [a] where\r\n}}}\r\nhack to get around #1470 (and if so, that bug is more important to me).\r\n\r\nThis is with\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.8.0.20070923\r\n}}}\r\nbut I had the same problem with 6.6.1.\r\n\r\nStandalone testcase attached.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/1792-ddump-minimal-imports breaks qualified imports (import...as)2019-07-07T19:11:42Zguest-ddump-minimal-imports breaks qualified imports (import...as)When using the `-ddump-minimal-imports` option on a Haskell file, it breaks qualified imports.
Ie, suppose one has a line in a file thus:
```
import qualified Data.ByteString as B (putStr, readFile)
```
Using `-ddump-minimal-imports`...When using the `-ddump-minimal-imports` option on a Haskell file, it breaks qualified imports.
Ie, suppose one has a line in a file thus:
```
import qualified Data.ByteString as B (putStr, readFile)
```
Using `-ddump-minimal-imports` will give you something like this:
```
import Data.ByteString(B.putStr, B.readFile)
```
There are 3 things wrong here:
- `putStr` and `readFile` should not be renamed thus, as obviously `Data.ByteString` has nothing under those names
- `Data.ByteString` is no longer being imported under a different name, so all function uses relying on `B.putStr` etc. will break
- Finally, it's just ugly to have no spaces between the last letter of the module's name and the opening parenthesis.
I see this behavior under GHC 6.6.1, and asl of \#haskell tells me he duplicated the import problem using GHCi version 6.8.0.20071019.
--
gwern6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1811liberate case needs an independent threshold2019-07-07T19:11:38ZSimon Marlowliberate case needs an independent thresholdThe liberate-case pass (on with -O2) is causing code duplication in the definition of `hPutStr` in `GHC.IO`.
This accounts for 10% of the 25% increase in binary sizes I'm seeing in 6.8.1. We'll be using `-fno-liberate-case` when buildin...The liberate-case pass (on with -O2) is causing code duplication in the definition of `hPutStr` in `GHC.IO`.
This accounts for 10% of the 25% increase in binary sizes I'm seeing in 6.8.1. We'll be using `-fno-liberate-case` when building libraries for the distributions (it's already off in the default build, since the default `GhcLibHcOpts` uses `-O`).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"liberate case causes code duplication","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The liberate-case pass (on with -O2) is causing code duplication in the definition of `hPutStr` in `GHC.IO`.\r\n\r\nThis accounts for 10% of the 25% increase in binary sizes I'm seeing in 6.8.1. We'll be using `-fno-liberate-case` when building libraries for the distributions (it's already off in the default build, since the default `GhcLibHcOpts` uses `-O`).","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1856Improve error message for mutally recursive modules2019-07-07T19:11:25ZguestImprove error message for mutally recursive modulesWhen I am trying to compile the following modules:
```
File: Files.hs
module Files where
import SecMonad
File: Lattice.hs
module Lattice where
File: Ref.hs
module Ref where
import SecMonad
File: Screen.hs
module Screen where...When I am trying to compile the following modules:
```
File: Files.hs
module Files where
import SecMonad
File: Lattice.hs
module Lattice where
File: Ref.hs
module Ref where
import SecMonad
File: Screen.hs
module Screen where
import SecMonad
File: Sec.hs
module Sec where
import Lattice
File: SecLib.hs (OBSERVE HERE THAT THE NAME OF THE
MODULE IS NOT THE SAME AS THE FILE)
module SecMonad where
import Lattice
import Sec
import SecMonad
import Files
import Screen
import Ref
File: SecMonad.hs
module SecMonad where
import Lattice
import Sec
```
I got the message:
```
ale@localhost ~/Sec7 $ ghci SecLib.hs -fglasgow-exts
GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
[1 of 4] Compiling Lattice ( Lattice.hs, interpreted )
[2 of 4] Compiling Sec ( Sec.hs, interpreted )
[3 of 4] Compiling SecIO ( SecIO.hs, interpreted )
Module imports form a cycle for modules:
main:Resources imports: Files Lattice
main:Files imports: SecMonad SecIO Lattice
main:SecMonad
imports: Resources Ref Screen Files SecMonad SecIO Sec Lattice
main:Ref imports: SecMonad SecIO Sec Lattice Data.IORef
main:Screen imports: SecMonad SecIO Lattice
Failed, modules loaded: SecIO, Lattice, Sec.
*SecIO>
```
I think that it would be of great help if the compiler can check if the names of the modules match the name of the files. It took me a while to discover the stupid mistake, and I believe that, when you have a large number of mobules, it might be difficult to find this bug. So, a simple check would help a lot in this situation.
That is it!6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1868Exception fails all exception predicates2019-07-07T19:11:21ZOrphiException fails all exception predicatesAttempting to operate on a file with an invalid filename (e.g., "C:\\C:\\") yields an "invalid parameter" exception. This exception appears to be a kind of `IOError`, yet it fails all 8 exception predicates.
```
test :: IO x -> IO ()
te...Attempting to operate on a file with an invalid filename (e.g., "C:\\C:\\") yields an "invalid parameter" exception. This exception appears to be a kind of `IOError`, yet it fails all 8 exception predicates.
```
test :: IO x -> IO ()
test a = do
catch (a >> return ()) examine
examine :: IOError -> IO ()
examine ioe = do
putStrLn $ "isAlreadyExistsError___" ++ show (isAlreadyExistsError ioe)
putStrLn $ "isDoesNotExistError " ++ show (isDoesNotExistError ioe)
putStrLn $ "isAlreadyInUseError____" ++ show (isAlreadyInUseError ioe)
putStrLn $ "isFullError " ++ show (isFullError ioe)
putStrLn $ "isEOFError_____________" ++ show (isEOFError ioe)
putStrLn $ "isIllegalOperation " ++ show (isIllegalOperation ioe)
putStrLn $ "isPermissionError______" ++ show (isPermissionError ioe)
putStrLn $ "isUserError " ++ show (isUserError ioe)
```
Now try, for example, `test (openFile "C:\\C:\\" ReadMode)`. All 8 predicates above return False. (However, if you do, say, `test (error "no")`, the `catch` function doesn't trap it at all because it's not an `IOError`.)
I was under the impression this is what the "illegal operation" type was for?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.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":"Exception fails all exception predicates","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attempting to operate on a file with an invalid filename (e.g., \"C:\\C:\\\") yields an \"invalid parameter\" exception. This exception appears to be a kind of `IOError`, yet it fails all 8 exception predicates.\r\n\r\n{{{\r\ntest :: IO x -> IO ()\r\ntest a = do\r\n catch (a >> return ()) examine\r\n\r\nexamine :: IOError -> IO ()\r\nexamine ioe = do\r\n putStrLn $ \"isAlreadyExistsError___\" ++ show (isAlreadyExistsError ioe)\r\n putStrLn $ \"isDoesNotExistError \" ++ show (isDoesNotExistError ioe)\r\n putStrLn $ \"isAlreadyInUseError____\" ++ show (isAlreadyInUseError ioe)\r\n putStrLn $ \"isFullError \" ++ show (isFullError ioe)\r\n putStrLn $ \"isEOFError_____________\" ++ show (isEOFError ioe)\r\n putStrLn $ \"isIllegalOperation \" ++ show (isIllegalOperation ioe)\r\n putStrLn $ \"isPermissionError______\" ++ show (isPermissionError ioe)\r\n putStrLn $ \"isUserError \" ++ show (isUserError ioe)\r\n}}}\r\n\r\nNow try, for example, `test (openFile \"C:\\\\C:\\\\\" ReadMode)`. All 8 predicates above return False. (However, if you do, say, `test (error \"no\")`, the `catch` function doesn't trap it at all because it's not an `IOError`.)\r\n\r\nI was under the impression this is what the \"illegal operation\" type was for?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1886GHC API should preserve and provide access to comments2019-07-07T19:11:16Zclaus.reinke@talk21.comGHC API should preserve and provide access to commentsone class of applications of the `GHC API` are program transformations (refactoring, source to source optimisation, partial evaluation, ..) and code layouters (pretty-print, 2html, syntax-colouring, ..). but, even ignoring layout, parsin...one class of applications of the `GHC API` are program transformations (refactoring, source to source optimisation, partial evaluation, ..) and code layouters (pretty-print, 2html, syntax-colouring, ..). but, even ignoring layout, parsing and pretty-printing with the `GHC API` does not currently preserve the source (nor does it generate syntactically valid code..).
consider this simple test: we want to parse a module, then pretty-print it (we might want to adjust the layout, or switch between layout and explicit braces). applying the attached code to itself gives this result:
```
$ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace -package ghc -e main API_Layout.hs
module API where
import DynFlags
import GHC
import PprTyThing
import System.Process
import System.IO
import Outputable
import Data.Maybe
instance Num () where
[]
[]
{ fromInteger = undefined }
mode = CompManager
compileToCoreFlag = False
writer >| cmd = runInteractiveCommand cmd >>= \ (i, o, e, p) -> writer i
cmd |> reader = runInteractiveCommand cmd >>= \ (i, o, e, p) -> reader o
ghcDir = "c:/fptools/ghc/compiler/stage2/ghc-inplace --print-libdir"
|>
(fmap dropLineEnds . hGetContents)
where
dropLineEnds = filter (not . (`elem` "\r\n"))
main = defaultErrorHandler defaultDynFlags
$ do s <- newSession . Just =<< ghcDir
flags <- getSessionDynFlags s
(flags, _) <- parseDynamicFlags flags ["-package ghc"]
GHC.defaultCleanupHandler flags
$ do setSessionDynFlags s (flags {hscTarget = HscInterpreted})
addTarget s =<< guessTarget "API_Layout.hs" Nothing
load s LoadAllTargets
prelude <- findModule s (mkModuleName "Prelude") Nothing
usermod <- findModule s (mkModuleName "API") Nothing
setContext s [usermod] [prelude]
Just cm <- checkModule s (mkModuleName "API") compileToCoreFlag
unqual <- getPrintUnqual s
printForUser stdout unqual $ ppr $ parsedSource cm
```
this has lost all comments, including pragmas, and is syntactically invalid!
one suggestion, to avoid upsetting the rest of `ghc`, would be to preserve the comments, with source locations, but to separate them from the main abstract syntax tree. there would also need to be a way to link ast fragments to comments, which might be slightly awkward. perhaps something like:
```
-- was there a comment just preceeding the current AST fragment?
commentsBefore :: AST -> Maybe String
-- was there a comment immediately following the current AST fragment?
commentsAfter :: AST -> Maybe String
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"GHC API should preserve and provide access to comments","status":"New","operating_system":"Unknown","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"one class of applications of the `GHC API` are program transformations (refactoring, source to source optimisation, partial evaluation, ..) and code layouters (pretty-print, 2html, syntax-colouring, ..). but, even ignoring layout, parsing and pretty-printing with the `GHC API` does not currently preserve the source (nor does it generate syntactically valid code..).\r\n\r\nconsider this simple test: we want to parse a module, then pretty-print it (we might want to adjust the layout, or switch between layout and explicit braces). applying the attached code to itself gives this result:\r\n{{{\r\n$ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace -package ghc -e main API_Layout.hs\r\nmodule API where\r\nimport DynFlags\r\nimport GHC\r\nimport PprTyThing\r\nimport System.Process\r\nimport System.IO\r\nimport Outputable\r\nimport Data.Maybe\r\ninstance Num () where\r\n []\r\n []\r\n { fromInteger = undefined }\r\nmode = CompManager\r\ncompileToCoreFlag = False\r\nwriter >| cmd = runInteractiveCommand cmd >>= \\ (i, o, e, p) -> writer i\r\ncmd |> reader = runInteractiveCommand cmd >>= \\ (i, o, e, p) -> reader o\r\nghcDir = \"c:/fptools/ghc/compiler/stage2/ghc-inplace --print-libdir\"\r\n |>\r\n (fmap dropLineEnds . hGetContents)\r\n where\r\n dropLineEnds = filter (not . (`elem` \"\\r\\n\"))\r\nmain = defaultErrorHandler defaultDynFlags\r\n $ do s <- newSession . Just =<< ghcDir\r\n flags <- getSessionDynFlags s\r\n (flags, _) <- parseDynamicFlags flags [\"-package ghc\"]\r\n GHC.defaultCleanupHandler flags\r\n $ do setSessionDynFlags s (flags {hscTarget = HscInterpreted})\r\n addTarget s =<< guessTarget \"API_Layout.hs\" Nothing\r\n load s LoadAllTargets\r\n prelude <- findModule s (mkModuleName \"Prelude\") Nothing\r\n usermod <- findModule s (mkModuleName \"API\") Nothing\r\n setContext s [usermod] [prelude]\r\n Just cm <- checkModule s (mkModuleName \"API\") compileToCoreFlag\r\n unqual <- getPrintUnqual s\r\n printForUser stdout unqual $ ppr $ parsedSource cm\r\n\r\n}}}\r\nthis has lost all comments, including pragmas, and is syntactically invalid!\r\n\r\none suggestion, to avoid upsetting the rest of `ghc`, would be to preserve the comments, with source locations, but to separate them from the main abstract syntax tree. there would also need to be a way to link ast fragments to comments, which might be slightly awkward. perhaps something like:\r\n{{{\r\n-- was there a comment just preceeding the current AST fragment?\r\ncommentsBefore :: AST -> Maybe String\r\n-- was there a comment immediately following the current AST fragment?\r\ncommentsAfter :: AST -> Maybe String\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1954Incorrect "Defined but not used" warning when using GeneralizedNewtypeDeriving2019-07-07T19:10:54ZmagnusIncorrect "Defined but not used" warning when using GeneralizedNewtypeDerivingWhen compiling
```
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# OPTIONS_GHC -Wall -Werror #-}
module Bug(P, runP) where
import Control.Monad.Identity(Identity, runIdentity)
newtype P a = P { unP :: Identity a } deriving Monad
runP...When compiling
```
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# OPTIONS_GHC -Wall -Werror #-}
module Bug(P, runP) where
import Control.Monad.Identity(Identity, runIdentity)
newtype P a = P { unP :: Identity a } deriving Monad
runP :: P a -> a
runP = runIdentity . unP
```
I get
```
Bug.hs:7:14: Warning: Defined but not used: data constructor `P'
```
although the constructor is used in the derived Monad instance. This is obviously not a show stopper, but it forces me to rewrite what to me looks like an OK program if I want to stick to the given OPTIONS_GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect \"Defined but not used\" warning when using GeneralizedNewtypeDeriving","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"When compiling\r\n{{{\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-}\r\n{-# OPTIONS_GHC -Wall -Werror #-}\r\nmodule Bug(P, runP) where\r\n\r\nimport Control.Monad.Identity(Identity, runIdentity)\r\n\r\nnewtype P a = P { unP :: Identity a } deriving Monad\r\n\r\nrunP :: P a -> a\r\nrunP = runIdentity . unP\r\n}}}\r\nI get \r\n{{{\r\nBug.hs:7:14: Warning: Defined but not used: data constructor `P'\r\n}}}\r\nalthough the constructor is used in the derived Monad instance. This is obviously not a show stopper, but it forces me to rewrite what to me looks like an OK program if I want to stick to the given OPTIONS_GHC.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1969enormous compile times2019-07-07T19:10:50Zduncanenormous compile timesSome modules cause ghc to take a very very long time (and a lot of memory) to compile, even without optimisations.
Here is an example of a module that takes almost forever to compile. The `WASH/HTML/HTMLMonad98.hs` module from WASH-2.12...Some modules cause ghc to take a very very long time (and a lot of memory) to compile, even without optimisations.
Here is an example of a module that takes almost forever to compile. The `WASH/HTML/HTMLMonad98.hs` module from WASH-2.12 http://www.informatik.uni-freiburg.de/\~thiemann/haskell/WASH/
It is a 185k, 5,800 line module consisting almost entirely of data, class and instance declarations.
It might be interesting to use this module as a test case to profile ghc's front end to see if there are any obvious inefficiencies or unecessary non-linear algorithms.
`WASH/HTML/HTMLPrelude.hs` is almost as bad. Between the two of them they push the overall compile time for WASH to several minutes with -O0 and nearly half an hour with -O1. GHC's memory use while compiling WASH also grows to over 300Mb with -O0 and over 600Mb with -O1 (on a 64bit box).
All in all, WASH is an excellent stress test for GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"enormous compile times","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Task","description":"Some modules cause ghc to take a very very long time (and a lot of memory) to compile, even without optimisations.\r\n\r\nHere is an example of a module that takes almost forever to compile. The {{{WASH/HTML/HTMLMonad98.hs}}} module from WASH-2.12 http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/\r\n\r\nIt is a 185k, 5,800 line module consisting almost entirely of data, class and instance declarations.\r\n\r\nIt might be interesting to use this module as a test case to profile ghc's front end to see if there are any obvious inefficiencies or unecessary non-linear algorithms.\r\n\r\n{{{WASH/HTML/HTMLPrelude.hs}}} is almost as bad. Between the two of them they push the overall compile time for WASH to several minutes with -O0 and nearly half an hour with -O1. GHC's memory use while compiling WASH also grows to over 300Mb with -O0 and over 600Mb with -O1 (on a 64bit box).\r\n\r\nAll in all, WASH is an excellent stress test for GHC.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2006unreachable GADT pattern clauses show up as warnings with -Wall2019-09-30T21:34:56Zryaniunreachable GADT pattern clauses show up as warnings with -WallIn the following code, there is a line commented out. With it commented out, I get the following warning:
```
patternbug.hs:10:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `interpret': Patterns not mat...In the following code, there is a line commented out. With it commented out, I get the following warning:
```
patternbug.hs:10:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `interpret': Patterns not matched: EVar
```
With it uncommented, I get the following compiler error:
```
patternbug.hs:11:10:
Inaccessible case alternative: Can't match types `()' and `(a, vs)'
In the pattern: EVar
In the definition of `interpret':
interpret EVar = error "unreachable"
```
The exhaustive pattern-matching algorithm should ignore unreachable cases in its analysis.
```
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE GADTs #-}
module PatternBug where
data Expr a vs where
EPrim :: String -> a -> Expr a vs
EVar :: Expr a (a,vs)
interpret :: Expr a () -> a
interpret (EPrim _ a) = a
-- interpret EVar = error "unreachable"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ryani.spam@gmail.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"unreachable GADT pattern clauses show up as warnings with -Wall","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["ryani.spam@gmail.com"],"type":"Bug","description":"In the following code, there is a line commented out. With it commented out, I get the following warning:\r\n\r\n{{{\r\npatternbug.hs:10:0:\r\n Warning: Pattern match(es) are non-exhaustive\r\n\t In the definition of `interpret': Patterns not matched: EVar\r\n}}}\r\n\r\nWith it uncommented, I get the following compiler error:\r\n{{{\r\npatternbug.hs:11:10:\r\n Inaccessible case alternative: Can't match types `()' and `(a, vs)'\r\n In the pattern: EVar\r\n In the definition of `interpret':\r\n\tinterpret EVar = error \"unreachable\"\r\n}}}\r\n\r\nThe exhaustive pattern-matching algorithm should ignore unreachable cases in its analysis.\r\n\r\n{{{\r\n{-# OPTIONS_GHC -Wall #-}\r\n{-# LANGUAGE GADTs #-}\r\nmodule PatternBug where\r\n\r\ndata Expr a vs where\r\n EPrim :: String -> a -> Expr a vs\r\n EVar :: Expr a (a,vs)\r\n\r\ninterpret :: Expr a () -> a\r\ninterpret (EPrim _ a) = a\r\n-- interpret EVar = error \"unreachable\"\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2089reading the package db is slow2019-07-07T19:10:16Zduncanreading the package db is slowWith a large number of registered packages it takes ages for ghc to read the package db and it does this every time it is run so it starts to add up.
I have a rather fast x86-64 machine and 160 registered packages. Here are some timings...With a large number of registered packages it takes ages for ghc to read the package db and it does this every time it is run so it starts to add up.
I have a rather fast x86-64 machine and 160 registered packages. Here are some timings:
```
$ time ghc-pkg list > /dev/null
user 0m1.164s
$ time ghc -c does-not-exist.c 2> /dev/null
real 0m0.612s
$ time hsc2hs does-exist.hsc --cflag=--version 2> /dev/null
user 0m0.572s
```
So since cabal configure involves running all of the above it starts to take a while:
```
$ time cabal configure
Configuring cabal-install-0.4.3...
real 0m2.241s
user 0m1.916s
```
The obvious solution is to use a binary cache of the package db containing the most commonly needed mappings like module name -\> package etc.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"reading the package db is slow","status":"New","operating_system":"Multiple","component":"Driver","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With a large number of registered packages it takes ages for ghc to read the package db and it does this every time it is run so it starts to add up.\r\n\r\nI have a rather fast x86-64 machine and 160 registered packages. Here are some timings:\r\n\r\n{{{\r\n$ time ghc-pkg list > /dev/null\r\nuser 0m1.164s\r\n\r\n$ time ghc -c does-not-exist.c 2> /dev/null\r\nreal 0m0.612s\r\n\r\n$ time hsc2hs does-exist.hsc --cflag=--version 2> /dev/null\r\nuser 0m0.572s\r\n}}}\r\n\r\nSo since cabal configure involves running all of the above it starts to take a while:\r\n{{{\r\n$ time cabal configure\r\nConfiguring cabal-install-0.4.3...\r\nreal 0m2.241s\r\nuser 0m1.916s\r\n}}}\r\n\r\nThe obvious solution is to use a binary cache of the package db containing the most commonly needed mappings like module name -> package etc.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2191A way to programmatically cause GHC to report the cost center stack associate...2019-07-07T19:09:47ZSamuel BronsonA way to programmatically cause GHC to report the cost center stack associated with a valueI find that I often wish I could ask GHC to tell me "where did \*that\* value come from?" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this in...I find that I often wish I could ask GHC to tell me "where did \*that\* value come from?" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this information as instructed by a running program. Perhaps:
reportCssFor :: a -\> b -\> b
I wouldn't really have any desire to use this on thunks, since when I want to do this it is usually because I don't like the value (i.e. it isn't in the right normal form), and to know this I must already have evaluated it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"A way to programmatically cause GHC to report the cost center stack associated with a value","status":"New","operating_system":"Unknown","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"I find that I often wish I could ask GHC to tell me \"where did *that* value come from?\" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this information as instructed by a running program. Perhaps:\r\n\r\nreportCssFor :: a -> b -> b\r\n\r\nI wouldn't really have any desire to use this on thunks, since when I want to do this it is usually because I don't like the value (i.e. it isn't in the right normal form), and to know this I must already have evaluated it.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2197GHCi doesn't work when built with way=p2019-07-07T19:09:45ZSamuel BronsonGHCi doesn't work when built with way=pI don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well...I don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well...
```
naesten@hydrogen:~/hacking/haskell/ghc-hashedrepo% ./compiler/stage2/ghc-inplace_p --interactive
GHCi, version 6.9.20080305: http://www.haskell.org/ghc/ :? for help
ghc_p-6.9.20080305: /home/naesten/hacking/haskell/ghc-hashedrepo/libraries/ghc-prim/dist/build/HSghc-prim-0.1.o: unknown symbol `traceCcszh_fast'
Loading package ghc-prim ... linking ... ghc_p-6.9.20080305: unable to load package `ghc-prim'
```6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2203TFs in class instances heads2019-07-07T19:09:44ZManuel M T ChakravartyTFs in class instances headsGanesh posted the following example on haskell-cafe:
```
{-# LANGUAGE ScopedTypeVariables, TypeFamilies, FlexibleInstances #-}
module Test1a where
class Foo a where
type TheFoo a
foo :: TheFoo a -> a
foo' :: a -> Int
class B...Ganesh posted the following example on haskell-cafe:
```
{-# LANGUAGE ScopedTypeVariables, TypeFamilies, FlexibleInstances #-}
module Test1a where
class Foo a where
type TheFoo a
foo :: TheFoo a -> a
foo' :: a -> Int
class Bar b where
bar :: b -> Int
instance Foo a => Bar (Either a (TheFoo a)) where
bar (Left a) = foo' a
bar (Right b) = foo' (foo b :: a)
instance Foo Int where
type TheFoo Int = Int
foo = id
foo' = id
val :: Either Int Int
val = Left 5
res :: Int
res = bar val
```
It fails to type check as the type of `bar` cannot be inferred. However, GHC should reject the instance due to the TF in the head despite `FlexibleInstances`.
Moreover, the corrected code
```
{-# LANGUAGE ScopedTypeVariables, TypeFamilies, UndecidableInstances #-}
module Test1a where
class Foo a where
type TheFoo a
foo :: TheFoo a -> a
foo' :: a -> Int
class Bar b where
bar :: b -> Int
instance (b ~ TheFoo a, Foo a) => Bar (Either a b) where
bar (Left a) = foo' a
bar (Right b) = foo' (foo b :: a)
instance Foo Int where
type TheFoo Int = Int
foo = id
foo' = id
val :: Either Int Int
val = Left 5
res :: Int
res = bar val
```
requires `UndecidableInstances`, although it shouldn't.
We should be able to allow equalities of the form `tv ~ F tv1 .. tvn` with tv and tvi being distinct type variables without requiring `UndecidableInstances`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ganesh@earth.li |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"TFs in class instances heads","status":"New","operating_system":"Multiple","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"chak"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":["ganesh@earth.li"],"type":"Bug","description":"Ganesh posted the following example on haskell-cafe:\r\n{{{\r\n{-# LANGUAGE ScopedTypeVariables, TypeFamilies, FlexibleInstances #-}\r\n\r\nmodule Test1a where\r\n\r\nclass Foo a where\r\n type TheFoo a\r\n foo :: TheFoo a -> a\r\n foo' :: a -> Int\r\n\r\nclass Bar b where\r\n bar :: b -> Int\r\n\r\ninstance Foo a => Bar (Either a (TheFoo a)) where\r\n bar (Left a) = foo' a\r\n bar (Right b) = foo' (foo b :: a)\r\n\r\ninstance Foo Int where\r\n type TheFoo Int = Int\r\n foo = id\r\n foo' = id\r\n\r\nval :: Either Int Int\r\nval = Left 5\r\n\r\nres :: Int\r\nres = bar val\r\n}}}\r\nIt fails to type check as the type of `bar` cannot be inferred. However, GHC should reject the instance due to the TF in the head despite `FlexibleInstances`.\r\n\r\nMoreover, the corrected code\r\n{{{\r\n{-# LANGUAGE ScopedTypeVariables, TypeFamilies, UndecidableInstances #-}\r\n\r\nmodule Test1a where\r\n\r\nclass Foo a where\r\n type TheFoo a\r\n foo :: TheFoo a -> a\r\n foo' :: a -> Int\r\n\r\nclass Bar b where\r\n bar :: b -> Int\r\n\r\ninstance (b ~ TheFoo a, Foo a) => Bar (Either a b) where\r\n bar (Left a) = foo' a\r\n bar (Right b) = foo' (foo b :: a)\r\n\r\ninstance Foo Int where\r\n type TheFoo Int = Int\r\n foo = id\r\n foo' = id\r\n\r\nval :: Either Int Int\r\nval = Left 5\r\n\r\nres :: Int\r\nres = bar val\r\n}}}\r\nrequires `UndecidableInstances`, although it shouldn't.\r\n\r\nWe should be able to allow equalities of the form `tv ~ F tv1 .. tvn` with tv and tvi being distinct type variables without requiring `UndecidableInstances`.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchManuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2210ghci gets into weird state if loading a module with a bad LANGUAGE pragma2019-07-07T19:09:42Zbosghci gets into weird state if loading a module with a bad LANGUAGE pragmaTry loading a module like this into `ghci`:
```
{-# LANGUAGE BreakMe #-}
```
This gets `ghci` into an odd wedged state, with a strange prompt, in which `Prelude` is not available.
<details><summary>Trac metadata</summary>
| Trac fiel...Try loading a module like this into `ghci`:
```
{-# LANGUAGE BreakMe #-}
```
This gets `ghci` into an odd wedged state, with a strange prompt, in which `Prelude` is not available.
<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 | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"ghci gets into weird state if loading a module with a bad LANGUAGE pragma","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Try loading a module like this into `ghci`:\r\n\r\n{{{\r\n{-# LANGUAGE BreakMe #-}\r\n}}}\r\n\r\nThis gets `ghci` into an odd wedged state, with a strange prompt, in which `Prelude` is not available.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2211Installing latest GHC-6.8.2 stable: pwd with floating point exception2019-07-07T19:09:42ZguestInstalling latest GHC-6.8.2 stable: pwd with floating point exceptionI tried to install
> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080410-i386-unknown-linux.tar.bz2
on Kubuntu. It was reported to be build properly:
> http://www.haskell.org/pipermail/cvs-ghc/2008-April/041915.html
but I ...I tried to install
> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080410-i386-unknown-linux.tar.bz2
on Kubuntu. It was reported to be build properly:
> http://www.haskell.org/pipermail/cvs-ghc/2008-April/041915.html
but I get:
```
/tmp/ghc-6.8.2.20080410> ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
Which we'll further canonicalise into: i386-unknown-linux
checking for path to top of build tree... configure: error: cannot determine current directory
```
From other reports I got to know that this might have to do with the custom 'pwd' of ghc installation. Indeed I get:
```
/tmp/ghc-6.8.2.20080410> ./utils/pwd/pwd
Floating point exception
```
<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":"Installing latest GHC-6.8.2 stable: pwd with floating point exception","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":"I tried to install\r\n http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080410-i386-unknown-linux.tar.bz2\r\non Kubuntu. It was reported to be build properly:\r\n http://www.haskell.org/pipermail/cvs-ghc/2008-April/041915.html\r\nbut I get:\r\n\r\n{{{\r\n/tmp/ghc-6.8.2.20080410> ./configure\r\nchecking build system type... i686-pc-linux-gnu\r\nchecking host system type... i686-pc-linux-gnu\r\nchecking target system type... i686-pc-linux-gnu\r\nWhich we'll further canonicalise into: i386-unknown-linux\r\nchecking for path to top of build tree... configure: error: cannot determine current directory\r\n}}}\r\n\r\nFrom other reports I got to know that this might have to do with the custom 'pwd' of ghc installation. Indeed I get:\r\n\r\n{{{\r\n/tmp/ghc-6.8.2.20080410> ./utils/pwd/pwd\r\nFloating point exception\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2226duplicate samples in heap profiling (-hc) output on 6.8.22019-07-07T19:09:38Zclemensduplicate samples in heap profiling (-hc) output on 6.8.2I tried to catch a bug in xmonad by using heap profiling (-hc). Compiled all libraries with -prof -auto-all. The .hp output seems broken as samples are written to the file multiple times. See attached example of xmonad.
<details><summar...I tried to catch a bug in xmonad by using heap profiling (-hc). Compiled all libraries with -prof -auto-all. The .hp output seems broken as samples are written to the file multiple times. See attached example of xmonad.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"duplicate samples in heap profiling (-hc) output on 6.8.2","status":"New","operating_system":"Unknown","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried to catch a bug in xmonad by using heap profiling (-hc). Compiled all libraries with -prof -auto-all. The .hp output seems broken as samples are written to the file multiple times. See attached example of xmonad. ","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2443@EnableWin32DLLs@ in mk/config.mk2019-07-07T19:08:33Zrurban@EnableWin32DLLs@ in mk/config.mk```
@EnableWin32DLLs@ should be temp. disabled also.
[EnableWin32DLLs.patch
rurban@x-ray.at**20080713112530] hunk ./mk/config.mk.in 410
-DLLized=@EnableWin32DLLs@
+#temp. disabled. was @EnableWin32DLLs@
+DLLized=NO
``````
@EnableWin32DLLs@ should be temp. disabled also.
[EnableWin32DLLs.patch
rurban@x-ray.at**20080713112530] hunk ./mk/config.mk.in 410
-DLLized=@EnableWin32DLLs@
+#temp. disabled. was @EnableWin32DLLs@
+DLLized=NO
```6.12 branchrurbanrurbanhttps://gitlab.haskell.org/ghc/ghc/-/issues/2493implement proposed Qualified Operator syntax2019-07-07T19:08:20ZIsaac Dupreeimplement proposed Qualified Operator syntaxproposed for haskell', we like the idea, we should implement it.
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
http://thread.gmane.org/gmane.comp.lang.haskell.prime/2439/focus=2449
Need to decide on a name for ...proposed for haskell', we like the idea, we should implement it.
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
http://thread.gmane.org/gmane.comp.lang.haskell.prime/2439/focus=2449
Need to decide on a name for the LANGUAGE flag (hmm.. !SanerQualifiedOperators?), as well as implementing the modified syntax( as a toggle-able thing).
while searching the wiki to see if the ticket existed already, I found an old ticket of mine that seems mentioned an instance of the exact syntax we've proposed, #1383 :-)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"implement proposed Qualified Operator syntax","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"proposed for haskell', we like the idea, we should implement it.\r\n\r\nhttp://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators\r\n\r\nhttp://thread.gmane.org/gmane.comp.lang.haskell.prime/2439/focus=2449\r\n\r\nNeed to decide on a name for the LANGUAGE flag (hmm.. !SanerQualifiedOperators?), as well as implementing the modified syntax( as a toggle-able thing).\r\n\r\nwhile searching the wiki to see if the ticket existed already, I found an old ticket of mine that seems mentioned an instance of the exact syntax we've proposed, #1383 :-)","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2500Unrecognised pragma complained about twice2019-07-07T19:08:18ZSimon Peyton JonesUnrecognised pragma complained about twice```
module Foo where
{-# FOO wibble #-}
f x = x
```
We get two complaints:
```
c:/simonpj/darcs/HEAD/ghc/stage1-inplace/ghc -c Foo.hs
Foo.hs:3:0: Unrecognised pragma
Foo.hs:3:0: Unrecognised pragma
sh-2.04$
```
<details><summary>T...```
module Foo where
{-# FOO wibble #-}
f x = x
```
We get two complaints:
```
c:/simonpj/darcs/HEAD/ghc/stage1-inplace/ghc -c Foo.hs
Foo.hs:3:0: Unrecognised pragma
Foo.hs:3:0: Unrecognised pragma
sh-2.04$
```
<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 | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Unrecognised pragma complained about twice","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{\r\nmodule Foo where\r\n\r\n{-# FOO wibble #-}\r\nf x = x\r\n}}}\r\nWe get two complaints:\r\n{{{\r\nc:/simonpj/darcs/HEAD/ghc/stage1-inplace/ghc -c Foo.hs\r\n\r\nFoo.hs:3:0: Unrecognised pragma\r\n\r\nFoo.hs:3:0: Unrecognised pragma\r\nsh-2.04$ \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2561Using "ITstring !FastString" in Lexer.x goes wrong (internal error: stg_ap_v_...2019-07-07T19:07:57ZIan Lynagh <igloo@earth.li>Using "ITstring !FastString" in Lexer.x goes wrong (internal error: stg_ap_v_ret)With this patch:
```
hunk ./compiler/parser/Lexer.x 535
+#if __GLASGOW_HASKELL__ >= 609
+ | ITstring !FastString
+#else
hunk ./compiler/parser/Lexer.x 539
+#endif
```
something goes wrong. The first sign, when validating, is that ...With this patch:
```
hunk ./compiler/parser/Lexer.x 535
+#if __GLASGOW_HASKELL__ >= 609
+ | ITstring !FastString
+#else
hunk ./compiler/parser/Lexer.x 539
+#endif
```
something goes wrong. The first sign, when validating, is that `timeout` is broken:
```
timeout: internal error: stg_ap_v_ret
(GHC version 6.9.20080902 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
If you use the python timeout program instead then you find a few tests fail, e.g.:
```
testsuite/tests/ghc-regress/codeGen/should_run$ '/home/ian/ghc/darcs/st2/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dx86_64_unknown_linux -dno-debug-output -o cg052 cg052.hs -O -fasm -funbox-strict-fields
testsuite/tests/ghc-regress/codeGen/should_run$ ./cg052
ok
cg052: internal error: stg_ap_v_ret
(GHC version 6.9.20080902 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
zsh: abort ./cg052
```
I'm not sure what's going on, but it seems to be repeatable.
<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 | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Using \"ITstring !FastString\" in Lexer.x goes wrong (internal error: stg_ap_v_ret)","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"With this patch:\r\n{{{\r\nhunk ./compiler/parser/Lexer.x 535\r\n+#if __GLASGOW_HASKELL__ >= 609\r\n+ | ITstring !FastString\r\n+#else\r\nhunk ./compiler/parser/Lexer.x 539\r\n+#endif\r\n}}}\r\nsomething goes wrong. The first sign, when validating, is that `timeout` is broken:\r\n{{{\r\ntimeout: internal error: stg_ap_v_ret\r\n (GHC version 6.9.20080902 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\nIf you use the python timeout program instead then you find a few tests fail, e.g.:\r\n{{{\r\ntestsuite/tests/ghc-regress/codeGen/should_run$ '/home/ian/ghc/darcs/st2/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dx86_64_unknown_linux -dno-debug-output -o cg052 cg052.hs -O -fasm -funbox-strict-fields\r\ntestsuite/tests/ghc-regress/codeGen/should_run$ ./cg052 \r\nok\r\ncg052: internal error: stg_ap_v_ret\r\n (GHC version 6.9.20080902 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nzsh: abort ./cg052\r\n}}}\r\nI'm not sure what's going on, but it seems to be repeatable.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2608Direct support for unit tests in Cabal2019-07-07T19:07:43ZKari PahulaDirect support for unit tests in CabalI'm passing along Debian wishlist bug [\#458495](http://bugs.debian.org/458495) for your consideration. The patch is for version 6.6.1 and it won't apply cleanly on HEAD, but I can adapt it to HEAD if you think it's worth having.
I didn...I'm passing along Debian wishlist bug [\#458495](http://bugs.debian.org/458495) for your consideration. The patch is for version 6.6.1 and it won't apply cleanly on HEAD, but I can adapt it to HEAD if you think it's worth having.
I didn't look overly much if something like this has been already implemented. My apologies if this is just more noise.
----
It would be nice if there was a simple way to build and run tests for
Cabalized packages.
Cabal provides a "test" target, but by default it does nothing.
Furthermore, you can't really build test cases using the Cabal
infrastructure, since any executables that you list get installed.
Searching on Google for how to integrate a test suite into Cabal turns
up suggestions such as "make a system() call from runTests to
The attached patch adds two new flags to the build information for
executables and libraries:
```
* do-not-install: if set to True, keeps an executable that it's set on
from being installed. This is necessary to keep test suites from
ending up in $prefix/bin, but may be useful for other build-time
utilities.
* is-test: if set to True on an executable, the executable will be
invoked by the "test" target of the setup script. Note that this
doesn't attempt to be at all smart about building the executable(s);
it just blindly invokes the test command(s) and returns a failure if
any of them fail.
```
The patch should be fairly straightforward. The need to do suppression
of installing executables in compiler-specific code is a bit ugly;
this could maybe be cleaned up with an equivalent to withExe that drops
non-installed executables and by writing and using a similar routine for
libraries.
This also changes the API of Cabal: runTests now takes an integer as
its first argument, indicating the verbosity level provided as an
argument on the command-line. The Boolean that was passed before
didn't have any purpose I could see and was always False, so it
shouldn't be hard to adapt existing code to this change. On the other
hand, the API can be preserved by just hard-coding a verbosity level.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Direct support for unit tests in Cabal","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I'm passing along Debian wishlist bug [http://bugs.debian.org/458495 #458495] for your consideration. The patch is for version 6.6.1 and it won't apply cleanly on HEAD, but I can adapt it to HEAD if you think it's worth having.\r\n\r\nI didn't look overly much if something like this has been already implemented. My apologies if this is just more noise.\r\n\r\n----\r\nIt would be nice if there was a simple way to build and run tests for\r\nCabalized packages.\r\n\r\nCabal provides a \"test\" target, but by default it does nothing.\r\nFurthermore, you can't really build test cases using the Cabal\r\ninfrastructure, since any executables that you list get installed.\r\nSearching on Google for how to integrate a test suite into Cabal turns\r\nup suggestions such as \"make a system() call from runTests to \r\n\r\nThe attached patch adds two new flags to the build information for\r\nexecutables and libraries:\r\n\r\n{{{\r\n * do-not-install: if set to True, keeps an executable that it's set on\r\n from being installed. This is necessary to keep test suites from\r\n ending up in $prefix/bin, but may be useful for other build-time\r\n utilities.\r\n\r\n * is-test: if set to True on an executable, the executable will be\r\n invoked by the \"test\" target of the setup script. Note that this\r\n doesn't attempt to be at all smart about building the executable(s);\r\n it just blindly invokes the test command(s) and returns a failure if\r\n any of them fail.\r\n}}}\r\n\r\nThe patch should be fairly straightforward. The need to do suppression\r\nof installing executables in compiler-specific code is a bit ugly;\r\nthis could maybe be cleaned up with an equivalent to withExe that drops\r\nnon-installed executables and by writing and using a similar routine for\r\nlibraries.\r\n\r\nThis also changes the API of Cabal: runTests now takes an integer as\r\nits first argument, indicating the verbosity level provided as an\r\nargument on the command-line. The Boolean that was passed before\r\ndidn't have any purpose I could see and was always False, so it\r\nshouldn't be hard to adapt existing code to this change. On the other\r\nhand, the API can be preserved by just hard-coding a verbosity level.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2611print022 fails2019-07-07T19:07:42ZIan Lynagh <igloo@earth.li>print022 failsprint022 fails:
```
-test = C 1 32 1.2 1.23 'x' 1 1.2 1.23
+test = C 1 32 1.2 1.23 'x' (I# 1) (F# 1.2) (D# 1.23)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------...print022 fails:
```
-test = C 1 32 1.2 1.23 'x' 1 1.2 1.23
+test = C 1 32 1.2 1.23 'x' (I# 1) (F# 1.2) (D# 1.23)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"print022 fails","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"print022 fails:\r\n{{{\r\n-test = C 1 32 1.2 1.23 'x' 1 1.2 1.23\r\n+test = C 1 32 1.2 1.23 'x' (I# 1) (F# 1.2) (D# 1.23)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchmnislaihmnislaihhttps://gitlab.haskell.org/ghc/ghc/-/issues/2613configure should summarize important results at the end of its run2019-07-07T19:07:42Zclaus.reinke@talk21.comconfigure should summarize important results at the end of its run`./configure` in ghc head produces a lot of output, including lots of detailed checks that tend to scroll away the more major results near the beginning.
It would be useful if the most important points (which ghc/gcc/tools/.. are going ...`./configure` in ghc head produces a lot of output, including lots of detailed checks that tend to scroll away the more major results near the beginning.
It would be useful if the most important points (which ghc/gcc/tools/.. are going to be used; which features are disabled because of missing tools) were summarized at the end of the configure run.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.9 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"configure should summarize important results at the end of its run","status":"New","operating_system":"Unknown","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"`./configure` in ghc head produces a lot of output, including lots of detailed checks that tend to scroll away the more major results near the beginning.\r\n\r\nIt would be useful if the most important points (which ghc/gcc/tools/.. are going to be used; which features are disabled because of missing tools) were summarized at the end of the configure run.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2677Detection of TF instance conflict depends on instance order2019-07-07T19:07:23ZreinerpDetection of TF instance conflict depends on instance orderWith 6.10 RC1, the following code compiles without complaint:
```
{-# OPTIONS -fglasgow-exts #-}
module OverlapTest where
type family A x
type instance A a = Bool
type instance A Int = Char
```
even though the overlapping instances "A...With 6.10 RC1, the following code compiles without complaint:
```
{-# OPTIONS -fglasgow-exts #-}
module OverlapTest where
type family A x
type instance A a = Bool
type instance A Int = Char
```
even though the overlapping instances "A a" and "A Int" conflict. Reordering the instances to
```
{-# OPTIONS -fglasgow-exts #-}
module OverlapTest where
type family A x
type instance A Int = Char
type instance A a = Bool
```
correctly doesn't compile, complaining about conflicting instances.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Detection of TF instance conflict depends on instance order","status":"New","operating_system":"Unknown/Multiple","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":["TF","conflict","instance"],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"With 6.10 RC1, the following code compiles without complaint:\r\n{{{\r\n{-# OPTIONS -fglasgow-exts #-}\r\nmodule OverlapTest where\r\n\r\ntype family A x\r\ntype instance A a = Bool\r\ntype instance A Int = Char\r\n}}}\r\neven though the overlapping instances \"A a\" and \"A Int\" conflict. Reordering the instances to\r\n{{{\r\n{-# OPTIONS -fglasgow-exts #-}\r\nmodule OverlapTest where\r\n\r\ntype family A x\r\ntype instance A Int = Char\r\ntype instance A a = Bool\r\n}}}\r\ncorrectly doesn't compile, complaining about conflicting instances.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchManuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2682Keep going after failed search for module in current directory2019-07-07T19:07:22ZajdKeep going after failed search for module in current directoryInside a package's source directory after the package has been installed, if I type `ghci` and then `import MODNAME`, where MODNAME is a module in the package, GHCi throws an error: `module main:MODNAME is not loaded`, even though MODNAM...Inside a package's source directory after the package has been installed, if I type `ghci` and then `import MODNAME`, where MODNAME is a module in the package, GHCi throws an error: `module main:MODNAME is not loaded`, even though MODNAME is part of the package (in its system-installed state). The desired behavior, I think, is to keep on going and realize that MODNAME is a module in an already-installed package, and then load that.
<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":"Keep going after failed search for module in current directory","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":"Inside a package's source directory after the package has been installed, if I type {{{ghci}}} and then {{{import MODNAME}}}, where MODNAME is a module in the package, GHCi throws an error: {{{module main:MODNAME is not loaded}}}, even though MODNAME is part of the package (in its system-installed state). The desired behavior, I think, is to keep on going and realize that MODNAME is a module in an already-installed package, and then load that.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2689make maintainer-clean leaves generated files and directories2019-07-07T19:07:20Zclaus.reinke@talk21.commake maintainer-clean leaves generated files and directoriesBefore updating my GHC head repo, I did `make maintainer-clean`. Recalling some recent bugs triggered by left-over files, I thought I'd try and look for them in advance, and found rather a lot of them.
For the purpose, I've got an alter...Before updating my GHC head repo, I did `make maintainer-clean`. Recalling some recent bugs triggered by left-over files, I thought I'd try and look for them in advance, and found rather a lot of them.
For the purpose, I've got an alternative boringfile (attached) that just hides subrepos and stuff I don't suspect at the moment.
```
$ make maintainer-clean
$ cp .darcs-boring .darcs-boring.safe
$ cp .darcs-subrepos .darcs-boring
$ darcs cha --last=1
Sat Oct 4 18:53:51 GMT Daylight Time 2008 Ian Lynagh <igloo@earth.li>
* prep-bin-dist-mingw complains if it finds a bad version of windres
$ darcs wh -s
M ./.darcs-boring -211 +18
M ./darcs-all -2 +68
$ darcs wh -l >mystuff/leftovers.log
-- output attached
$ cp .darcs-boring.safe .darcs-boring
```
Perhaps this could be made into an automated test, so that leftovers don't keep piling up until someone trips over them (though you probably don't want the buildbots to clean their results away, in case you need to inspect them later)?
See also the related ticket on `make distclean`, #1693.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"make maintainer-clean leaves generated files and directories","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Before updating my GHC head repo, I did `make maintainer-clean`. Recalling some recent bugs triggered by left-over files, I thought I'd try and look for them in advance, and found rather a lot of them. \r\n\r\nFor the purpose, I've got an alternative boringfile (attached) that just hides subrepos and stuff I don't suspect at the moment.\r\n{{{\r\n$ make maintainer-clean\r\n\r\n$ cp .darcs-boring .darcs-boring.safe\r\n$ cp .darcs-subrepos .darcs-boring\r\n\r\n$ darcs cha --last=1\r\nSat Oct 4 18:53:51 GMT Daylight Time 2008 Ian Lynagh <igloo@earth.li>\r\n * prep-bin-dist-mingw complains if it finds a bad version of windres\r\n\r\n$ darcs wh -s\r\nM ./.darcs-boring -211 +18\r\nM ./darcs-all -2 +68\r\n\r\n$ darcs wh -l >mystuff/leftovers.log\r\n-- output attached\r\n\r\n$ cp .darcs-boring.safe .darcs-boring\r\n}}}\r\n\r\nPerhaps this could be made into an automated test, so that leftovers don't keep piling up until someone trips over them (though you probably don't want the buildbots to clean their results away, in case you need to inspect them later)?\r\n\r\nSee also the related ticket on `make distclean`, #1693.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2699broken pipe errors are too noisy2019-07-07T19:07:17ZBertram Felgenhauerbroken pipe errors are too noisyThe following program
```
main = mapM_ print fibs where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
```
produces this output when piped through `head` on a shell:
```
# ./a.out | head -n 1
0
a.out: <stdout>: commitAndReleaseBuffer: re...The following program
```
main = mapM_ print fibs where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
```
produces this output when piped through `head` on a shell:
```
# ./a.out | head -n 1
0
a.out: <stdout>: commitAndReleaseBuffer: resource vanished (Broken pipe)
#
```
The final error message is annoying. It would be nice if the RTS suppressed it.
<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":"broken pipe errors are too noisy","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":"The following program\r\n\r\n{{{\r\nmain = mapM_ print fibs where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)\r\n}}}\r\n\r\nproduces this output when piped through {{{head}}} on a shell:\r\n\r\n{{{\r\n# ./a.out | head -n 1\r\n0\r\na.out: <stdout>: commitAndReleaseBuffer: resource vanished (Broken pipe)\r\n#\r\n}}}\r\n\r\nThe final error message is annoying. It would be nice if the RTS suppressed it.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2712Parallel GC scheduling problems2019-07-07T19:07:13ZSimon MarlowParallel GC scheduling problemsThe parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor...The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently.
Really we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks.
If this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parallel GC scheduling problems","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.10.2","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently.\r\n\r\nReally we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks.\r\n\r\nIf this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2729Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version)2021-11-02T09:27:33ZmnislaihStuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version)This is the end of the -v output without -O2
```
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Fri Sep 5 21:53:18 CEST 2008
ms_mod = main:XMonad.StackSet,
ms_imps = [Data.Map, Data.List, Data.Li...This is the end of the -v output without -O2
```
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Fri Sep 5 21:53:18 CEST 2008
ms_mod = main:XMonad.StackSet,
ms_imps = [Data.Map, Data.List, Data.List, Data.Maybe, Prelude]
ms_srcimps = []
}]
compile: input file ./XMonad/StackSet.hs
Created temporary directory: /tmp/ghc14177_0
*** Checking old interface for main:XMonad.StackSet:
[1 of 1] Compiling XMonad.StackSet ( XMonad/StackSet.hs, XMonad/StackSet.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 7813
*** Simplify:
Result size = 6756
Result size = 6535
Result size = 6511
Result size = 6511
*** Tidy Core:
Result size = 6511
*** CorePrep:
```
1. ..and then it stops, consuming full CPU and constant (\~27MB) memory.
The output with -O2 is slightly different
```
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Fri Sep 5 21:53:18 CEST 2008
ms_mod = main:XMonad.StackSet,
ms_imps = [Data.Map, Data.List, Data.List, Data.Maybe, Prelude]
ms_srcimps = []
}]
compile: input file ./XMonad/StackSet.hs
Created temporary directory: /tmp/ghc14187_0
*** Checking old interface for main:XMonad.StackSet:
[1 of 1] Compiling XMonad.StackSet ( XMonad/StackSet.hs, XMonad/StackSet.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 7808
*** Simplify:
Result size = 6281
Result size = 6189
Result size = 6189
*** Specialise:
Result size = 6189
*** Float out (not lambdas, not constants):
```
I waited for about 30 minutes before killing it.
This problem doesn't seem to be present in the 6.10 branch, so the culprit must be a relatively recent patch.
<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 | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"This is the end of the -v output without -O2\r\n{{{\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = Fri Sep 5 21:53:18 CEST 2008\r\n ms_mod = main:XMonad.StackSet,\r\n ms_imps = [Data.Map, Data.List, Data.List, Data.Maybe, Prelude]\r\n ms_srcimps = []\r\n }]\r\ncompile: input file ./XMonad/StackSet.hs\r\nCreated temporary directory: /tmp/ghc14177_0\r\n*** Checking old interface for main:XMonad.StackSet:\r\n[1 of 1] Compiling XMonad.StackSet ( XMonad/StackSet.hs, XMonad/StackSet.o )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Desugar:\r\n Result size = 7813\r\n*** Simplify:\r\n Result size = 6756\r\n Result size = 6535\r\n Result size = 6511\r\n Result size = 6511\r\n*** Tidy Core:\r\n Result size = 6511\r\n*** CorePrep:\r\n}}}\r\n...and then it stops, consuming full CPU and constant (~27MB) memory.\r\n\r\nThe output with -O2 is slightly different\r\n{{{\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = Fri Sep 5 21:53:18 CEST 2008\r\n ms_mod = main:XMonad.StackSet,\r\n ms_imps = [Data.Map, Data.List, Data.List, Data.Maybe, Prelude]\r\n ms_srcimps = []\r\n }]\r\ncompile: input file ./XMonad/StackSet.hs\r\nCreated temporary directory: /tmp/ghc14187_0\r\n*** Checking old interface for main:XMonad.StackSet:\r\n[1 of 1] Compiling XMonad.StackSet ( XMonad/StackSet.hs, XMonad/StackSet.o )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Desugar:\r\n Result size = 7808\r\n*** Simplify:\r\n Result size = 6281\r\n Result size = 6189\r\n Result size = 6189\r\n*** Specialise:\r\n Result size = 6189\r\n*** Float out (not lambdas, not constants):\r\n}}}\r\n\r\nI waited for about 30 minutes before killing it.\r\nThis problem doesn't seem to be present in the 6.10 branch, so the culprit must be a relatively recent patch.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2759Data.Generics.ConstrRep isn't general enough2019-07-07T19:07:00ZguestData.Generics.ConstrRep isn't general enoughThe type ConstrRep in Data.Generics is used to represent constructors for types.
The FloatConstr constructor is the one used for all kinds of floating point primitives.
But FloatConstr has an argument of type Double. This limits the prim...The type ConstrRep in Data.Generics is used to represent constructors for types.
The FloatConstr constructor is the one used for all kinds of floating point primitives.
But FloatConstr has an argument of type Double. This limits the primitive floating point types to those that are accurately representable as a Double.
In other places in Haskell where an accurate and generic floating point value is needed the type Rational is used. It should be used here too.
<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":"Data.Generics.ConstrRep isn't general enough","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":"The type ConstrRep in Data.Generics is used to represent constructors for types.\r\nThe FloatConstr constructor is the one used for all kinds of floating point primitives.\r\nBut FloatConstr has an argument of type Double. This limits the primitive floating point types to those that are accurately representable as a Double.\r\nIn other places in Haskell where an accurate and generic floating point value is needed the type Rational is used. It should be used here too.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchdreixeldreixelhttps://gitlab.haskell.org/ghc/ghc/-/issues/2760Data.Generics.Basics.mkNorepType spelled wrong2019-07-07T19:07:00ZguestData.Generics.Basics.mkNorepType spelled wrongTo be consistent with the constructor name NoRep this function should be mkNoRepType.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| V...To be consistent with the constructor name NoRep this function should be mkNoRepType.
<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":"Data.Generics.Basics.mkNoreptype spelled wrong","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":"To be consistent with the constructor name NoRep this function should be mkNoRepType.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchdreixeldreixelhttps://gitlab.haskell.org/ghc/ghc/-/issues/2767Type family bug ?2019-07-07T19:06:58ZtestType family bug ?I get this error when compiling a program with associated type families:
```
$ ghc --make Queens_v2.hs
[1 of 5] Compiling Domain ( Domain.hs, Domain.o )
[2 of 5] Compiling Solver ( Solver.hs, Solver.o )
[3 of 5] Com...I get this error when compiling a program with associated type families:
```
$ ghc --make Queens_v2.hs
[1 of 5] Compiling Domain ( Domain.hs, Domain.o )
[2 of 5] Compiling Solver ( Solver.hs, Solver.o )
[3 of 5] Compiling FD ( FD.hs, FD.o )
[4 of 5] Compiling SearchTree ( SearchTree.hs, SearchTree.o )
[5 of 5] Compiling Main ( Queens_v2.hs, Queens_v2.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
idInfo co{v a629} [tv]
```
Tom Schrijvers
<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 | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type family bug ?","status":"New","operating_system":"MacOS X","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I get this error when compiling a program with associated type families:\r\n{{{\r\n$ ghc --make Queens_v2.hs \r\n[1 of 5] Compiling Domain ( Domain.hs, Domain.o )\r\n[2 of 5] Compiling Solver ( Solver.hs, Solver.o )\r\n[3 of 5] Compiling FD ( FD.hs, FD.o )\r\n[4 of 5] Compiling SearchTree ( SearchTree.hs, SearchTree.o )\r\n[5 of 5] Compiling Main ( Queens_v2.hs, Queens_v2.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tidInfo co{v a629} [tv]\r\n}}}\r\n\r\nTom Schrijvers","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchManuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2800deprecated OPTIONS flag warnings generated during dep chasing?2019-07-07T19:06:47Zduncandeprecated OPTIONS flag warnings generated during dep chasing?It would appear that warnings about deprecated flags used in `OPTIONS` pragmas get spat out during the early pre-processing and module chasing phase when they would not be generated after pre-processing.
`ghc --make` has to scan each mo...It would appear that warnings about deprecated flags used in `OPTIONS` pragmas get spat out during the early pre-processing and module chasing phase when they would not be generated after pre-processing.
`ghc --make` has to scan each module to look for options and language extensions to know if it has to run cpp. At this stage it cannot of course run cpp so it does not necessarily get the full set of options and extensions since some may be conditional. So it should not at this stage generate any warnings since they may be suppressed by later cpp-conditional flags.
Another possible theory is that it generates the warnings before having read all the `OPTIONS` flags so the later warning suppression is ineffective. Unfortunately we have to put them in the order we do for compatibility with older versions of ghc.
Here's an example out of Cabal:
```
{-# OPTIONS -cpp -fffi #-}
-- OPTIONS required for ghc-6.4.x, and must appear first
{-# LANGUAGE CPP, ForeignFunctionInterface #-}
{-# OPTIONS_GHC -cpp -fffi #-}
{-# OPTIONS_NHC98 -cpp #-}
{-# OPTIONS_JHC -fcpp -fffi #-}
#if __GLASGOW_HASKELL__ >= 610
{-# OPTIONS_GHC -fno-warn-deprecated-flags #-}
-- the ghc flag -fffi is deprecated in ghc-6.10. We're
-- supposed to use the LANGUAGE pragmas instead. However
-- we have to maintain compatibility with older ghc versions
-- so we (try to) suppress this warning.
#endif
```
What we're trying to do here is make it work with ghc-6.4 + and not generate any warnings with the latest ghc. This seems quite tricky to do.
To support ghc-6.4 we have to put the `OPTIONS` pragma first, since it apparently only looks at the first couple lines. We then use the compiler-specific `OPTIONS` pragmas. In particular these are needed for ghc-6.6. For ghc-6.8 and later we can use the `LANGUAGE` pragmas.
In ghc-6.10 the `-fffi` option is deprecated. However we cannot conditionally compile the `OPTIONS -cpp -fffi` since ghc needs to see the `-cpp` to know that it has to cpp the module. Making the `OPTIONS -cpp` unconditional and the `OPTIONS -cpp -fffi` conditional does not work with ghc-6.4.
So instead we try suppressing the warning. We cannot do that unconditionally since the flag is only present in newer ghc versions. However if we do suppress conditionally then ghc still warns anyway, presumably because it is warning on the first pass rather than in the pass after running cpp.
All in all it's a bit tricky to do right. Indeed I cannot currently see a way to make it work at all without generating warnings. The sledgehammer would be to put a flag in the .cabal file and have it apply to all modules, however that does not prevent the warning happening during Cabal bootstrapping which uses plain `ghc --make`.
<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":"deprecated OPTIONS flag warnings generated during dep chasing?","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":"It would appear that warnings about deprecated flags used in `OPTIONS` pragmas get spat out during the early pre-processing and module chasing phase when they would not be generated after pre-processing.\r\n\r\n`ghc --make` has to scan each module to look for options and language extensions to know if it has to run cpp. At this stage it cannot of course run cpp so it does not necessarily get the full set of options and extensions since some may be conditional. So it should not at this stage generate any warnings since they may be suppressed by later cpp-conditional flags.\r\n\r\nAnother possible theory is that it generates the warnings before having read all the `OPTIONS` flags so the later warning suppression is ineffective. Unfortunately we have to put them in the order we do for compatibility with older versions of ghc.\r\n\r\nHere's an example out of Cabal:\r\n\r\n{{{\r\n{-# OPTIONS -cpp -fffi #-}\r\n-- OPTIONS required for ghc-6.4.x, and must appear first\r\n{-# LANGUAGE CPP, ForeignFunctionInterface #-}\r\n{-# OPTIONS_GHC -cpp -fffi #-}\r\n{-# OPTIONS_NHC98 -cpp #-}\r\n{-# OPTIONS_JHC -fcpp -fffi #-}\r\n#if __GLASGOW_HASKELL__ >= 610\r\n{-# OPTIONS_GHC -fno-warn-deprecated-flags #-}\r\n-- the ghc flag -fffi is deprecated in ghc-6.10. We're\r\n-- supposed to use the LANGUAGE pragmas instead. However\r\n-- we have to maintain compatibility with older ghc versions\r\n-- so we (try to) suppress this warning.\r\n#endif\r\n}}}\r\n\r\nWhat we're trying to do here is make it work with ghc-6.4 + and not generate any warnings with the latest ghc. This seems quite tricky to do.\r\n\r\nTo support ghc-6.4 we have to put the `OPTIONS` pragma first, since it apparently only looks at the first couple lines. We then use the compiler-specific `OPTIONS` pragmas. In particular these are needed for ghc-6.6. For ghc-6.8 and later we can use the `LANGUAGE` pragmas.\r\n\r\nIn ghc-6.10 the `-fffi` option is deprecated. However we cannot conditionally compile the `OPTIONS -cpp -fffi` since ghc needs to see the `-cpp` to know that it has to cpp the module. Making the `OPTIONS -cpp` unconditional and the `OPTIONS -cpp -fffi` conditional does not work with ghc-6.4. \r\n\r\nSo instead we try suppressing the warning. We cannot do that unconditionally since the flag is only present in newer ghc versions. However if we do suppress conditionally then ghc still warns anyway, presumably because it is warning on the first pass rather than in the pass after running cpp.\r\n\r\nAll in all it's a bit tricky to do right. Indeed I cannot currently see a way to make it work at all without generating warnings. The sledgehammer would be to put a flag in the .cabal file and have it apply to all modules, however that does not prevent the warning happening during Cabal bootstrapping which uses plain `ghc --make`.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2809Patching libffi fails in Solaris2019-07-07T19:06:44Zrl@cse.unsw.edu.auPatching libffi fails in SolarisThis is what happens:
```
gmake[1]: Entering directory `/home/rl/ghc/ghc/libffi'
rm -f -rf libffi-3.0.6 build
/usr/sfw/bin/gtar -zxf libffi-3.0.6.tar.gz
mv libffi-3.0.6 build
chmod +x ln
patch -p0 < libffi-dllize-3.0.6.patch
Looks lik...This is what happens:
```
gmake[1]: Entering directory `/home/rl/ghc/ghc/libffi'
rm -f -rf libffi-3.0.6 build
/usr/sfw/bin/gtar -zxf libffi-3.0.6.tar.gz
mv libffi-3.0.6 build
chmod +x ln
patch -p0 < libffi-dllize-3.0.6.patch
Looks like a unified context diff.
Hunk #5 failed at line 344.
Hunk #6 failed at line 165.
Hunk #7 failed at line 33.
3 out of 7 hunks failed: saving rejects to build/include/ffi.h.in.rej
The next patch looks like a unified context diff.
Hunk #2 failed at line 66.
Hunk #3 failed at line 26.
2 out of 3 hunks failed: saving rejects to build/include/ffi_common.h.rej
done
gmake[1]: *** [stamp.ffi.configure] Error 1
```
Using GNU `patch` instead of the Solaris version works.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"Patching libffi fails in Solaris","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is what happens:\r\n{{{\r\ngmake[1]: Entering directory `/home/rl/ghc/ghc/libffi'\r\nrm -f -rf libffi-3.0.6 build\r\n/usr/sfw/bin/gtar -zxf libffi-3.0.6.tar.gz\r\nmv libffi-3.0.6 build\r\nchmod +x ln\r\npatch -p0 < libffi-dllize-3.0.6.patch\r\n Looks like a unified context diff.\r\nHunk #5 failed at line 344.\r\nHunk #6 failed at line 165.\r\nHunk #7 failed at line 33.\r\n3 out of 7 hunks failed: saving rejects to build/include/ffi.h.in.rej\r\n The next patch looks like a unified context diff.\r\nHunk #2 failed at line 66.\r\nHunk #3 failed at line 26.\r\n2 out of 3 hunks failed: saving rejects to build/include/ffi_common.h.rej\r\ndone\r\ngmake[1]: *** [stamp.ffi.configure] Error 1\r\n}}}\r\n\r\nUsing GNU `patch` instead of the Solaris version works.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2810Debugger: change context to the module containing the current breakpoint2019-07-07T19:06:44ZSimon MarlowDebugger: change context to the module containing the current breakpointMoved part of #2740 here.
When we stop at a breakpoint, perhaps we should change the current context (`:module`) to the module that contains the breakpoint location. That would at least give access to a similar scope to that in which th...Moved part of #2740 here.
When we stop at a breakpoint, perhaps we should change the current context (`:module`) to the module that contains the breakpoint location. That would at least give access to a similar scope to that in which the breakpoint expression is located.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| 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":"Debugger: change context to the module containing the current breakpoint","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Moved part of #2740 here.\r\n\r\nWhen we stop at a breakpoint, perhaps we should change the current context (`:module`) to the module that contains the breakpoint location. That would at least give access to a similar scope to that in which the breakpoint expression is located.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2813Create a utf8 bytestring-a-like2019-07-07T19:06:43ZIan Lynagh <igloo@earth.li>Create a utf8 bytestring-a-likeThere are a number of things we want a utf8 bytestring-a-like for:
- GHC's !FastString to be built on top of
- Text.!PrettyPrint.ptext (this means we can drop GHC's utils/Pretty)
- template haskell, to use in place of packedstring
- pos...There are a number of things we want a utf8 bytestring-a-like for:
- GHC's !FastString to be built on top of
- Text.!PrettyPrint.ptext (this means we can drop GHC's utils/Pretty)
- template haskell, to use in place of packedstring
- possibly to use in the base IO libraries (see also #2811)
- possibly to use in haskeline (see also #2812)
and probably more besides. Ideally all of this will be done comfortably in time for 6.12!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Create a utf8 bytestring-a-like","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There are a number of things we want a utf8 bytestring-a-like for:\r\n * GHC's !FastString to be built on top of\r\n * Text.!PrettyPrint.ptext (this means we can drop GHC's utils/Pretty)\r\n * template haskell, to use in place of packedstring\r\n * possibly to use in the base IO libraries (see also #2811)\r\n * possibly to use in haskeline (see also #2812)\r\nand probably more besides. Ideally all of this will be done comfortably in time for 6.12!\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2828TcTyFuns.uMeta: normalisation shouldn't allow x ~ x2019-07-07T19:06:39ZpizzaTcTyFuns.uMeta: normalisation shouldn't allow x ~ x```
pizza@extracheese:~/proj/truegraph$ ghci stats.hs
GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package b...```
pizza@extracheese:~/proj/truegraph$ ghci stats.hs
GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( stats.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.0.20081007 for i386-unknown-linux):
TcTyFuns.uMeta: normalisation shouldn't allow x ~ x
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
where stats.hs is:
```
mean :: (Num b) => [a] -> (a -> b) -> b
mean set f =
let total = sum $ map f set
mean' = total / fromIntegral $ length set
in mean'
```
NOTE that i'm not even sure if this code is correct or makes sense, i'm in the middle of growing it.
<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":"TcTyFuns.uMeta: normalisation shouldn't allow x ~ x","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":"{{{\r\npizza@extracheese:~/proj/truegraph$ ghci stats.hs \r\nGHCi, version 6.10.0.20081007: 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\n[1 of 1] Compiling Main ( stats.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.0.20081007 for i386-unknown-linux):\r\n TcTyFuns.uMeta: normalisation shouldn't allow x ~ x\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n> \r\n}}}\r\n\r\nwhere stats.hs is:\r\n\r\n{{{\r\nmean :: (Num b) => [a] -> (a -> b) -> b\r\nmean set f = \r\n let total = sum $ map f set \r\n mean' = total / fromIntegral $ length set \r\n in mean'\r\n}}}\r\n\r\nNOTE that i'm not even sure if this code is correct or makes sense, i'm in the middle of growing it.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchManuel M T ChakravartyManuel M T Chakravartyhttps://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/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/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/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/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/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/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/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/2951Add support for amd64-solaris2 platform2019-07-07T19:06:10ZkgardasAdd support for amd64-solaris2 platformHello,
it would be nice if GHC build correctly detects if it's running on amd64 platform or plain old i386 platform. The problem is that current config.guess returns in both cases i386-pc-solaris2.\* string. Certainly there is a possibi...Hello,
it would be nice if GHC build correctly detects if it's running on amd64 platform or plain old i386 platform. The problem is that current config.guess returns in both cases i386-pc-solaris2.\* string. Certainly there is a possibility to use `isainfo -n` to test for application supported instruction set, see:
```
karel@silence:~/vcs/ghc$ ./config.guess
i386-pc-solaris2.11
karel@silence:~/vcs/ghc$ isainfo -n
amd64
karel@silence:~/vcs/ghc$
```
I'm just not sure if hacking configure.ac's code below
```
i[[3456]]86-*-solaris2*)
HostPlatform=i386-unknown-solaris2 # hack again
TargetPlatform=i386-unknown-solaris2
BuildPlatform=i386-unknown-solaris2
HostPlatform_CPP='i386_unknown_solaris2'
HostArch_CPP='i386'
HostVendor_CPP='unknown'
HostOS_CPP='solaris2'
;;
```
and changing HostArch_CPP from 'i386' to 'x86_64' would be enough for the change.
<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":"Add support for amd64-solaris2 platform","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":"Hello,\r\n\r\nit would be nice if GHC build correctly detects if it's running on amd64 platform or plain old i386 platform. The problem is that current config.guess returns in both cases i386-pc-solaris2.* string. Certainly there is a possibility to use `isainfo -n` to test for application supported instruction set, see:\r\n{{{\r\nkarel@silence:~/vcs/ghc$ ./config.guess \r\ni386-pc-solaris2.11\r\nkarel@silence:~/vcs/ghc$ isainfo -n\r\namd64\r\nkarel@silence:~/vcs/ghc$ \r\n}}}\r\n\r\nI'm just not sure if hacking configure.ac's code below\r\n{{{\r\ni[[3456]]86-*-solaris2*)\r\n HostPlatform=i386-unknown-solaris2 # hack again\r\n TargetPlatform=i386-unknown-solaris2\r\n BuildPlatform=i386-unknown-solaris2\r\n HostPlatform_CPP='i386_unknown_solaris2'\r\n HostArch_CPP='i386'\r\n HostVendor_CPP='unknown'\r\n HostOS_CPP='solaris2'\r\n ;;\r\n}}}\r\nand changing HostArch_CPP from 'i386' to 'x86_64' would be enough for the change.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2962Reduce space usage of genericLength for common Num instances2019-07-07T19:06:07ZthorkilnaurReduce space usage of genericLength for common Num instancesThere is a space leak in `genericLength`:
```
$ ghc/stage2-inplace/ghc --interactive
GHCi, version 6.11.20090116: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linkin...There is a space leak in `genericLength`:
```
$ ghc/stage2-inplace/ghc --interactive
GHCi, version 6.11.20090116: 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 ffi-1.0 ... linking ... done.
Prelude> :module +List
Prelude List> genericLength [1..600000]
*** Exception: stack overflow
Prelude List>
Prelude List> length [1..600000]
600000
Prelude List>
```
The attached patch against the base library provides a fix.
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| 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":"Fix space leak in genericLength","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is a space leak in {{{genericLength}}}:\r\n{{{\r\n$ ghc/stage2-inplace/ghc --interactive\r\nGHCi, version 6.11.20090116: 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 ffi-1.0 ... linking ... done.\r\nPrelude> :module +List\r\nPrelude List> genericLength [1..600000]\r\n*** Exception: stack overflow\r\nPrelude List>\r\nPrelude List> length [1..600000]\r\n600000\r\nPrelude List>\r\n}}}\r\nThe attached patch against the base library provides a fix.\r\n\r\nBest regards\r\nThorkil\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchthorkilnaurthorkilnaurhttps://gitlab.haskell.org/ghc/ghc/-/issues/2981".space" directive not recognised by solaris assembler2019-07-07T19:06:01Zduncan".space" directive not recognised by solaris assemblerThe Solaris assembler (`/usr/ccs/bin/as`) does not recognise the `.space` directive. Presumably the GNU assembler does.
```
/usr/ccs/bin/as: "test.s", line 484: error: unknown opcode ".space"
/usr/ccs/bin/as: "test.s", line 484: error: ...The Solaris assembler (`/usr/ccs/bin/as`) does not recognise the `.space` directive. Presumably the GNU assembler does.
```
/usr/ccs/bin/as: "test.s", line 484: error: unknown opcode ".space"
/usr/ccs/bin/as: "test.s", line 484: error: statement syntax
```
It happens building ghc head on sparc solaris with the NCG turned on. However the pretty-printing code:
`compiler/nativeGen/PprMach.hs:`
```
pprData (CmmUninitialised bytes) = ptext (sLit ".space ") <> int bytes
```
does not look like it's in a section that is specific to sparc or solaris. So presumably the same issue applies on Solaris on x86 systems when using the system gcc and assembler rather than GNU as.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\".space\" directive not recognised by solaris assembler","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Solaris assembler (`/usr/ccs/bin/as`) does not recognise the `.space` directive. Presumably the GNU assembler does.\r\n\r\n{{{\r\n/usr/ccs/bin/as: \"test.s\", line 484: error: unknown opcode \".space\"\r\n/usr/ccs/bin/as: \"test.s\", line 484: error: statement syntax\r\n}}}\r\n\r\nIt happens building ghc head on sparc solaris with the NCG turned on. However the pretty-printing code:\r\n\r\n`compiler/nativeGen/PprMach.hs:`\r\n{{{\r\npprData (CmmUninitialised bytes) = ptext (sLit \".space \") <> int bytes\r\n}}}\r\n\r\ndoes not look like it's in a section that is specific to sparc or solaris. So presumably the same issue applies on Solaris on x86 systems when using the system gcc and assembler rather than GNU as.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchbenlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/2984Vectorized dph code doesn't terminate2019-07-07T19:06:00ZfreVectorized dph code doesn't terminateThe program attached to this ticket doesn't terminate when vectorisation is used. It runs fine when vectorisation is not enabled.
The problem seems to be the use of sumP or mapP with the empty array.
<details><summary>Trac metadata</su...The program attached to this ticket doesn't terminate when vectorisation is used. It runs fine when vectorisation is not enabled.
The problem seems to be the use of sumP or mapP with the empty array.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Data Parallel Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Vectorized dph code doesn't terminate","status":"New","operating_system":"Linux","component":"Data Parallel Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"The program attached to this ticket doesn't terminate when vectorisation is used. It runs fine when vectorisation is not enabled.\r\n\r\nThe problem seems to be the use of sumP or mapP with the empty array. ","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchrl@cse.unsw.edu.aurl@cse.unsw.edu.auhttps://gitlab.haskell.org/ghc/ghc/-/issues/2995ghc -Wall does not complain about unnecessary data constructor imports2019-07-07T19:05:58ZEyalLotemghc -Wall does not complain about unnecessary data constructor importsIf it is enough to import:
```
import SomeModule(SomeType)
```
Then ghc should complain (warn) when importing:
```
import SomeModule(SomeType(..))
```
or:
```
import SomeModule(SomeType(SomeConstructor))
```
But it doesn't output a...If it is enough to import:
```
import SomeModule(SomeType)
```
Then ghc should complain (warn) when importing:
```
import SomeModule(SomeType(..))
```
or:
```
import SomeModule(SomeType(SomeConstructor))
```
But it doesn't output any complaint or warning.6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3019sparc membar asm instruction requires mode parameter2019-07-07T19:05:51Zduncansparc membar asm instruction requires mode parameterThe new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.
```
EXTERN_INLINE void
store_load_barrier(void) {
#if i386_HOST_ARCH
__asm__ __volatile__ ("lock; addl $0,0(%%esp)" : : : "memory");
#elif x86_64_HOST_A...The new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.
```
EXTERN_INLINE void
store_load_barrier(void) {
#if i386_HOST_ARCH
__asm__ __volatile__ ("lock; addl $0,0(%%esp)" : : : "memory");
#elif x86_64_HOST_ARCH
__asm__ __volatile__ ("lock; addq $0,0(%%rsp)" : : : "memory");
#elif powerpc_HOST_ARCH
__asm__ __volatile__ ("msync" : : : "memory");
#elif sparc_HOST_ARCH
/* Sparc in TSO mode does not require write/write barriers. */
__asm__ __volatile__ ("membar" : : : "memory");
#elif !defined(WITHSMP)
return;
#else
#error memory barriers unimplemented on this architecture
#endif
```
In particular for sparc the bit:
```
/* Sparc in TSO mode does not require write/write barriers. */
__asm__ __volatile__ ("membar" : : : "memory");
```
This is not right. The membar assembly statement requires a parameter to specify which kind of memory barrier is required. For `store_load_barrier()` it is of course `membar #StoreLoad`.
Without this the assembler complains:
```
/usr/ccs/bin/as: "parallel/WSDeque.s", line 11: error: statement syntax
```
With `#StoreLoad` added it's fine.
Note also that the comment appears to be wrong
```
/* Sparc in TSO mode does not require write/write barriers. */
```
This is `store_load_barrier()` not `store_store_barrier()` so it is exactly and only this case that is required.
<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":"sparc membar asm instruction requires mode parameter","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.\r\n\r\n{{{\r\nEXTERN_INLINE void\r\nstore_load_barrier(void) {\r\n#if i386_HOST_ARCH\r\n __asm__ __volatile__ (\"lock; addl $0,0(%%esp)\" : : : \"memory\");\r\n#elif x86_64_HOST_ARCH\r\n __asm__ __volatile__ (\"lock; addq $0,0(%%rsp)\" : : : \"memory\");\r\n#elif powerpc_HOST_ARCH\r\n __asm__ __volatile__ (\"msync\" : : : \"memory\");\r\n#elif sparc_HOST_ARCH\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n __asm__ __volatile__ (\"membar\" : : : \"memory\");\r\n#elif !defined(WITHSMP)\r\n return;\r\n#else\r\n#error memory barriers unimplemented on this architecture\r\n#endif\r\n}}}\r\n\r\nIn particular for sparc the bit:\r\n{{{\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n __asm__ __volatile__ (\"membar\" : : : \"memory\");\r\n}}}\r\n\r\nThis is not right. The membar assembly statement requires a parameter to specify which kind of memory barrier is required. For `store_load_barrier()` it is of course `membar #StoreLoad`.\r\n\r\nWithout this the assembler complains:\r\n{{{\r\n/usr/ccs/bin/as: \"parallel/WSDeque.s\", line 11: error: statement syntax\r\n}}}\r\n\r\nWith `#StoreLoad` added it's fine.\r\n\r\nNote also that the comment appears to be wrong\r\n{{{\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n}}}\r\nThis is `store_load_barrier()` not `store_store_barrier()` so it is exactly and only this case that is required.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3100GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet2019-07-07T19:05:24ZmightybyteGHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet```
Exception when trying to run compile-time code:
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
reifyType PredTy
```
Code reproducing this bug can be found at:
http://hpaste.org/fastcgi...```
Exception when trying to run compile-time code:
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
reifyType PredTy
```
Code reproducing this bug can be found at:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2419
Marked as critical because I haven't found a workaround yet.6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3177support quasiquoting for types2019-07-07T19:05:01Zclaus.reinke@talk21.comsupport quasiquoting for typesCurrently, quasiquotes are limited to patterns and expressions, though patterns and expressions with explicit type signatures can be generated (with appropriate language flag for pattern signatures).
Since so much of Haskell programming...Currently, quasiquotes are limited to patterns and expressions, though patterns and expressions with explicit type signatures can be generated (with appropriate language flag for pattern signatures).
Since so much of Haskell programming happens at the type level, it would be great if quasiquoting wasn't excluded from that part of the game (think type-level numbers, for instance, or any type-level library that requires constants translated into types).
For just one example, see http://www.haskell.org/pipermail/haskell-cafe/2009-April/059819.html , where I would like to be able to specify label types and type tags directly at the type-level as well.
related: #1476 (Template Haskell won't address this in the near future, so having quasiquotes for types would narrow the gap)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"support quasiquoting for types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, quasiquotes are limited to patterns and expressions, though patterns and expressions with explicit type signatures can be generated (with appropriate language flag for pattern signatures).\r\n\r\nSince so much of Haskell programming happens at the type level, it would be great if quasiquoting wasn't excluded from that part of the game (think type-level numbers, for instance, or any type-level library that requires constants translated into types).\r\n\r\nFor just one example, see http://www.haskell.org/pipermail/haskell-cafe/2009-April/059819.html , where I would like to be able to specify label types and type tags directly at the type-level as well. \r\n\r\nrelated: #1476 (Template Haskell won't address this in the near future, so having quasiquotes for types would narrow the gap)","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3193line number for GADT type error is very inaccurate2019-07-07T19:04:57Znr@eecs.harvard.eduline number for GADT type error is very inaccurateHere is an error message from 6.11:
```
cmm/ZDF5ex.hs:528:2:
Couldn't match expected type `ZOpen'
against inferred type `ZClosed'
Expected type: ZipGF m l e x
Inferred type: ZipGF m l C O
In the first argu...Here is an error message from 6.11:
```
cmm/ZDF5ex.hs:528:2:
Couldn't match expected type `ZOpen'
against inferred type `ZClosed'
Expected type: ZipGF m l e x
Inferred type: ZipGF m l C O
In the first argument of `anal_f', namely `g'
In the expression: anal_f g (return . fromZJust) ZNothing
```
This is all very well, but the offending term (the one shown in the message) is actually on line 697, not line 528. The term is part of one declaration in a monster 'where' clause attached to the definition on line 528, column 2. The next one might not be so easy to find.
I'm attaching the file, which is part of some new GHC code I'm hoping to deliver one of these months. If you need access to the whole thing I'll have a branch in a git repository.
<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":"line number for GADT type error is very inaccurate","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["GADTs"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is an error message from 6.11:\r\n{{{\r\ncmm/ZDF5ex.hs:528:2:\r\n Couldn't match expected type `ZOpen'\r\n against inferred type `ZClosed'\r\n Expected type: ZipGF m l e x\r\n Inferred type: ZipGF m l C O\r\n In the first argument of `anal_f', namely `g'\r\n In the expression: anal_f g (return . fromZJust) ZNothing\r\n}}}\r\nThis is all very well, but the offending term (the one shown in the message) is actually on line 697, not line 528. The term is part of one declaration in a monster 'where' clause attached to the definition on line 528, column 2. The next one might not be so easy to find.\r\n\r\nI'm attaching the file, which is part of some new GHC code I'm hoping to deliver one of these months. If you need access to the whole thing I'll have a branch in a git repository.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3221Incorrect "defined but not used" warning for data types using deriving2019-07-07T19:04:50ZNeil MitchellIncorrect "defined but not used" warning for data types using derivingConsider:
```
module Main() where
import System
data Foo = Bar | Baz
deriving (Show,Read)
main = do
[x] <- getArgs
print (read x :: Foo)
```
When we compile:
```
$ ghc -c Test.hs -fwarn-unused-binds
Test.hs:6:11:...Consider:
```
module Main() where
import System
data Foo = Bar | Baz
deriving (Show,Read)
main = do
[x] <- getArgs
print (read x :: Foo)
```
When we compile:
```
$ ghc -c Test.hs -fwarn-unused-binds
Test.hs:6:11: Warning: Defined but not used: data constructor `Bar'
Test.hs:6:17: Warning: Defined but not used: data constructor `Baz'
```
This is incorrect. If a data type derives `Read`, `Enum` or `Bounded` (and for `Bounded`, is either the first or last element), then the values are used - even if not by name.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.10.2 |
| 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":"Incorrect \"defined but not used\" warning for data types using deriving","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Consider:\r\n\r\n{{{\r\n\r\nmodule Main() where\r\n\r\nimport System\r\n\r\ndata Foo = Bar | Baz\r\n deriving (Show,Read)\r\n\r\nmain = do\r\n [x] <- getArgs\r\n print (read x :: Foo)\r\n}}}\r\n\r\nWhen we compile:\r\n\r\n{{{\r\n$ ghc -c Test.hs -fwarn-unused-binds\r\nTest.hs:6:11: Warning: Defined but not used: data constructor `Bar'\r\nTest.hs:6:17: Warning: Defined but not used: data constructor `Baz'\r\n}}}\r\n\r\nThis is incorrect. If a data type derives {{{Read}}}, {{{Enum}}} or {{{Bounded}}} (and for {{{Bounded}}}, is either the first or last element), then the values are used - even if not by name.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3240Bad jump on PowerPC2019-07-07T19:04:46ZduaneBad jump on PowerPC```
ghc: internal error: unconditional relative branch out of range: jump island out of range
(GHC version 6.10.1 for powerpc_apple_darwin)
```
That's it. NOTE: I was compiling LHC when this happened.```
ghc: internal error: unconditional relative branch out of range: jump island out of range
(GHC version 6.10.1 for powerpc_apple_darwin)
```
That's it. NOTE: I was compiling LHC when this happened.6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3245Quadratic slowdown in Data.Typeable2019-07-07T19:04:45ZguestQuadratic slowdown in Data.TypeableData.Typeable has a significant asymptotic performance problem. In the
attached code, sum2 runs much slower than either sum1 or sum3. It
should be linear but it seems to slow down quadratically (i.e.
doubling "len" quadruples the time fo...Data.Typeable has a significant asymptotic performance problem. In the
attached code, sum2 runs much slower than either sum1 or sum3. It
should be linear but it seems to slow down quadratically (i.e.
doubling "len" quadruples the time for sum2). Here is an example run:
```
$ ghc --make -O3 CastSpeed.hs
$ ./CastSpeed 20000
gsum1
Result: 200010000
Time(sec): 7.999e-3
Result: 200010000
Time(sec): 0.0
Result: 200010000
Time(sec): 1.0e-3
gsum2
Result: 200010000
Time(sec): 1.483774
Result: 200010000
Time(sec): 1.477776
Result: 200010000
Time(sec): 1.523768
gsum3
Result: 200010000
Time(sec): 5.999e-3
Result: 200010000
Time(sec): 0.0
Result: 200010000
Time(sec): 0.0
```
The only difference between sum1 and sum2 is that sum2 wraps a
singleton list around each element (i.e. the cast is to \[Int\] instead
of Int). The only difference between sum2 and sum3 is that sum3 uses
an unchecked cast (unsafeCoerce) instead of a checked cast. This
problem seems to crop up only for those types which are made up of a
type constructor applied to an argument (e.g. "\[\]" applied to "Int").
Because of sum3 runs fast, I suspect that something is going wrong
with the "typeOf" call in a checked cast, and because sum1 runs fast I
suspect that what is going wrong is the call to appKey that is called
from mkAppTy that is called from typeOfDefault that is called from the
Typeable instance for \[Int\] (i.e. instance (Typeable1 s, Typeable a)
=\> Typeable (s a)). This is a bit of speculation and I don't have
hard evidence for that being the source of the problems, but tests
that I have run (not listed here) are strongly suggestive of appKey
being the culprit.
- Michael D. Adams
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Quadratic slowdown in Data.Typeable","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":"Bug","description":"Data.Typeable has a significant asymptotic performance problem. In the\r\nattached code, sum2 runs much slower than either sum1 or sum3. It\r\nshould be linear but it seems to slow down quadratically (i.e.\r\ndoubling \"len\" quadruples the time for sum2). Here is an example run:\r\n\r\n{{{\r\n$ ghc --make -O3 CastSpeed.hs\r\n$ ./CastSpeed 20000\r\ngsum1\r\nResult: 200010000\r\nTime(sec): 7.999e-3\r\nResult: 200010000\r\nTime(sec): 0.0\r\nResult: 200010000\r\nTime(sec): 1.0e-3\r\n\r\ngsum2\r\nResult: 200010000\r\nTime(sec): 1.483774\r\nResult: 200010000\r\nTime(sec): 1.477776\r\nResult: 200010000\r\nTime(sec): 1.523768\r\n\r\ngsum3\r\nResult: 200010000\r\nTime(sec): 5.999e-3\r\nResult: 200010000\r\nTime(sec): 0.0\r\nResult: 200010000\r\nTime(sec): 0.0\r\n}}}\r\n\r\nThe only difference between sum1 and sum2 is that sum2 wraps a\r\nsingleton list around each element (i.e. the cast is to [Int] instead\r\nof Int). The only difference between sum2 and sum3 is that sum3 uses\r\nan unchecked cast (unsafeCoerce) instead of a checked cast. This\r\nproblem seems to crop up only for those types which are made up of a\r\ntype constructor applied to an argument (e.g. \"[]\" applied to \"Int\").\r\n\r\nBecause of sum3 runs fast, I suspect that something is going wrong\r\nwith the \"typeOf\" call in a checked cast, and because sum1 runs fast I\r\nsuspect that what is going wrong is the call to appKey that is called\r\nfrom mkAppTy that is called from typeOfDefault that is called from the\r\nTypeable instance for [Int] (i.e. instance (Typeable1 s, Typeable a)\r\n=> Typeable (s a)). This is a bit of speculation and I don't have\r\nhard evidence for that being the source of the problems, but tests\r\nthat I have run (not listed here) are strongly suggestive of appKey\r\nbeing the culprit.\r\n\r\n- Michael D. Adams\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3273memory leak due to optimisation2020-11-17T17:20:15Zsebfmemory leak due to optimisationShort summary:
The attached programs use lots of space when compiled with -O and run in constant space without -O.
condensed.hs runs in constant space with -O too, if you remove any occurrence of 'id'.
original.hs uses a lot of space wi...Short summary:
The attached programs use lots of space when compiled with -O and run in constant space without -O.
condensed.hs runs in constant space with -O too, if you remove any occurrence of 'id'.
original.hs uses a lot of space without -O too, if an alternative definition of 'iterDepth' is used (see comment there).
I could reproduce this behaviour with ghc-6.8.2 under Linux as well as ghc-6.10.1 and ghc-6.11.20090331 under Mac OS X 10.5.7.
Full description:
This ticket has an attached tar file with two source files -- original.hs and condensed.hs -- that can be compiled with and without -O to reproduce the bug:
```
$ ghc -fforce-recomp --make original
[1 of 1] Compiling Main ( original.hs, original.o )
Linking original ...
$ ./original
^C <constant space usage>
$ ghc -v -dcore-lint -O -fforce-recomp --make original
Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.8.3
Using package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf
Using package config file: /Users/sebf/.ghc/i386-darwin-6.10.1/package.conf
hiding package HTTP-3001.1.3 to avoid conflict with later version HTTP-3001.1.4
hiding package haddock-2.3.0 to avoid conflict with later version haddock-2.4.1
hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0
hiding package old-time-1.0.0.1 to avoid conflict with later version old-time-1.0.0.2
hiding package filepath-1.1.0.1 to avoid conflict with later version filepath-1.1.0.2
hiding package process-1.0.1.0 to avoid conflict with later version process-1.0.1.1
hiding package Cabal-1.6.0.1 to avoid conflict with later version Cabal-1.6.0.2
hiding package regex-base-0.72.0.2 to avoid conflict with later version regex-base-0.93.1
hiding package regex-posix-0.72.0.3 to avoid conflict with later version regex-posix-0.93.2
hiding package regex-compat-0.71.0.1 to avoid conflict with later version regex-compat-0.92
hiding package network-2.2.0.1 to avoid conflict with later version network-2.2.1.2
hiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickCheck-2.1.0.1
hiding package time-1.1.2.2 to avoid conflict with later version time-1.1.2.3
hiding package zlib-0.4.0.4 to avoid conflict with later version zlib-0.5.0.0
hiding package HTTP-3001.1.4 to avoid conflict with later version HTTP-3001.1.5
hiding package regex-posix-0.93.2 to avoid conflict with later version regex-posix-0.94.1
hiding package utf8-string-0.3.3 to avoid conflict with later version utf8-string-0.3.4
hiding package binary-0.4.3.1 to avoid conflict with later version binary-0.4.4
hiding package zip-archive-0.1.1.1 to avoid conflict with later version zip-archive-0.1.1.3
hiding package binary-0.4.4 to avoid conflict with later version binary-0.5
hiding package haddock-2.4.1 to avoid conflict with later version haddock-2.4.2
hiding package HTTP-3001.1.5 to avoid conflict with later version HTTP-4000.0.0
hiding package hscolour-1.10.1 to avoid conflict with later version hscolour-1.11
hiding package HTTP-4000.0.0 to avoid conflict with later version HTTP-4000.0.1
hiding package haskell-src-exts-0.4.6 to avoid conflict with later version haskell-src-exts-0.4.8
hiding package HTTP-4000.0.1 to avoid conflict with later version HTTP-4000.0.4
hiding package digest-0.0.0.1 to avoid conflict with later version digest-0.0.0.2
hiding package level-monad-0.2.1 to avoid conflict with later version level-monad-0.3
hiding package HTTP-4000.0.4 to avoid conflict with later version HTTP-4000.0.7
hiding package digest-0.0.0.2 to avoid conflict with later version digest-0.0.0.4
hiding package terminfo-0.2.2.1 to avoid conflict with later version terminfo-0.3.0.2
hiding package stream-monad-0.1 to avoid conflict with later version stream-monad-0.1.1.0
hiding package tree-monad-0.1 to avoid conflict with later version tree-monad-0.1.1
hiding package parallel-tree-search-0.2.1 to avoid conflict with later version parallel-tree-search-0.4
hiding package explicit-sharing-0.2 to avoid conflict with later version explicit-sharing-0.3.1.1
hiding package tree-monad-0.1.1 to avoid conflict with later version tree-monad-0.2
hiding package tree-monad-0.2 to avoid conflict with later version tree-monad-0.2.1
hiding package parallel-tree-search-0.4 to avoid conflict with later version parallel-tree-search-0.4.1
hiding package level-monad-0.3 to avoid conflict with later version level-monad-0.3.1
hiding package explicit-sharing-0.3.1.1 to avoid conflict with later version explicit-sharing-0.3.1.2
hiding package explicit-sharing-0.3.1.2 to avoid conflict with later version explicit-sharing-0.3.1.3
hiding package explicit-sharing-0.3.1.3 to avoid conflict with later version explicit-sharing-0.4.0
hiding package explicit-sharing-0.4.0 to avoid conflict with later version explicit-sharing-0.5.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.0
wired-in package base mapped to base-4.0.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.0
wired-in package template-haskell mapped to template-haskell-2.3.0.0
wired-in package dph-seq mapped to dph-seq-0.3
wired-in package dph-par mapped to dph-par-0.3
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: *original.hs
Stable obj: [Main]
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Thu Jun 4 13:23:20 CEST 2009
ms_mod = main:Main,
ms_imps = [Control.Monad.Cont]
ms_srcimps = []
}]
compile: input file original.hs
Created temporary directory: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( original.hs, original.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 753
*** Core Linted result of Desugar:
*** Simplify:
Result size = 290
*** Core Linted result of Simplifier phase gentle, iteration 1 out of 4:
Result size = 280
*** Core Linted result of Simplifier phase gentle, iteration 2 out of 4:
Result size = 280
*** Core Linted result of Simplify phase gentle done:
*** Specialise:
Result size = 331
*** Core Linted result of Specialise:
*** Float out (not lambdas, not constants):
Result size = 351
*** Core Linted result of Float out (not lambdas, not constants):
*** Float inwards:
Result size = 351
*** Core Linted result of Float inwards:
*** Simplify:
Result size = 587
*** Core Linted result of Simplifier phase 2 [main], iteration 1 out of 4:
Result size = 390
*** Core Linted result of Simplifier phase 2 [main], iteration 2 out of 4:
Result size = 304
*** Core Linted result of Simplify phase 2 [main] done:
*** Simplify:
Result size = 287
*** Core Linted result of Simplifier phase 1 [main], iteration 1 out of 4:
Result size = 287
*** Core Linted result of Simplify phase 1 [main] done:
*** Simplify:
Result size = 330
*** Core Linted result of Simplifier phase 0 [main], iteration 1 out of 4:
Result size = 310
*** Core Linted result of Simplifier phase 0 [main], iteration 2 out of 4:
Result size = 304
*** Core Linted result of Simplifier phase 0 [main], iteration 3 out of 4:
Result size = 304
*** Core Linted result of Simplify phase 0 [main] done:
*** Demand analysis:
Result size = 304
*** Core Linted result of Demand analysis:
*** Worker Wrapper binds:
Result size = 330
*** Core Linted result of Worker Wrapper binds:
*** GlomBinds:
*** Simplify:
Result size = 345
*** Core Linted result of Simplifier phase 0 [post-worker-wrapper], iteration 1 out of 4:
Result size = 345
*** Core Linted result of Simplify phase 0 [post-worker-wrapper] done:
*** Float out (not lambdas, constants):
Result size = 353
*** Core Linted result of Float out (not lambdas, constants):
*** Common sub-expression:
Result size = 352
*** Core Linted result of Common sub-expression:
*** Float inwards:
Result size = 352
*** Core Linted result of Float inwards:
*** Simplify:
Result size = 353
*** Core Linted result of Simplifier phase 0 [final], iteration 1 out of 4:
Result size = 353
*** Core Linted result of Simplify phase 0 [final] done:
*** Tidy Core:
Result size = 353
*** Core Linted result of Tidy Core:
writeBinIface: 49 Names
writeBinIface: 98 dict entries
*** CorePrep:
Result size = 430
*** Core Linted result of CorePrep:
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** Assembler:
gcc -I. -c /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s -o original.o
*** Deleting temp files:
Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s
Upsweep completely successful.
*** Deleting temp files:
Deleting:
link: linkables are ...
LinkableM (Thu Jun 4 13:55:23 CEST 2009) main:Main
[DotO original.o]
Linking original ...
*** Linker:
gcc -v -o original -DDONT_WANT_WIN32_DLL_SUPPORT original.o -L/Library/Frameworks/GHC.framework
/Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr
/lib/ghc-6.10.1/base-4.0.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/
integer-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0
-L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1 -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0
-lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lffi -lgmp -ldl -u _ghczmprim_GHCziTypes_Izh_static_info
-u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info
-u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info
-u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info
-u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info
-u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info
-u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info
-u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info
-u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure
-u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure
-u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure
-u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure
-u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure
-u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure
-u _base_GHCziConc_ensureIOManagerIsRunning_closure -Wl,-search_paths_first
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple
--with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5488)
/usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.7
-weak_reference_mismatches non-weak -u _ghczmprim_GHCziTypes_Izh_static_info
-u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info
-u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info
-u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info
-u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info
-u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info
-u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info
-u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info
-u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure
-u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure
-u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure
-u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure
-u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure
-u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure
-u _base_GHCziConc_ensureIOManagerIsRunning_closure -o original -lcrt1.10.5.o -L/Library/Frameworks/GHC.framework/
Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/base-4.0.0.0
-L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/integer-0.1.0.0 -L/Library/Frameworks/GHC.framework
/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1
-L/usr/lib/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1
/../../.. original.o -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0 -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm
-lffi -lgmp -ldl -search_paths_first -lgcc_s.10.5 -lgcc -lSystem
link: done
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0
$ ./original
^C <increasing space usage>
$ ghc -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <constant space>
13:50 memleak$ ghc -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing space usage>
```
I have checked with ghc-6.8.2 on "Linux 2.6.27-11-generic 1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux" and with ghc-6.10.1 and 6.11.200903331 on "Darwin 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14\~1/RELEASE_I386 i386"
Here are some more runs with -fno-full-laziness and/or -fno-cse. Neither switch affects the memory requirements with -O:
```
$ ghc -fno-full-laziness -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing memory usage>
$ ghc -fno-cse -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing memory usage>
$ ghc -fno-full-laziness -fno-cse -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing memory usage>
```
The program original.hs contains an alternative implementation of 'iterDepth' that seems to hint at the problem. I think, the argument of 'runDepthBound' is held in memory for a good reason there.
The program condensed.hs contains four superflous occurrences of 'id' that seem to play together to cause the memory leak. If all of them are present then the program uses lots of space with -O, if either one is missing it runs in constant space. The program always runs in constant space without -O. I think, the space leak is caused by holding the arguments of 'id' in memory. If that is true, however, I don't see why \*all\* occurrences of 'id' are necessary to cause the leak.
I think the original program and all versions of the condensed program should run in constant space with and without -O. It would be nice if the alternative version of the original program would run in constant space too but I see that there is sharing that may prevent this.
<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 | sebf@informatik.uni-kiel.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"memory leak due to optimisation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sebf@informatik.uni-kiel.de"],"type":"Bug","description":"Short summary:\r\n\r\nThe attached programs use lots of space when compiled with -O and run in constant space without -O.\r\ncondensed.hs runs in constant space with -O too, if you remove any occurrence of 'id'.\r\noriginal.hs uses a lot of space without -O too, if an alternative definition of 'iterDepth' is used (see comment there).\r\n\r\nI could reproduce this behaviour with ghc-6.8.2 under Linux as well as ghc-6.10.1 and ghc-6.11.20090331 under Mac OS X 10.5.7.\r\n\r\nFull description:\r\n\r\nThis ticket has an attached tar file with two source files -- original.hs and condensed.hs -- that can be compiled with and without -O to reproduce the bug:\r\n\r\n{{{\r\n$ ghc -fforce-recomp --make original\r\n[1 of 1] Compiling Main ( original.hs, original.o )\r\nLinking original ...\r\n\r\n$ ./original \r\n^C <constant space usage>\r\n\r\n$ ghc -v -dcore-lint -O -fforce-recomp --make original\r\nGlasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.8.3\r\nUsing package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf\r\nUsing package config file: /Users/sebf/.ghc/i386-darwin-6.10.1/package.conf\r\nhiding package HTTP-3001.1.3 to avoid conflict with later version HTTP-3001.1.4\r\nhiding package haddock-2.3.0 to avoid conflict with later version haddock-2.4.1\r\nhiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0\r\nhiding package old-time-1.0.0.1 to avoid conflict with later version old-time-1.0.0.2\r\nhiding package filepath-1.1.0.1 to avoid conflict with later version filepath-1.1.0.2\r\nhiding package process-1.0.1.0 to avoid conflict with later version process-1.0.1.1\r\nhiding package Cabal-1.6.0.1 to avoid conflict with later version Cabal-1.6.0.2\r\nhiding package regex-base-0.72.0.2 to avoid conflict with later version regex-base-0.93.1\r\nhiding package regex-posix-0.72.0.3 to avoid conflict with later version regex-posix-0.93.2\r\nhiding package regex-compat-0.71.0.1 to avoid conflict with later version regex-compat-0.92\r\nhiding package network-2.2.0.1 to avoid conflict with later version network-2.2.1.2\r\nhiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickCheck-2.1.0.1\r\nhiding package time-1.1.2.2 to avoid conflict with later version time-1.1.2.3\r\nhiding package zlib-0.4.0.4 to avoid conflict with later version zlib-0.5.0.0\r\nhiding package HTTP-3001.1.4 to avoid conflict with later version HTTP-3001.1.5\r\nhiding package regex-posix-0.93.2 to avoid conflict with later version regex-posix-0.94.1\r\nhiding package utf8-string-0.3.3 to avoid conflict with later version utf8-string-0.3.4\r\nhiding package binary-0.4.3.1 to avoid conflict with later version binary-0.4.4\r\nhiding package zip-archive-0.1.1.1 to avoid conflict with later version zip-archive-0.1.1.3\r\nhiding package binary-0.4.4 to avoid conflict with later version binary-0.5\r\nhiding package haddock-2.4.1 to avoid conflict with later version haddock-2.4.2\r\nhiding package HTTP-3001.1.5 to avoid conflict with later version HTTP-4000.0.0\r\nhiding package hscolour-1.10.1 to avoid conflict with later version hscolour-1.11\r\nhiding package HTTP-4000.0.0 to avoid conflict with later version HTTP-4000.0.1\r\nhiding package haskell-src-exts-0.4.6 to avoid conflict with later version haskell-src-exts-0.4.8\r\nhiding package HTTP-4000.0.1 to avoid conflict with later version HTTP-4000.0.4\r\nhiding package digest-0.0.0.1 to avoid conflict with later version digest-0.0.0.2\r\nhiding package level-monad-0.2.1 to avoid conflict with later version level-monad-0.3\r\nhiding package HTTP-4000.0.4 to avoid conflict with later version HTTP-4000.0.7\r\nhiding package digest-0.0.0.2 to avoid conflict with later version digest-0.0.0.4\r\nhiding package terminfo-0.2.2.1 to avoid conflict with later version terminfo-0.3.0.2\r\nhiding package stream-monad-0.1 to avoid conflict with later version stream-monad-0.1.1.0\r\nhiding package tree-monad-0.1 to avoid conflict with later version tree-monad-0.1.1\r\nhiding package parallel-tree-search-0.2.1 to avoid conflict with later version parallel-tree-search-0.4\r\nhiding package explicit-sharing-0.2 to avoid conflict with later version explicit-sharing-0.3.1.1\r\nhiding package tree-monad-0.1.1 to avoid conflict with later version tree-monad-0.2\r\nhiding package tree-monad-0.2 to avoid conflict with later version tree-monad-0.2.1\r\nhiding package parallel-tree-search-0.4 to avoid conflict with later version parallel-tree-search-0.4.1\r\nhiding package level-monad-0.3 to avoid conflict with later version level-monad-0.3.1\r\nhiding package explicit-sharing-0.3.1.1 to avoid conflict with later version explicit-sharing-0.3.1.2\r\nhiding package explicit-sharing-0.3.1.2 to avoid conflict with later version explicit-sharing-0.3.1.3\r\nhiding package explicit-sharing-0.3.1.3 to avoid conflict with later version explicit-sharing-0.4.0\r\nhiding package explicit-sharing-0.4.0 to avoid conflict with later version explicit-sharing-0.5.0\r\nwired-in package ghc-prim mapped to ghc-prim-0.1.0.0\r\nwired-in package integer mapped to integer-0.1.0.0\r\nwired-in package base mapped to base-4.0.0.0\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0.1.0\r\nwired-in package syb mapped to syb-0.1.0.0\r\nwired-in package template-haskell mapped to template-haskell-2.3.0.0\r\nwired-in package dph-seq mapped to dph-seq-0.3\r\nwired-in package dph-par mapped to dph-par-0.3\r\nHsc static flags: -static\r\n*** Chasing dependencies:\r\nChasing modules from: *original.hs\r\nStable obj: [Main]\r\nStable BCO: []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = Thu Jun 4 13:23:20 CEST 2009\r\n ms_mod = main:Main,\r\n ms_imps = [Control.Monad.Cont]\r\n ms_srcimps = []\r\n }]\r\ncompile: input file original.hs\r\nCreated temporary directory: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0\r\n*** Checking old interface for main:Main:\r\n[1 of 1] Compiling Main ( original.hs, original.o )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Desugar:\r\n Result size = 753\r\n*** Core Linted result of Desugar:\r\n*** Simplify:\r\n Result size = 290\r\n*** Core Linted result of Simplifier phase gentle, iteration 1 out of 4:\r\n Result size = 280\r\n*** Core Linted result of Simplifier phase gentle, iteration 2 out of 4:\r\n Result size = 280\r\n*** Core Linted result of Simplify phase gentle done:\r\n*** Specialise:\r\n Result size = 331\r\n*** Core Linted result of Specialise:\r\n*** Float out (not lambdas, not constants):\r\n Result size = 351\r\n*** Core Linted result of Float out (not lambdas, not constants):\r\n*** Float inwards:\r\n Result size = 351\r\n*** Core Linted result of Float inwards:\r\n*** Simplify:\r\n Result size = 587\r\n*** Core Linted result of Simplifier phase 2 [main], iteration 1 out of 4:\r\n Result size = 390\r\n*** Core Linted result of Simplifier phase 2 [main], iteration 2 out of 4:\r\n Result size = 304\r\n*** Core Linted result of Simplify phase 2 [main] done:\r\n*** Simplify:\r\n Result size = 287\r\n*** Core Linted result of Simplifier phase 1 [main], iteration 1 out of 4:\r\n Result size = 287\r\n*** Core Linted result of Simplify phase 1 [main] done:\r\n*** Simplify:\r\n Result size = 330\r\n*** Core Linted result of Simplifier phase 0 [main], iteration 1 out of 4:\r\n Result size = 310\r\n*** Core Linted result of Simplifier phase 0 [main], iteration 2 out of 4:\r\n Result size = 304\r\n*** Core Linted result of Simplifier phase 0 [main], iteration 3 out of 4:\r\n Result size = 304\r\n*** Core Linted result of Simplify phase 0 [main] done:\r\n*** Demand analysis:\r\n Result size = 304\r\n*** Core Linted result of Demand analysis:\r\n*** Worker Wrapper binds:\r\n Result size = 330\r\n*** Core Linted result of Worker Wrapper binds:\r\n*** GlomBinds:\r\n*** Simplify:\r\n Result size = 345\r\n*** Core Linted result of Simplifier phase 0 [post-worker-wrapper], iteration 1 out of 4:\r\n Result size = 345\r\n*** Core Linted result of Simplify phase 0 [post-worker-wrapper] done:\r\n*** Float out (not lambdas, constants):\r\n Result size = 353\r\n*** Core Linted result of Float out (not lambdas, constants):\r\n*** Common sub-expression:\r\n Result size = 352\r\n*** Core Linted result of Common sub-expression:\r\n*** Float inwards:\r\n Result size = 352\r\n*** Core Linted result of Float inwards:\r\n*** Simplify:\r\n Result size = 353\r\n*** Core Linted result of Simplifier phase 0 [final], iteration 1 out of 4:\r\n Result size = 353\r\n*** Core Linted result of Simplify phase 0 [final] done:\r\n*** Tidy Core:\r\n Result size = 353\r\n*** Core Linted result of Tidy Core:\r\nwriteBinIface: 49 Names\r\nwriteBinIface: 98 dict entries\r\n*** CorePrep:\r\n Result size = 430\r\n*** Core Linted result of CorePrep:\r\n*** Stg2Stg:\r\n*** CodeGen:\r\n*** CodeOutput:\r\n*** Assembler:\r\ngcc -I. -c /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s -o original.o\r\n*** Deleting temp files:\r\nDeleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: \r\nlink: linkables are ...\r\nLinkableM (Thu Jun 4 13:55:23 CEST 2009) main:Main\r\n [DotO original.o]\r\nLinking original ...\r\n*** Linker:\r\ngcc -v -o original -DDONT_WANT_WIN32_DLL_SUPPORT original.o -L/Library/Frameworks/GHC.framework\r\n/Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr\r\n/lib/ghc-6.10.1/base-4.0.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/\r\ninteger-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0\r\n -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1 -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0\r\n -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lffi -lgmp -ldl -u _ghczmprim_GHCziTypes_Izh_static_info\r\n -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info \r\n-u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info\r\n -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info\r\n -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info\r\n -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info\r\n -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info\r\n -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info\r\n -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure\r\n -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure\r\n -u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure\r\n -u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure\r\n -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure\r\n -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure\r\n -u _base_GHCziConc_ensureIOManagerIsRunning_closure -Wl,-search_paths_first\r\nUsing built-in specs.\r\nTarget: i686-apple-darwin9\r\nConfigured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr\r\n --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/\r\n --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple\r\n --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9\r\nThread model: posix\r\ngcc version 4.0.1 (Apple Inc. build 5488)\r\n /usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.7\r\n -weak_reference_mismatches non-weak -u _ghczmprim_GHCziTypes_Izh_static_info \r\n-u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info\r\n -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info\r\n -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info\r\n -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info\r\n -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info\r\n -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info\r\n -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info\r\n -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure\r\n -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure\r\n -u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure\r\n -u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure\r\n -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure\r\n -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure\r\n -u _base_GHCziConc_ensureIOManagerIsRunning_closure -o original -lcrt1.10.5.o -L/Library/Frameworks/GHC.framework/\r\nVersions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/base-4.0.0.0\r\n -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/integer-0.1.0.0 -L/Library/Frameworks/GHC.framework\r\n/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1\r\n -L/usr/lib/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1\r\n -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1\r\n/../../.. original.o -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0 -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm \r\n-lffi -lgmp -ldl -search_paths_first -lgcc_s.10.5 -lgcc -lSystem\r\nlink: done\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Deleting temp dirs:\r\nDeleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0\r\n\r\n$ ./original \r\n^C <increasing space usage>\r\n\r\n$ ghc -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <constant space>\r\n\r\n13:50 memleak$ ghc -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing space usage>\r\n}}}\r\n\r\nI have checked with ghc-6.8.2 on \"Linux 2.6.27-11-generic 1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux\" and with ghc-6.10.1 and 6.11.200903331 on \"Darwin 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386\"\r\n\r\nHere are some more runs with -fno-full-laziness and/or -fno-cse. Neither switch affects the memory requirements with -O:\r\n\r\n{{{\r\n$ ghc -fno-full-laziness -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing memory usage>\r\n\r\n$ ghc -fno-cse -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing memory usage>\r\n\r\n$ ghc -fno-full-laziness -fno-cse -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing memory usage>\r\n}}}\r\n\r\nThe program original.hs contains an alternative implementation of 'iterDepth' that seems to hint at the problem. I think, the argument of 'runDepthBound' is held in memory for a good reason there.\r\n\r\nThe program condensed.hs contains four superflous occurrences of 'id' that seem to play together to cause the memory leak. If all of them are present then the program uses lots of space with -O, if either one is missing it runs in constant space. The program always runs in constant space without -O. I think, the space leak is caused by holding the arguments of 'id' in memory. If that is true, however, I don't see why *all* occurrences of 'id' are necessary to cause the leak.\r\n\r\nI think the original program and all versions of the condensed program should run in constant space with and without -O. It would be nice if the alternative version of the original program would run in constant space too but I see that there is sharing that may prevent this.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3331control-monad-queue performance regression2019-07-07T19:04:23ZLeon P Smithleon.p.smith@gmail.comcontrol-monad-queue performance regression```
$ cabal unpack control-monad-queue
$ cd control-monad-queue-0.0.9.1/tests
$ ghc --make -O2 Time.hs -i..
$ ./Time allison 34 20
$ ./Time corec1 34 20
$ ./Time corec2 34 20
```
Runs anywhere from 16-32% slower on GHC 6.10.3 than GHC...```
$ cabal unpack control-monad-queue
$ cd control-monad-queue-0.0.9.1/tests
$ ghc --make -O2 Time.hs -i..
$ ./Time allison 34 20
$ ./Time corec1 34 20
$ ./Time corec2 34 20
```
Runs anywhere from 16-32% slower on GHC 6.10.3 than GHC 6.8.3, and allocates significantly more memory.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.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":"control-monad-queue performance regression","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ cabal unpack control-monad-queue\r\n$ cd control-monad-queue-0.0.9.1/tests\r\n$ ghc --make -O2 Time.hs -i..\r\n$ ./Time allison 34 20\r\n$ ./Time corec1 34 20\r\n$ ./Time corec2 34 20\r\n}}}\r\n\r\nRuns anywhere from 16-32% slower on GHC 6.10.3 than GHC 6.8.3, and allocates significantly more memory. ","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3540Parser accepts malformed types with implicit parameters2019-07-07T19:03:25ZbenlParser accepts malformed types with implicit parametersThe parser in GHC 6.11 currently accepts this:
```
thing :: (?dude :: Int) -> Int
thing = undefined
```
Where the type should really be written with =\> like
```
thing :: (?dude :: Int) => Int
thing = undefined
```
Running hlint on t...The parser in GHC 6.11 currently accepts this:
```
thing :: (?dude :: Int) -> Int
thing = undefined
```
Where the type should really be written with =\> like
```
thing :: (?dude :: Int) => Int
thing = undefined
```
Running hlint on the malformed-but-accepted-by-GHC version crashes haskell-src-exts:
```
benl@humboldt:~$ cat tmp/Main.hs
main = undefined
thing :: (?dude :: Int) -> Int
thing = undefined
benl@humboldt:~$ hlint tmp/Main.hs
hlint: src/Language/Haskell/Exts/ParseUtils.hs:(841,18)-(863,53): Non-exhaustive patterns in case
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parser accepts malformed types with implicit parameters","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nThe parser in GHC 6.11 currently accepts this:\r\n{{{\r\nthing :: (?dude :: Int) -> Int\r\nthing = undefined\r\n}}}\r\n\r\nWhere the type should really be written with => like\r\n{{{\r\nthing :: (?dude :: Int) => Int\r\nthing = undefined\r\n}}}\r\n\r\nRunning hlint on the malformed-but-accepted-by-GHC version crashes haskell-src-exts:\r\n{{{\r\nbenl@humboldt:~$ cat tmp/Main.hs \r\nmain = undefined\r\n\r\nthing :: (?dude :: Int) -> Int\r\nthing = undefined\r\n\r\nbenl@humboldt:~$ hlint tmp/Main.hs \r\nhlint: src/Language/Haskell/Exts/ParseUtils.hs:(841,18)-(863,53): Non-exhaustive patterns in case\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3641^L Does Not Work Anymore in Interactive Mode for 6.10.x?2019-07-07T19:03:00ZAviator^L Does Not Work Anymore in Interactive Mode for 6.10.x?I use Ctrl+L a lot to clear the terminal. The clear screen feature is incorporated in various Unix shells, also programming language interpreters like Python. This worked in 6.8.x as I can remember, but not in 6.10.x.
I don't know if so...I use Ctrl+L a lot to clear the terminal. The clear screen feature is incorporated in various Unix shells, also programming language interpreters like Python. This worked in 6.8.x as I can remember, but not in 6.10.x.
I don't know if someone has posted a similar bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"^L Does Not Work Anymore in Interactive Mode for 6.10.x?","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I use Ctrl+L a lot to clear the terminal. The clear screen feature is incorporated in various Unix shells, also programming language interpreters like Python. This worked in 6.8.x as I can remember, but not in 6.10.x.\r\n\r\nI don't know if someone has posted a similar bug.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchjudahjudahhttps://gitlab.haskell.org/ghc/ghc/-/issues/3664Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate)2019-07-07T19:02:53ZSergei TrofimovichGhc eats tremendous heaps of RAM in -prof build (highlighting-kate)Tried to build **highlighting-kate-0.2.5** from hackage with ghc-6.12rc1
and could not wait build result. Ghc ate 2.5BG of ram in 6 minutes, then I
stopped it as machine swapped horribly.
```
$ ghc --info
[("Project name","The Glorious...Tried to build **highlighting-kate-0.2.5** from hackage with ghc-6.12rc1
and could not wait build result. Ghc ate 2.5BG of ram in 6 minutes, then I
stopped it as machine swapped horribly.
```
$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("Project version","6.12.0.20091010")
,("Booter version","6.10.4")
,("Stage","2")
,("Have interpreter","YES")
,("Object splitting","YES")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Unregisterised","NO")
,("Tables next to code","YES")
,("Win32 DLLs","")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn")
,("Leading underscore","NO")
,("Debug on","False")
,("LibDir","/usr/lib64/ghc-6.12.0.20091010")
```
```
* Using cabal-1.8.0.
[1 of 1] Compiling Main ( /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.lhs, /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.o )
Linking setup ...
Configuring highlighting-kate-0.2.5...
Flags chosen: executable=True, splitbase=True
Dependency base >=3 && <5: using base-4.2.0.0
Dependency containers -any: using containers-0.3.0.0
Dependency filepath -any: using filepath-1.1.0.3
Dependency parsec <3: using parsec-2.1.0.1
Dependency pcre-light -any: using pcre-light-0.3.1
Dependency xhtml -any: using xhtml-3000.2.0.1
Using Cabal-1.8.0 compiled by ghc-6.12
Using compiler: ghc-6.12.0.20091010
```
1. ..
```
/usr/bin/gcc /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064.c -o /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064 -D__GLASGOW_HASKELL__=612 -I. -O0 -O0 -I/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5/include -I/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0/include -I/usr/lib64/ghc-6.12.0.20091010/include -I/usr/lib64/ghc-6.12.0.20091010/include -L/usr/lib64/xhtml-3000.2.0.1/ghc-6.12.0.20091010 -L/usr/lib64/pcre-light-0.3.1/ghc-6.12.0.20091010 -L/usr/lib64/parsec-2.1.0.1/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010/filepath-1.1.0.3 -L/usr/lib64/ghc-6.12.0.20091010/containers-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5 -L/usr/lib64/ghc-6.12.0.20091010/array-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/integer-gmp-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/ghc-prim-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010
Preprocessing library highlighting-kate-0.2.5...
Preprocessing executables for highlighting-kate-0.2.5...
Building highlighting-kate-0.2.5...
```
1. ..
```
[41 of 61] Compiling Text.Highlighting.Kate.Syntax.Php ( Text/Highlighting/Kate/Syntax/Php.hs, dist/build/Text/Highlighting/Kate/Syntax/Php.p_o )
Ctrl+C
VIRT: 2.5G RAM, RSS 1.2G RAM, swap activity is large.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 RC1 |
| 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 eats tremendous heaps of RAM in -prof build (highlighting-kate)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Tried to build '''highlighting-kate-0.2.5''' from hackage with ghc-6.12rc1\r\nand could not wait build result. Ghc ate 2.5BG of ram in 6 minutes, then I\r\nstopped it as machine swapped horribly.\r\n\r\n{{{\r\n$ ghc --info\r\n [(\"Project name\",\"The Glorious Glasgow Haskell Compilation System\")\r\n ,(\"Project version\",\"6.12.0.20091010\")\r\n ,(\"Booter version\",\"6.10.4\")\r\n ,(\"Stage\",\"2\")\r\n ,(\"Have interpreter\",\"YES\")\r\n ,(\"Object splitting\",\"YES\")\r\n ,(\"Have native code generator\",\"YES\")\r\n ,(\"Support SMP\",\"YES\")\r\n ,(\"Unregisterised\",\"NO\")\r\n ,(\"Tables next to code\",\"YES\")\r\n ,(\"Win32 DLLs\",\"\")\r\n ,(\"RTS ways\",\"l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn\")\r\n ,(\"Leading underscore\",\"NO\")\r\n ,(\"Debug on\",\"False\")\r\n ,(\"LibDir\",\"/usr/lib64/ghc-6.12.0.20091010\")\r\n}}}\r\n\r\n{{{\r\n * Using cabal-1.8.0.\r\n[1 of 1] Compiling Main ( /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.lhs, /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.o )\r\nLinking setup ...\r\nConfiguring highlighting-kate-0.2.5...\r\nFlags chosen: executable=True, splitbase=True\r\nDependency base >=3 && <5: using base-4.2.0.0\r\nDependency containers -any: using containers-0.3.0.0\r\nDependency filepath -any: using filepath-1.1.0.3\r\nDependency parsec <3: using parsec-2.1.0.1\r\nDependency pcre-light -any: using pcre-light-0.3.1\r\nDependency xhtml -any: using xhtml-3000.2.0.1\r\nUsing Cabal-1.8.0 compiled by ghc-6.12\r\nUsing compiler: ghc-6.12.0.20091010\r\n}}}\r\n...\r\n{{{\r\n/usr/bin/gcc /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064.c -o /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064 -D__GLASGOW_HASKELL__=612 -I. -O0 -O0 -I/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5/include -I/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0/include -I/usr/lib64/ghc-6.12.0.20091010/include -I/usr/lib64/ghc-6.12.0.20091010/include -L/usr/lib64/xhtml-3000.2.0.1/ghc-6.12.0.20091010 -L/usr/lib64/pcre-light-0.3.1/ghc-6.12.0.20091010 -L/usr/lib64/parsec-2.1.0.1/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010/filepath-1.1.0.3 -L/usr/lib64/ghc-6.12.0.20091010/containers-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5 -L/usr/lib64/ghc-6.12.0.20091010/array-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/integer-gmp-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/ghc-prim-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010\r\nPreprocessing library highlighting-kate-0.2.5...\r\nPreprocessing executables for highlighting-kate-0.2.5...\r\nBuilding highlighting-kate-0.2.5...\r\n}}}\r\n...\r\n{{{\r\n[41 of 61] Compiling Text.Highlighting.Kate.Syntax.Php ( Text/Highlighting/Kate/Syntax/Php.hs, dist/build/Text/Highlighting/Kate/Syntax/Php.p_o )\r\n \r\nCtrl+C\r\nVIRT: 2.5G RAM, RSS 1.2G RAM, swap activity is large.\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3772Methods not inlined2019-07-07T19:02:14Zrl@cse.unsw.edu.auMethods not inlinedThis affects both 6.12 and the HEAD (albeit differently) but works fine with 6.10. It also works if everything is in one module. We are interested in the function `U.foo`; in particular, we want the call to `deepSeq` (resulting from inli...This affects both 6.12 and the HEAD (albeit differently) but works fine with 6.10. It also works if everything is in one module. We are interested in the function `U.foo`; in particular, we want the call to `deepSeq` (resulting from inlining `T.apply`) to be inlined. This is what we get with 6.10 (compiling with `-O2`):
```
go_riA :: [GHC.Types.Double] -> ()
go_riA =
\ (ds_agP :: [GHC.Types.Double]) ->
case ds_agP of wild_agQ {
[] -> GHC.Unit.();
: y_agU ys_agV ->
case y_agU of tpl2_ah1 { GHC.Types.D# ipv_ah3 -> go_riA ys_agV }
}
U.foo :: GHC.Types.Int -> ()
U.foo =
\ (n_afR :: GHC.Types.Int) ->
case n_afR of w_Xhn { GHC.Types.I# ww_ahi ->
go_riA (T.$wgen @ GHC.Types.Double T.$f2 ww_ahi)
}
```
Everything has been nicely inlined. With 6.12, we get this:
```
U.foo [NEVER Nothing] :: GHC.Types.Int -> ()
U.foo =
\ (n_adD :: GHC.Types.Int) ->
case n_adD of _ { GHC.Types.I# ww_afv ->
let {
eta_sgc :: [GHC.Types.Double]
eta_sgc = T.$wgen @ GHC.Types.Double T.$fCDouble ww_afv } in
__inline_me (GHC.Base.foldr
@ GHC.Types.Double @ () (T.$fCDouble1 @ ()) GHC.Unit.() eta_sgc)
}
```
The `deepSeq` call has been inlined but hasn't been optimised, I guess because GHC retained the `__inline_me` for some reason. Things are even worse with the HEAD:
```
U.foo :: GHC.Types.Int -> ()
U.foo =
\ (n_aaO :: GHC.Types.Int) ->
case n_aaO of _ { GHC.Types.I# ww_abR ->
T.$fC[]1
@ GHC.Types.Double
T.$fCDouble
@ ()
(T.$w$cgen @ GHC.Types.Double T.$fCDouble ww_abR)
GHC.Unit.()
}
```
Here, `deepSeq` hasn't even been inlined. But let's add a dummy method to `DeepSeq`:
```
class DeepSeq a where
deepSeq :: a -> b -> b
dummy :: a
dummy = undefined
```
Now, the HEAD actually inlines the call:
```
go_rcM :: [GHC.Types.Double] -> ()
go_rcM =
\ (ds_acl :: [GHC.Types.Double]) ->
case ds_acl of _ {
[] -> GHC.Unit.();
: y_acq ys_acr ->
case y_acq of _ { GHC.Types.D# _ -> go_rcM ys_acr }
}
U.foo :: GHC.Types.Int -> ()
U.foo =
\ (n_aaQ :: GHC.Types.Int) ->
case n_aaQ of _ { GHC.Types.I# ww_abI ->
go_rcM (T.$w$cgen @ GHC.Types.Double T.$fCDouble ww_abI)
}
```
Unfortunately, 6.12 still doesn't.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Methods not inlined","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This affects both 6.12 and the HEAD (albeit differently) but works fine with 6.10. It also works if everything is in one module. We are interested in the function `U.foo`; in particular, we want the call to `deepSeq` (resulting from inlining `T.apply`) to be inlined. This is what we get with 6.10 (compiling with `-O2`):\r\n{{{\r\ngo_riA :: [GHC.Types.Double] -> ()\r\ngo_riA =\r\n \\ (ds_agP :: [GHC.Types.Double]) ->\r\n case ds_agP of wild_agQ {\r\n [] -> GHC.Unit.();\r\n : y_agU ys_agV ->\r\n case y_agU of tpl2_ah1 { GHC.Types.D# ipv_ah3 -> go_riA ys_agV }\r\n }\r\n\r\nU.foo :: GHC.Types.Int -> ()\r\nU.foo =\r\n \\ (n_afR :: GHC.Types.Int) ->\r\n case n_afR of w_Xhn { GHC.Types.I# ww_ahi ->\r\n go_riA (T.$wgen @ GHC.Types.Double T.$f2 ww_ahi)\r\n }\r\n}}}\r\nEverything has been nicely inlined. With 6.12, we get this:\r\n{{{\r\nU.foo [NEVER Nothing] :: GHC.Types.Int -> ()\r\nU.foo =\r\n \\ (n_adD :: GHC.Types.Int) ->\r\n case n_adD of _ { GHC.Types.I# ww_afv ->\r\n let {\r\n eta_sgc :: [GHC.Types.Double]\r\n eta_sgc = T.$wgen @ GHC.Types.Double T.$fCDouble ww_afv } in\r\n __inline_me (GHC.Base.foldr\r\n @ GHC.Types.Double @ () (T.$fCDouble1 @ ()) GHC.Unit.() eta_sgc)\r\n }\r\n}}}\r\nThe `deepSeq` call has been inlined but hasn't been optimised, I guess because GHC retained the `__inline_me` for some reason. Things are even worse with the HEAD:\r\n{{{\r\nU.foo :: GHC.Types.Int -> ()\r\nU.foo =\r\n \\ (n_aaO :: GHC.Types.Int) ->\r\n case n_aaO of _ { GHC.Types.I# ww_abR ->\r\n T.$fC[]1\r\n @ GHC.Types.Double\r\n T.$fCDouble\r\n @ ()\r\n (T.$w$cgen @ GHC.Types.Double T.$fCDouble ww_abR)\r\n GHC.Unit.()\r\n }\r\n}}}\r\nHere, `deepSeq` hasn't even been inlined. But let's add a dummy method to `DeepSeq`:\r\n{{{\r\nclass DeepSeq a where\r\n deepSeq :: a -> b -> b\r\n\r\n dummy :: a\r\n dummy = undefined\r\n}}}\r\nNow, the HEAD actually inlines the call:\r\n{{{\r\ngo_rcM :: [GHC.Types.Double] -> ()\r\ngo_rcM =\r\n \\ (ds_acl :: [GHC.Types.Double]) ->\r\n case ds_acl of _ {\r\n [] -> GHC.Unit.();\r\n : y_acq ys_acr ->\r\n case y_acq of _ { GHC.Types.D# _ -> go_rcM ys_acr }\r\n }\r\n\r\nU.foo :: GHC.Types.Int -> ()\r\nU.foo =\r\n \\ (n_aaQ :: GHC.Types.Int) ->\r\n case n_aaQ of _ { GHC.Types.I# ww_abI ->\r\n go_rcM (T.$w$cgen @ GHC.Types.Double T.$fCDouble ww_abI)\r\n }\r\n}}}\r\nUnfortunately, 6.12 still doesn't.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3853make tags work in the new build system2019-07-07T19:01:51ZIan Lynagh <igloo@earth.li>make tags work in the new build systemMake tags work in the new build system.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | ...Make tags work in the new build system.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"make tags work in the new build system","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Make tags work in the new build system.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3856Share code between C wrappers2019-07-07T19:01:50ZIan Lynagh <igloo@earth.li>Share code between C wrappers`driver/ghci/ghci.c` and `driver/gcc/gcc.c` do more-or-less the same thing in different ways; I think `gcc.c` is the newer, and simpler. Share code if possible.
<details><summary>Trac metadata</summary>
| Trac field | Value...`driver/ghci/ghci.c` and `driver/gcc/gcc.c` do more-or-less the same thing in different ways; I think `gcc.c` is the newer, and simpler. Share code if possible.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Share code between C wrappers","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"`driver/ghci/ghci.c` and `driver/gcc/gcc.c` do more-or-less the same thing in different ways; I think `gcc.c` is the newer, and simpler. Share code if possible.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/4237-dcore-lint error after simplifier iteration 1 when profiling2019-07-07T18:59:55ZWolfram Kahl-dcore-lint error after simplifier iteration 1 when profilingThis happens with the current development version of Agda, with last change from July 20.
```
darcs get --lazy http://code.haskell.org/Agda
```
I did:
```
./Setup configure -p --prefix=/usr/local/packages/ghc-6.12.3 --ghc-option=-dcor...This happens with the current development version of Agda, with last change from July 20.
```
darcs get --lazy http://code.haskell.org/Agda
```
I did:
```
./Setup configure -p --prefix=/usr/local/packages/ghc-6.12.3 --ghc-option=-dcore-lint
./Setup build -v > build.log 2>&1
```
`build.log` is attached, and shows a core-lint error in the profiling way.
I tried this since I am getting segfaults and other errors in long Agda runs with more than 4GB heap, and have no idea yet how to trim them down.
Wolfram
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"-dcore-lint error after simplifier iteration 1 when profiling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["core-lint","profiling,","simplifier,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This happens with the current development version of Agda, with last change from July 20.\r\n\r\n{{{\r\ndarcs get --lazy http://code.haskell.org/Agda\r\n}}}\r\n\r\nI did:\r\n\r\n{{{\r\n./Setup configure -p --prefix=/usr/local/packages/ghc-6.12.3 --ghc-option=-dcore-lint\r\n./Setup build -v > build.log 2>&1\r\n}}}\r\n\r\n{{{build.log}}} is attached, and shows a core-lint error in the profiling way.\r\n\r\nI tried this since I am getting segfaults and other errors in long Agda runs with more than 4GB heap, and have no idea yet how to trim them down.\r\n\r\nWolfram","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branch