GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:51:10Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7138GHCi does no respect -ignore-dot-ghci anymore2019-07-07T18:51:10ZSimon Hengelsol@typeful.netGHCi does no respect -ignore-dot-ghci anymoreSteps to reproduce:
```
$ echo foobar > .ghci
$ ghci -ignore-dot-ghci
```
Expected results: GHCi is started without any errors.
Actual result: GHCi reports "Not in scope: \`foobar'".
<details><summary>Trac metadata</summary>
| Trac ...Steps to reproduce:
```
$ echo foobar > .ghci
$ ghci -ignore-dot-ghci
```
Expected results: GHCi is started without any errors.
Actual result: GHCi reports "Not in scope: \`foobar'".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi does no respect -ignore-dot-ghci anymore","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Steps to reproduce:\r\n\r\n{{{\r\n$ echo foobar > .ghci\r\n$ ghci -ignore-dot-ghci\r\n}}}\r\n\r\nExpected results: GHCi is started without any errors.\r\n\r\nActual result: GHCi reports \"Not in scope: `foobar'\".","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/7137Unnecessary -XRank2Types requirement involving type alias containing "forall"...2019-07-07T18:51:10ZjoeyadamsUnnecessary -XRank2Types requirement involving type alias containing "forall" from another moduleThe following builds with GHC 7.4, but not 7.6.
**Bottom.hs**
```
{-# LANGUAGE Rank2Types #-}
module Bottom where
type Bottom = forall a. a
data Pipe l i o u m r = Pipe
type GSource m o = forall l i u. Pipe l i o u m ()
```
**Main.h...The following builds with GHC 7.4, but not 7.6.
**Bottom.hs**
```
{-# LANGUAGE Rank2Types #-}
module Bottom where
type Bottom = forall a. a
data Pipe l i o u m r = Pipe
type GSource m o = forall l i u. Pipe l i o u m ()
```
**Main.hs**
```
import Bottom
myBottom :: Int -> Bottom
myBottom _ = error "Bottom"
main :: IO ()
main = myBottom 3
```
Note that Main.hs does not have the Rank2Types extension turned on.
myBottom does not have a rank-2 type. After expanding the type alias, you get:
```
myBottom :: Int -> forall a. a
```
This is logically equivalent to:
```
myBottom :: forall a. Int -> a
```
GHC 7.4.2 accepts this use of type alias, but GHC 7.6 does not.
Note that if we make something that does in fact expand to a rank-2 type:
```
foo :: Bottom -> Int
foo x = x
```
GHC 7.4.2 correctly rejects the program unless you enable Rank2Types.
Also, if we use a standalone Bottom type alias:
```
myBottom :: Bottom
```
Then GHC 7.6 accepts the program. It does not accept Int -\> Bottom without Rank2Types, but it does accept Bottom by itself.
This issue is easy to work around: just add {-\# LANGUAGE Rank2Types \#-} or {-\# LANGUAGE RankNTypes \#-} to the top of the module.
Is this a bug, or have the rules for type aliases and forall been deliberately tightened?
P.S.: This ticket is for GHC 7.6.1-rc1. That version tag is not available, though.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unnecessary -XRank2Types requirement involving type alias containing \"forall\" from another module","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following builds with GHC 7.4, but not 7.6.\r\n\r\n'''Bottom.hs'''\r\n{{{\r\n{-# LANGUAGE Rank2Types #-}\r\nmodule Bottom where\r\n\r\ntype Bottom = forall a. a\r\n\r\ndata Pipe l i o u m r = Pipe\r\ntype GSource m o = forall l i u. Pipe l i o u m ()\r\n}}}\r\n\r\n\r\n'''Main.hs'''\r\n{{{\r\nimport Bottom\r\n\r\nmyBottom :: Int -> Bottom\r\nmyBottom _ = error \"Bottom\"\r\n\r\nmain :: IO ()\r\nmain = myBottom 3\r\n}}}\r\n\r\nNote that Main.hs does not have the Rank2Types extension turned on.\r\n\r\nmyBottom does not have a rank-2 type. After expanding the type alias, you get:\r\n\r\n{{{\r\nmyBottom :: Int -> forall a. a\r\n}}}\r\n\r\nThis is logically equivalent to:\r\n\r\n{{{\r\nmyBottom :: forall a. Int -> a\r\n}}}\r\n\r\nGHC 7.4.2 accepts this use of type alias, but GHC 7.6 does not.\r\n\r\nNote that if we make something that does in fact expand to a rank-2 type:\r\n\r\n{{{\r\nfoo :: Bottom -> Int\r\nfoo x = x\r\n}}}\r\n\r\nGHC 7.4.2 correctly rejects the program unless you enable Rank2Types.\r\n\r\nAlso, if we use a standalone Bottom type alias:\r\n\r\n{{{\r\nmyBottom :: Bottom\r\n}}}\r\n\r\nThen GHC 7.6 accepts the program. It does not accept Int -> Bottom without Rank2Types, but it does accept Bottom by itself.\r\n\r\nThis issue is easy to work around: just add {-# LANGUAGE Rank2Types #-} or {-# LANGUAGE RankNTypes #-} to the top of the module.\r\n\r\nIs this a bug, or have the rules for type aliases and forall been deliberately tightened?\r\n\r\nP.S.: This ticket is for GHC 7.6.1-rc1. That version tag is not available, though.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/7134ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC322019-07-07T18:51:11Zcetinsertghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32I downloaded ghc-7.6.0.20120810-x86_64-windows.exe and attempting to run GHCi dumps the following error message:
```
C:\Users\Cetin>ghci
GHCi, version 7.6.0.20120810: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ......I downloaded ghc-7.6.0.20120810-x86_64-windows.exe and attempting to run GHCi dumps the following error message:
```
C:\Users\Cetin>ghci
GHCi, version 7.6.0.20120810: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc.exe: internal error: R_X86_64_PC32: Hig
h bits are set in 7f9585f95a0 for WaitForSingleObject
(GHC version 7.6.0.20120810 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
Tested on Windows 8 Release Preview 64-bit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["R_X86_64_PC32"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I downloaded ghc-7.6.0.20120810-x86_64-windows.exe and attempting to run GHCi dumps the following error message:\r\n\r\n{{{\r\nC:\\Users\\Cetin>ghci\r\nGHCi, version 7.6.0.20120810: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... ghc.exe: internal error: R_X86_64_PC32: Hig\r\nh bits are set in 7f9585f95a0 for WaitForSingleObject\r\n (GHC version 7.6.0.20120810 for x86_64_unknown_mingw32)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nThis application has requested the Runtime to terminate it in an unusual way.\r\nPlease contact the application's support team for more information.\r\n\r\n}}}\r\n\r\nTested on Windows 8 Release Preview 64-bit.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/7132Internal error: stg_ap_v_ret when running indexed_types tests2019-07-07T18:51:12ZRichard Eisenbergrae@richarde.devInternal error: stg_ap_v_ret when running indexed_types testsAfter running `make` in `testsuite/tests/indexed_types`, I got the following output:
```
Unexpected failures:
should_run GMapAssoc [bad exit code] (optllvm)
should_run GMapTop [bad exit code] (optllvm)
should_run T2985 [bad ...After running `make` in `testsuite/tests/indexed_types`, I got the following output:
```
Unexpected failures:
should_run GMapAssoc [bad exit code] (optllvm)
should_run GMapTop [bad exit code] (optllvm)
should_run T2985 [bad exit code] (optllvm)
should_run T4235 [bad exit code] (optllvm)
should_run T5719 [bad exit code] (optllvm)
```
On further examination of these failures, I found that they each produced the following:
```
=====> T4235(optllvm) 2 of 5 [0, 0, 0]
cd . && '/Users/rae/Documents/ghc-pure/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T4235 T4235.hs -O -fllvm >T4235.comp.stderr 2>&1
cd . && ./T4235 </dev/null >T4235.run.stdout 2>T4235.run.stderr
/bin/sh: line 1: 57284 Abort trap: 6 ./T4235 < /dev/null > T4235.run.stdout 2> T4235.run.stderr
Wrong exit code (expected 0 , actual 134 )
Stdout:
Stderr:
T4235: internal error: stg_ap_v_ret
(GHC version 7.7.20120809 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*** unexpected failure for T4235(optllvm)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.5 |
| 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":"Internal error: stg_ap_v_ret when running indexed_types tests","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"After running {{{make}}} in {{{testsuite/tests/indexed_types}}}, I got the following output:\r\n\r\n{{{\r\nUnexpected failures:\r\n should_run GMapAssoc [bad exit code] (optllvm)\r\n should_run GMapTop [bad exit code] (optllvm)\r\n should_run T2985 [bad exit code] (optllvm)\r\n should_run T4235 [bad exit code] (optllvm)\r\n should_run T5719 [bad exit code] (optllvm)\r\n}}}\r\n\r\nOn further examination of these failures, I found that they each produced the following:\r\n\r\n{{{\r\n=====> T4235(optllvm) 2 of 5 [0, 0, 0]\r\ncd . && '/Users/rae/Documents/ghc-pure/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T4235 T4235.hs -O -fllvm >T4235.comp.stderr 2>&1\r\ncd . && ./T4235 </dev/null >T4235.run.stdout 2>T4235.run.stderr\r\n/bin/sh: line 1: 57284 Abort trap: 6 ./T4235 < /dev/null > T4235.run.stdout 2> T4235.run.stderr\r\nWrong exit code (expected 0 , actual 134 )\r\nStdout:\r\n\r\nStderr:\r\nT4235: internal error: stg_ap_v_ret\r\n (GHC version 7.7.20120809 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n*** unexpected failure for T4235(optllvm)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7124polykinds tests failing2019-07-07T18:51:16Zpcapriottipolykinds tests failingSome of the `polykinds` tests are failing with `-fhpc` with core lint errors, namely:
- `Freeman`
- `PolyKinds13`
- `T6015`Some of the `polykinds` tests are failing with `-fhpc` with core lint errors, namely:
- `Freeman`
- `PolyKinds13`
- `T6015`7.6.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/7117Data family constructors defined in GHCi are not in scope2019-07-07T18:51:18ZparcsData family constructors defined in GHCi are not in scopeThe following example explains the problem:
```
> data family Foo a
> data instance Foo Int = FooInt
> :t FooInt
<interactive>:1:1: Not in scope: data constructor `FooInt'
```
`FooInt` is defined, but `GHCi` doesn't recognize it.
<de...The following example explains the problem:
```
> data family Foo a
> data instance Foo Int = FooInt
> :t FooInt
<interactive>:1:1: Not in scope: data constructor `FooInt'
```
`FooInt` is defined, but `GHCi` doesn't recognize it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data family constructors defined in GHCi are not in scope","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following example explains the problem:\r\n\r\n{{{\r\n> data family Foo a\r\n> data instance Foo Int = FooInt\r\n> :t FooInt\r\n\r\n<interactive>:1:1: Not in scope: data constructor `FooInt'\r\n}}}\r\n\r\n`FooInt` is defined, but `GHCi` doesn't recognize it.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/7054Compile failure on non x86/x86-642019-07-07T18:51:36ZerikdCompile failure on non x86/x86-64Compile error as follows on Git HEAD (f3aabb7eae90f68c5f9f22ff0bc7117deb22d57d):
```
HC [stage 0] compiler/stage1/build/X86/Regs.o
compiler/nativeGen/X86/Regs.hs:20:9:
Not in scope: `allHaskellArgRegs'
compiler/nativeGen/X86/Reg...Compile error as follows on Git HEAD (f3aabb7eae90f68c5f9f22ff0bc7117deb22d57d):
```
HC [stage 0] compiler/stage1/build/X86/Regs.o
compiler/nativeGen/X86/Regs.hs:20:9:
Not in scope: `allHaskellArgRegs'
compiler/nativeGen/X86/Regs.hs:22:9:
Not in scope: `instrClobberedRegs'
Perhaps you meant `callClobberedRegs' (line 647)
```
I have a patch for this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.5 |
| 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":"Compile failure on non x86/x86-64","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compile error as follows on Git HEAD (f3aabb7eae90f68c5f9f22ff0bc7117deb22d57d):\r\n\r\n{{{\r\n HC [stage 0] compiler/stage1/build/X86/Regs.o\r\n\r\ncompiler/nativeGen/X86/Regs.hs:20:9:\r\n Not in scope: `allHaskellArgRegs'\r\n\r\ncompiler/nativeGen/X86/Regs.hs:22:9:\r\n Not in scope: `instrClobberedRegs'\r\n Perhaps you meant `callClobberedRegs' (line 647)\r\n}}}\r\n\r\nI have a patch for this.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7040linker failures with foreign global data2019-07-07T18:51:40ZLuite Stegemanlinker failures with foreign global dataOn OS X with X86_64 the attached example crashes (not reliably, might take a few tries, doesn't seem to crash in gdb). A compiled executable always works fine.
<details><summary>Trac metadata</summary>
| Trac field | Value ...On OS X with X86_64 the attached example crashes (not reliably, might take a few tries, doesn't seem to crash in gdb). A compiled executable always works fine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | GhciCrash |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"ghci segfault on OS X X86_64 with foreign global data","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"On OS X with X86_64 the attached example crashes (not reliably, might take a few tries, doesn't seem to crash in gdb). A compiled executable always works fine.\r\n\r\n","type_of_failure":"GhciCrash","blocking":[]} -->7.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/6163GHC stops producing runnable code in OSX Mountain Lion DP42019-07-07T18:51:53ZsmidgetGHC stops producing runnable code in OSX Mountain Lion DP4Yesterday I upgraded my OSX 10.8 Mountain Lion Developer Preview 3 install to Developer Preview 4, and this appears to have broken GHC. I've tried the GHC included in the OSX Haskell-Package 2012.2.0.0 as well as the GHC from Homebrew in...Yesterday I upgraded my OSX 10.8 Mountain Lion Developer Preview 3 install to Developer Preview 4, and this appears to have broken GHC. I've tried the GHC included in the OSX Haskell-Package 2012.2.0.0 as well as the GHC from Homebrew in both 32 and 64 bit versions. Everything worked flawlessly in Developer Previews 2 and 3.
I can compile software just fine, and when I run it it appears to run, but then aborts with a strange closure error. For example, I can run Xmonad for several seconds before it crashes.
I've been able to replicate this in both a fresh install of Mountain Lion DP4 on a clean partition and on my upgrade from DP3.
To replicate, install Mountain Lion DP4 on a fresh partition, install GHC either from Homebrew or Haskell-Package, and try to compile a hello world program. It will compile without error, but when running it, I get:
```
jesse@Mulder:~/temp/hello
> ls
hello.hs typescript
jesse@Mulder:~/temp/hello
> cat hello.hs
main = putStrLn "Hello, World!"
jesse@Mulder:~/temp/hello
> ghc --make hello.hs
[1 of 1] Compiling Main ( hello.hs, hello.o )
Linking hello ...
jesse@Mulder:~/temp/hello
> ./hello
Hello, World!
hello: internal error: evacuate(static): strange closure type 32
(GHC version 7.4.2 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[1] 61943 abort ./hello
```
Xmonad exits with a similar message, as does trying to compile GHC myself. Notice how it prints Hello, World! before it crashes.
Any ideas on how I can provide for information to help debug this would be most appreciated. Life is difficult in OSX without Xmonad.
I have attached the OSX crash log of Xmonad as it may provide some detail into what is going on, but this appears to happen regardless of the program being run.
Kernel:
```
Darwin Mulder.local 12.0.0 Darwin Kernel Version 12.0.0: Thu Jun 7 18:47:37 PDT 2012; root:xnu-2050.6.71~1/RELEASE_X86_64 x86_64
```
GCC:
```
jesse@Mulder:~/temp/hello
> gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.10~42/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.10~42/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.10.00)
```
Normally I wouldn't ask for support for software still in beta, but apparently this release is at least someone close to the final product.
Thank you very much for any assistance!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC stops producing runnable code in OSX Mountain Lion DP4","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":["Lion,","Mountain","OSX,","abort","closure,","strange"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nYesterday I upgraded my OSX 10.8 Mountain Lion Developer Preview 3 install to Developer Preview 4, and this appears to have broken GHC. I've tried the GHC included in the OSX Haskell-Package 2012.2.0.0 as well as the GHC from Homebrew in both 32 and 64 bit versions. Everything worked flawlessly in Developer Previews 2 and 3.\r\n\r\nI can compile software just fine, and when I run it it appears to run, but then aborts with a strange closure error. For example, I can run Xmonad for several seconds before it crashes.\r\n\r\nI've been able to replicate this in both a fresh install of Mountain Lion DP4 on a clean partition and on my upgrade from DP3.\r\n\r\nTo replicate, install Mountain Lion DP4 on a fresh partition, install GHC either from Homebrew or Haskell-Package, and try to compile a hello world program. It will compile without error, but when running it, I get:\r\n\r\n\r\n{{{\r\njesse@Mulder:~/temp/hello\r\n> ls\r\nhello.hs typescript\r\n\r\njesse@Mulder:~/temp/hello\r\n> cat hello.hs \r\nmain = putStrLn \"Hello, World!\"\r\n\r\njesse@Mulder:~/temp/hello\r\n> ghc --make hello.hs \r\n[1 of 1] Compiling Main ( hello.hs, hello.o )\r\nLinking hello ...\r\n\r\njesse@Mulder:~/temp/hello\r\n> ./hello\r\nHello, World!\r\nhello: internal error: evacuate(static): strange closure type 32\r\n (GHC version 7.4.2 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n[1] 61943 abort ./hello\r\n}}}\r\n\r\n\r\nXmonad exits with a similar message, as does trying to compile GHC myself. Notice how it prints Hello, World! before it crashes.\r\n\r\nAny ideas on how I can provide for information to help debug this would be most appreciated. Life is difficult in OSX without Xmonad.\r\n\r\nI have attached the OSX crash log of Xmonad as it may provide some detail into what is going on, but this appears to happen regardless of the program being run.\r\n\r\nKernel:\r\n{{{\r\nDarwin Mulder.local 12.0.0 Darwin Kernel Version 12.0.0: Thu Jun 7 18:47:37 PDT 2012; root:xnu-2050.6.71~1/RELEASE_X86_64 x86_64\r\n}}}\r\n\r\nGCC:\r\n{{{\r\njesse@Mulder:~/temp/hello\r\n> gcc -v\r\nUsing built-in specs.\r\nTarget: i686-apple-darwin11\r\nConfigured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.10~42/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.10~42/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1\r\nThread model: posix\r\ngcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.10.00)\r\n}}}\r\n\r\nNormally I wouldn't ask for support for software still in beta, but apparently this release is at least someone close to the final product.\r\n\r\nThank you very much for any assistance!","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/6151typePrimRep: UbxTupleRep2019-07-07T18:51:56ZSimon MarlowtypePrimRep: UbxTupleRepA handful of new failures appeared in the nightly build recently, perhaps as a result of the changes to unboxed tuple handling. The failures are all with GHCi.
e.g.
```
'/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/...A handful of new failures appeared in the nightly build recently, perhaps as a result of the changes to unboxed tuple handling. The failures are all with GHCi.
e.g.
```
'/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fno-ghci-history cgrun064.hs --interactive -ignore-dot-ghci +RTS -I0.1 -RTS
GHCi, version 7.5.20120607: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( cgrun064.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.5.20120607 for x86_64-unknown-linux):
typePrimRep: UbxTupleRep
(# ghc-prim:GHC.Prim.State#{(w) tc 32q} s{tv v} [tv],
ghc-prim:GHC.Prim.MutableArray#{(w) tc 31m}
s{tv v} [tv] a{tv u} [tv] #)
```
The full set of failures is:
```
array/should_run arr020 [bad stdout or stderr] (ghci)
codeGen/should_run cgrun064 [bad stdout or stderr] (ghci)
codeGen/should_run cgrun065 [bad stdout or stderr] (ghci)
codeGen/should_run cgrun068 [bad stdout or stderr] (ghci)
codeGen/should_run cgrun070 [bad stdout or stderr] (ghci)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"typePrimRep: UbxTupleRep","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A handful of new failures appeared in the nightly build recently, perhaps as a result of the changes to unboxed tuple handling. The failures are all with GHCi.\r\n\r\ne.g.\r\n\r\n{{{\r\n'/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fno-ghci-history cgrun064.hs --interactive -ignore-dot-ghci +RTS -I0.1 -RTS \r\nGHCi, version 7.5.20120607: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( cgrun064.hs, interpreted )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.5.20120607 for x86_64-unknown-linux):\r\n typePrimRep: UbxTupleRep\r\n (# ghc-prim:GHC.Prim.State#{(w) tc 32q} s{tv v} [tv],\r\n ghc-prim:GHC.Prim.MutableArray#{(w) tc 31m}\r\n s{tv v} [tv] a{tv u} [tv] #)\r\n}}}\r\n\r\n\r\nThe full set of failures is:\r\n\r\n{{{\r\n array/should_run arr020 [bad stdout or stderr] (ghci)\r\n codeGen/should_run cgrun064 [bad stdout or stderr] (ghci)\r\n codeGen/should_run cgrun065 [bad stdout or stderr] (ghci)\r\n codeGen/should_run cgrun068 [bad stdout or stderr] (ghci)\r\n codeGen/should_run cgrun070 [bad stdout or stderr] (ghci)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/6143Regression: lots of documentation missing2019-07-07T18:51:58ZSimon MarlowRegression: lots of documentation missingSomething is wrong with the Haddock docs in the HEAD, such that most (but not all) functions have no documentation. Just point your browser at `libraries/base/dist-install/doc/html/base/Prelude.html` in a validate build, and you'll see t...Something is wrong with the Haddock docs in the HEAD, such that most (but not all) functions have no documentation. Just point your browser at `libraries/base/dist-install/doc/html/base/Prelude.html` in a validate build, and you'll see that many functions are missing documentation. The first one I see on that page is `otherwise`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regression: lots of documentation missing","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"7.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Something is wrong with the Haddock docs in the HEAD, such that most (but not all) functions have no documentation. Just point your browser at `libraries/base/dist-install/doc/html/base/Prelude.html` in a validate build, and you'll see that many functions are missing documentation. The first one I see on that page is `otherwise`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/6108Haddock's prune option is not regarded for DEPRECATED things2019-07-07T18:52:08ZSimon Hengelsol@typeful.netHaddock's prune option is not regarded for DEPRECATED thingsI introduced this regression when I extended Haddock, so that it adds deprecation messages for deprecated things to the generated documentation.
This may not sound critical, but it is a rather common use case to prune documentation for ...I introduced this regression when I extended Haddock, so that it adds deprecation messages for deprecated things to the generated documentation.
This may not sound critical, but it is a rather common use case to prune documentation for deprecated things. That way you can keep deprecated stuff around for backward compatibility without cluttering the documentation.
I'd tend to disable the feature for now (a patch set is on my
[disable-support-for-warnings](https://github.com/sol/haddock/tree/disable-support-for-warnings) branch).
Alternatively we could apply a fix for the issue. I have a patch set for that on my [fix-warning-support](https://github.com/sol/haddock/tree/fix-warning-support) branch. But it is not a trivial change.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.4.2-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Haddock's prune option is not regarded for DEPRECATED things","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I introduced this regression when I extended Haddock, so that it adds deprecation messages for deprecated things to the generated documentation.\r\n\r\nThis may not sound critical, but it is a rather common use case to prune documentation for deprecated things. That way you can keep deprecated stuff around for backward compatibility without cluttering the documentation.\r\n\r\nI'd tend to disable the feature for now (a patch set is on my \r\n[https://github.com/sol/haddock/tree/disable-support-for-warnings disable-support-for-warnings] branch).\r\n\r\nAlternatively we could apply a fix for the issue. I have a patch set for that on my [https://github.com/sol/haddock/tree/fix-warning-support fix-warning-support] branch. But it is not a trivial change.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2waernwaernhttps://gitlab.haskell.org/ghc/ghc/-/issues/6104Regression: space leak in HEAD vs. 7.42019-07-07T18:52:09ZSimon MarlowRegression: space leak in HEAD vs. 7.4I often keep an eye on compiler performance by compiling Cabal. Yesterday I noticed that HEAD appears to have a space leak: it needs 806MB to compile Cabal with -O, vs 424MB with 7.4.1.
Here are the results. First 7.4.1:
```
$ ghc-7.4....I often keep an eye on compiler performance by compiling Cabal. Yesterday I noticed that HEAD appears to have a space leak: it needs 806MB to compile Cabal with -O, vs 424MB with 7.4.1.
Here are the results. First 7.4.1:
```
$ ghc-7.4.1 -O --make Distribution.Simple +RTS -s
```
```
53,658,077,704 bytes allocated in the heap
9,679,170,192 bytes copied during GC
148,845,896 bytes maximum residency (56 sample(s))
6,610,216 bytes maximum slop
424 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 102382 colls, 0 par 24.24s 24.22s 0.0002s 0.0046s
Gen 1 56 colls, 0 par 12.48s 12.48s 0.2229s 0.4738s
INIT time 0.00s ( 0.00s elapsed)
MUT time 57.37s ( 60.81s elapsed)
GC time 36.72s ( 36.70s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 94.09s ( 97.52s elapsed)
```
And HEAD:
```
$ ghc-nightly2 -O --make Distribution.Simple +RTS -s
```
```
55,699,304,032 bytes allocated in the heap
11,721,558,728 bytes copied during GC
288,988,200 bytes maximum residency (50 sample(s))
7,808,192 bytes maximum slop
806 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 107655 colls, 0 par 28.83s 28.83s 0.0003s 0.0043s
Gen 1 50 colls, 0 par 16.36s 16.36s 0.3272s 1.0063s
TASKS: 3 (1 bound, 2 peak workers (2 total), using -N1)
INIT time 0.00s ( 0.00s elapsed)
MUT time 59.87s ( 63.18s elapsed)
GC time 45.19s ( 45.19s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 105.07s (108.37s elapsed)
```
We need to squash this before 7.6 is released.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regression: space leak in HEAD vs. 7.4","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I often keep an eye on compiler performance by compiling Cabal. Yesterday I noticed that HEAD appears to have a space leak: it needs 806MB to compile Cabal with -O, vs 424MB with 7.4.1.\r\n\r\nHere are the results. First 7.4.1:\r\n\r\n{{{\r\n$ ghc-7.4.1 -O --make Distribution.Simple +RTS -s\r\n}}}\r\n\r\n{{{\r\n 53,658,077,704 bytes allocated in the heap\r\n 9,679,170,192 bytes copied during GC\r\n 148,845,896 bytes maximum residency (56 sample(s))\r\n 6,610,216 bytes maximum slop\r\n 424 MB total memory in use (0 MB lost due to fragmentation)\r\n\r\n Tot time (elapsed) Avg pause Max pause\r\n Gen 0 102382 colls, 0 par 24.24s 24.22s 0.0002s 0.0046s\r\n Gen 1 56 colls, 0 par 12.48s 12.48s 0.2229s 0.4738s\r\n\r\n INIT time 0.00s ( 0.00s elapsed)\r\n MUT time 57.37s ( 60.81s elapsed)\r\n GC time 36.72s ( 36.70s elapsed)\r\n EXIT time 0.00s ( 0.00s elapsed)\r\n Total time 94.09s ( 97.52s elapsed)\r\n}}}\r\n\r\nAnd HEAD:\r\n\r\n{{{\r\n$ ghc-nightly2 -O --make Distribution.Simple +RTS -s\r\n}}}\r\n\r\n{{{\r\n 55,699,304,032 bytes allocated in the heap\r\n 11,721,558,728 bytes copied during GC\r\n 288,988,200 bytes maximum residency (50 sample(s))\r\n 7,808,192 bytes maximum slop\r\n 806 MB total memory in use (0 MB lost due to fragmentation)\r\n\r\n Tot time (elapsed) Avg pause Max pause\r\n Gen 0 107655 colls, 0 par 28.83s 28.83s 0.0003s 0.0043s\r\n Gen 1 50 colls, 0 par 16.36s 16.36s 0.3272s 1.0063s\r\n\r\n TASKS: 3 (1 bound, 2 peak workers (2 total), using -N1)\r\n\r\n INIT time 0.00s ( 0.00s elapsed)\r\n MUT time 59.87s ( 63.18s elapsed)\r\n GC time 45.19s ( 45.19s elapsed)\r\n EXIT time 0.00s ( 0.00s elapsed)\r\n Total time 105.07s (108.37s elapsed)\r\n}}}\r\n\r\nWe need to squash this before 7.6 is released.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/6099filepath library a lot bigger in 7.4.2 RC 12019-07-07T18:52:11ZIan Lynagh <igloo@earth.li>filepath library a lot bigger in 7.4.2 RC 1`filepath` is a lot bigger in 7.4.2 RC 1 than in 7.4.1, e.g.:
```
Change Size changed:
"ghc-7.4.1/libraries/filepath/dist-install/build/libHSfilepath-1.3.0.0.a"
"ghc-7.4.1.20120508/libraries/filepath/dist-install/build/libHSfile...`filepath` is a lot bigger in 7.4.2 RC 1 than in 7.4.1, e.g.:
```
Change Size changed:
"ghc-7.4.1/libraries/filepath/dist-install/build/libHSfilepath-1.3.0.0.a"
"ghc-7.4.1.20120508/libraries/filepath/dist-install/build/libHSfilepath-1.3.0.0.a"
388984 -> 760936
```
This probably isn't a show-stopper, but let's at least try to take a look at what's going on before release.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"filepath library a lot bigger in 7.4.2 RC 1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.4.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`filepath` is a lot bigger in 7.4.2 RC 1 than in 7.4.1, e.g.:\r\n{{{\r\nChange Size changed:\r\n \"ghc-7.4.1/libraries/filepath/dist-install/build/libHSfilepath-1.3.0.0.a\"\r\n \"ghc-7.4.1.20120508/libraries/filepath/dist-install/build/libHSfilepath-1.3.0.0.a\"\r\n 388984 -> 760936\r\n}}}\r\n\r\nThis probably isn't a show-stopper, but let's at least try to take a look at what's going on before release.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/6072Irrefutable pattern error while compiling GHC2019-07-07T18:52:19ZSjoerd VisscherIrrefutable pattern error while compiling GHCWhile doing "make" on GHC HEAD I got this error:
```
"inplace/bin/ghc-stage1" -prof -H32m -O -package-name ghc-7.5.20120503 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/...While doing "make" on GHC HEAD I got this error:
```
"inplace/bin/ghc-stage1" -prof -H32m -O -package-name ghc-7.5.20120503 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../rts/dist/build -Icompiler/stage2 -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.14.0 -package array-0.3.0.3 -package base-4.5.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.0.0 -package containers-0.5.0.0 -package directory-1.1.0.1 -package filepath-1.2.0.1 -package hoopl-3.8.7.2 -package hpc-0.5.1.0 -package process-1.1.0.0 -package template-haskell-2.6.0.0 -package time-1.4 -package unix-2.5.1.0 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -no-user-package-conf -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf p_hi -osuf p_o -hcsuf p_hc -c compiler/main/HscMain.hs -o compiler/stage2/build/HscMain.p_o
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.5.20120503 for x86_64-apple-darwin):
compiler/simplCore/SimplUtils.lhs:1668:5-25: Irrefutable pattern failed for pattern ((_, _, rhs1) : _)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [compiler/stage2/build/HscMain.p_o] Error 1
make: *** [all] Error 2
```7.6.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/6071Compiled program segfaults2019-07-07T18:52:19ZstevecheckowayCompiled program segfaultsWhen I run the bug program, it correctly computes 28 values (output lines 1 through 28) and on the 29th, it segfaults.
For some reason this program runs out of stack space; however if you compile it with -rtsopts and increase the size o...When I run the bug program, it correctly computes 28 values (output lines 1 through 28) and on the 29th, it segfaults.
For some reason this program runs out of stack space; however if you compile it with -rtsopts and increase the size of the stack, it will segfault on the 29th.
This program is fairly slow. Compiled with -O4, it took 3 minutes to segfault and used more than 20 GB of RAM.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.4 |
| 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 program segfaults","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I run the bug program, it correctly computes 28 values (output lines 1 through 28) and on the 29th, it segfaults.\r\n\r\nFor some reason this program runs out of stack space; however if you compile it with -rtsopts and increase the size of the stack, it will segfault on the 29th.\r\n\r\nThis program is fairly slow. Compiled with -O4, it took 3 minutes to segfault and used more than 20 GB of RAM.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/6067regression: cgrun051(ghci) failing in HEAD2019-07-07T18:52:20ZSimon Marlowregression: cgrun051(ghci) failing in HEAD```
=====> cgrun051(ghci) 46 of 79 [0, 0, 0]
cd . && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fno-g...```
=====> cgrun051(ghci) 46 of 79 [0, 0, 0]
cd . && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fno-ghci-history cgrun051.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <cgrun051.genscript 1>cgrun051.interp.stdout 2>cgrun051.interp.stderr
Actual stderr output differs from expected:
--- ./cgrun051.stderr 2012-04-30 18:02:44.638862376 +0100
+++ ./cgrun051.run.stderr 2012-05-01 11:19:15.808880452 +0100
@@ -1 +1 @@
-cgrun051: OK
+cgrun051: Impossible case alternative
*** unexpected failure for cgrun051(ghci)
```
The code is very simple. For some reason the simplifier is replacing the `error "OK"` with `runtimeError "Impossible case alternative"`, but only in GHCi.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"regression: cgrun051(ghci) failing in HEAD","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n=====> cgrun051(ghci) 46 of 79 [0, 0, 0]\r\ncd . && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fno-ghci-history cgrun051.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <cgrun051.genscript 1>cgrun051.interp.stdout 2>cgrun051.interp.stderr\r\nActual stderr output differs from expected:\r\n--- ./cgrun051.stderr 2012-04-30 18:02:44.638862376 +0100\r\n+++ ./cgrun051.run.stderr 2012-05-01 11:19:15.808880452 +0100\r\n@@ -1 +1 @@\r\n-cgrun051: OK\r\n+cgrun051: Impossible case alternative\r\n*** unexpected failure for cgrun051(ghci)\r\n}}}\r\n\r\nThe code is very simple. For some reason the simplifier is replacing the `error \"OK\"` with `runtimeError \"Impossible case alternative\"`, but only in GHCi.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/6061threadDelay broken on Windows2019-07-07T18:52:22ZSimon MarlowthreadDelay broken on WindowsThere seems to be new breakage in `threadDelay` on Windows. I noticed `conc070` failing in a validate:
```
=====> conc070(ghci) 191 of 3265 [0, 0, 0]
cd ./concurrent/should_run && 'c:/simonmar/ghc-validate/bindisttest/install dir/bin...There seems to be new breakage in `threadDelay` on Windows. I noticed `conc070` failing in a validate:
```
=====> conc070(ghci) 191 of 3265 [0, 0, 0]
cd ./concurrent/should_run && 'c:/simonmar/ghc-validate/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fno-ghci-history conc070.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <conc070.genscript 1>conc070.interp.stdout 2>conc070.interp.stderr
Actual stdout output differs from expected:
--- ./concurrent/should_run/conc070.stdout 2011-08-02 14:43:53 +0100
+++ ./concurrent/should_run/conc070.run.stdout 2012-04-27 10:54:04 +0100
@@ -1 +1 @@
-[ThreadBlocked BlockedOnMVar,ThreadBlocked BlockedOnMVar,ThreadRunning,ThreadFinished]
+[ThreadFinished,ThreadBlocked BlockedOnMVar,ThreadRunning,ThreadFinished]
*** unexpected failure for conc070(ghci)
```
and strangely if you try `threadDelay 1000000` in GHCi it returns immediately.
This test is also failing:
```
=====> ThreadDelay001(threaded1) 7 of 7 [0, 0, 0]
cd . && 'c:/simonmar/ghc-validate/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fno-ghci-history -o ThreadDelay001 ThreadDelay001.hs -threaded -debug >ThreadDelay001.comp.stderr 2>&1
cd . && ./ThreadDelay001 </dev/null >ThreadDelay001.run.stdout 2>ThreadDelay001.run.stderr
Actual stdout output differs from expected:
--- /dev/null 2012-04-30 11:17:41 +0100
+++ ./ThreadDelay001.run.stdout 2012-04-30 11:17:41 +0100
@@ -0,0 +1,2 @@
+(Mon Apr 30 11:17:29 GMT Daylight Time 2012,Mon Apr 30 11:17:29 GMT Daylight Time 2012,1000000,0,-1000000,-1.0e-6)
+(Mon Apr 30 11:17:29 GMT Daylight Time 2012,Mon Apr 30 11:17:29 GMT Daylight Time 2012,5000000,0,-5000000,-5.0e-6)
*** unexpected failure for ThreadDelay001(threaded1)
```
Possibly related to the fix for #5865
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"threadDelay broken on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There seems to be new breakage in `threadDelay` on Windows. I noticed `conc070` failing in a validate:\r\n\r\n{{{\r\n=====> conc070(ghci) 191 of 3265 [0, 0, 0]\r\n\r\ncd ./concurrent/should_run && 'c:/simonmar/ghc-validate/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fno-ghci-history conc070.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <conc070.genscript 1>conc070.interp.stdout 2>conc070.interp.stderr\r\n\r\nActual stdout output differs from expected:\r\n\r\n--- ./concurrent/should_run/conc070.stdout\t2011-08-02 14:43:53 +0100\r\n+++ ./concurrent/should_run/conc070.run.stdout\t2012-04-27 10:54:04 +0100\r\n@@ -1 +1 @@\r\n-[ThreadBlocked BlockedOnMVar,ThreadBlocked BlockedOnMVar,ThreadRunning,ThreadFinished]\r\n+[ThreadFinished,ThreadBlocked BlockedOnMVar,ThreadRunning,ThreadFinished]\r\n\r\n*** unexpected failure for conc070(ghci)\r\n}}}\r\n\r\nand strangely if you try `threadDelay 1000000` in GHCi it returns immediately.\r\n\r\nThis test is also failing:\r\n\r\n{{{\r\n=====> ThreadDelay001(threaded1) 7 of 7 [0, 0, 0]\r\ncd . && 'c:/simonmar/ghc-validate/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fno-ghci-history -o ThreadDelay001 ThreadDelay001.hs -threaded -debug >ThreadDelay001.comp.stderr 2>&1\r\ncd . && ./ThreadDelay001 </dev/null >ThreadDelay001.run.stdout 2>ThreadDelay001.run.stderr\r\nActual stdout output differs from expected:\r\n--- /dev/null 2012-04-30 11:17:41 +0100\r\n+++ ./ThreadDelay001.run.stdout 2012-04-30 11:17:41 +0100\r\n@@ -0,0 +1,2 @@\r\n+(Mon Apr 30 11:17:29 GMT Daylight Time 2012,Mon Apr 30 11:17:29 GMT Daylight Time 2012,1000000,0,-1000000,-1.0e-6)\r\n+(Mon Apr 30 11:17:29 GMT Daylight Time 2012,Mon Apr 30 11:17:29 GMT Daylight Time 2012,5000000,0,-5000000,-5.0e-6)\r\n*** unexpected failure for ThreadDelay001(threaded1)\r\n}}}\r\n\r\nPossibly related to the fix for #5865","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/6042GHC is bloated2019-07-07T18:52:26ZSimon MarlowGHC is bloatedI noticed today that our binary dists are getting bigger:
```
-rw-rw-r-- 1 simonmar GHC 118924739 2010-11-17 04:02 ghc-7.0.1-i386-unknown-linux.tar.bz2
-rw-rw-r-- 1 simonmar GHC 112074889 2011-03-02 04:19 ghc-7.0.2-i386-unknown-linux.ta...I noticed today that our binary dists are getting bigger:
```
-rw-rw-r-- 1 simonmar GHC 118924739 2010-11-17 04:02 ghc-7.0.1-i386-unknown-linux.tar.bz2
-rw-rw-r-- 1 simonmar GHC 112074889 2011-03-02 04:19 ghc-7.0.2-i386-unknown-linux.tar.bz2
-rw-rw-r-- 1 simonmar GHC 109012585 2011-03-27 05:21 ghc-7.0.3-i386-unknown-linux.tar.bz2
-rw-rw-r-- 1 simonmar GHC 109012197 2011-06-15 04:25 ghc-7.0.4-i386-unknown-linux.tar.bz2
-rw-rw-r-- 1 simonmar GHC 115102248 2011-08-10 03:17 ghc-7.2.1-i386-unknown-linux.tar.bz2
-rw-rw-r-- 1 simonmar GHC 114428608 2011-11-10 04:28 ghc-7.2.2-i386-unknown-linux.tar.bz2
-rw-rw-r-- 1 simonmar GHC 123417972 2012-04-20 04:23 ghc-7.4.1.20120416-i386-unknown-linux.tar.bz2
-rw-rw-r-- 1 simonmar GHC 144861355 2012-04-18 06:25 ghc-7.5.20120413-i386-unknown-linux.tar.bz2
```
I looked into the difference between 7.0.4 and 7.4.1, and found that it seems to be mostly caused by GHC itself getting bigger:
```
-rwxrwxr-x simonmar/GHC 31280127 2011-06-14 19:59 ghc-7.0.4/ghc/stage2/build/tmp/ghc-stage2
-rwxrwxr-x simonmar/GHC 41050757 2012-04-19 20:12 ghc-7.4.1/ghc/stage2/build/tmp/ghc-stage2
```
the GHC binary is 25% larger, and the binary dist contains several copies of GHC (.a, _p.a, .so, the GHC binary, haddock).
We didn't add 25% more code to GHC between 7.0.4 and 7.4.1, so why is it 25% larger? This increase isn't reflected in other libraries - in fact, the base package is smaller in 7.4.1 than 7.0.4.
I have a horrid feeling that this is due to heavy use of INLINE/INLINABLE in `containers`, but I hope I'm wrong.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | milan, tibbe |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC is bloated","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["milan","tibbe"],"type":"Bug","description":"I noticed today that our binary dists are getting bigger:\r\n\r\n{{{\r\n-rw-rw-r-- 1 simonmar GHC 118924739 2010-11-17 04:02 ghc-7.0.1-i386-unknown-linux.tar.bz2\r\n-rw-rw-r-- 1 simonmar GHC 112074889 2011-03-02 04:19 ghc-7.0.2-i386-unknown-linux.tar.bz2\r\n-rw-rw-r-- 1 simonmar GHC 109012585 2011-03-27 05:21 ghc-7.0.3-i386-unknown-linux.tar.bz2\r\n-rw-rw-r-- 1 simonmar GHC 109012197 2011-06-15 04:25 ghc-7.0.4-i386-unknown-linux.tar.bz2\r\n-rw-rw-r-- 1 simonmar GHC 115102248 2011-08-10 03:17 ghc-7.2.1-i386-unknown-linux.tar.bz2\r\n-rw-rw-r-- 1 simonmar GHC 114428608 2011-11-10 04:28 ghc-7.2.2-i386-unknown-linux.tar.bz2\r\n-rw-rw-r-- 1 simonmar GHC 123417972 2012-04-20 04:23 ghc-7.4.1.20120416-i386-unknown-linux.tar.bz2\r\n-rw-rw-r-- 1 simonmar GHC 144861355 2012-04-18 06:25 ghc-7.5.20120413-i386-unknown-linux.tar.bz2\r\n}}}\r\n\r\nI looked into the difference between 7.0.4 and 7.4.1, and found that it seems to be mostly caused by GHC itself getting bigger:\r\n\r\n{{{\r\n-rwxrwxr-x simonmar/GHC 31280127 2011-06-14 19:59 ghc-7.0.4/ghc/stage2/build/tmp/ghc-stage2\r\n-rwxrwxr-x simonmar/GHC 41050757 2012-04-19 20:12 ghc-7.4.1/ghc/stage2/build/tmp/ghc-stage2\r\n}}}\r\n\r\nthe GHC binary is 25% larger, and the binary dist contains several copies of GHC (.a, _p.a, .so, the GHC binary, haddock).\r\n\r\nWe didn't add 25% more code to GHC between 7.0.4 and 7.4.1, so why is it 25% larger? This increase isn't reflected in other libraries - in fact, the base package is smaller in 7.4.1 than 7.0.4.\r\n\r\nI have a horrid feeling that this is due to heavy use of INLINE/INLINABLE in `containers`, but I hope I'm wrong.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/5980Name of compiler mismatch in safeHaskell/ghci/p5 p7 p82019-07-07T18:52:44ZRichard Eisenbergrae@richarde.devName of compiler mismatch in safeHaskell/ghci/p5 p7 p8During validation, three tests in safeHaskell/ghci fail: p5 p7 and p8. The apparent reason for failure is that the validation script uses a binary named "ghc", where the expected stdout for these tests assumes "ghc-stage2". I'm not sure ...During validation, three tests in safeHaskell/ghci fail: p5 p7 and p8. The apparent reason for failure is that the validation script uses a binary named "ghc", where the expected stdout for these tests assumes "ghc-stage2". I'm not sure how to fix this in the test suite.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Name of compiler mismatch in safeHaskell/ghci/p5 p7 p8","status":"New","operating_system":"MacOS X","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"During validation, three tests in safeHaskell/ghci fail: p5 p7 and p8. The apparent reason for failure is that the validation script uses a binary named \"ghc\", where the expected stdout for these tests assumes \"ghc-stage2\". I'm not sure how to fix this in the test suite.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1