November 2017 - ghc-tickets

[GHC] #12712: break011 is broken on Windows
by GHC 19 Mar '18

19 Mar '18

#12712: break011 is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: break011 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `break011` testcase fails on Windows with some unexpected differences in stdout. {{{ +++ ./ghci.debugger/scripts/break011.run/break011.run.stdout.normalised 2016-10-16 01:57:26.489544400 +0000 @@ -51,6 +51,9 @@ "foo" "CallStack (from HasCallStack): error, called at Test7.hs:<line>:<column> in <package-id>:Main") -*** Exception: foo -CallStack (from HasCallStack): - error, called at Test7.hs:<line>:<column> in <package-id>:Main +Stopped in <exception thrown>, <unknown> +_exception :: e = SomeException + (ErrorCallWithLocation + "foo" + "CallStack (from HasCallStack): + error, called at Test7.hs:<line>:<column> in <package-id>:Main") }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12712> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13443: Typeclass resolution errors quite puzzling
by GHC 19 Mar '18

19 Mar '18

#13443: Typeclass resolution errors quite puzzling -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is based on a post I made to haskell-cafe: https://mail.haskell.org/pipermail/haskell-cafe/2016-August/124622.html Here's a program with an odd error message (GHC 8.0.1): {{{ data A a = A a deriving Eq data B = B main :: IO () main = print (A B == A B) test/main.hs:5:15: error: • No instance for (Eq B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B) }}} I get an error about `Eq B` even though it's `Eq A` that is manifestly required at the call site. This error is odder when `A` and `B` are defined far away from the use of `==`. This is even odder: {{{ data A a = A a data B = B instance Ord a => Eq (A a) where main :: IO () main = print (A B == A B) test/main.hs:7:15: error: • No instance for (Ord B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B) }}} Now not only is the type puzzling (`B` instead of `A`) but the *class* is puzzling (`Ord` instead of `Eq`). This occurred to me in practice because `Data.Graph.Inductive.PatriciaTree.Gr` has `(Eq a, Ord b) => Eq (Gr a b)`. It would have been a lot more helpful to see {{{ * No instance for (Ord B) * arising from (Eq A) * arising from the use of '==' }}} Does anyone agree with me that GHC should produce the full trace when it fails to resolve instances rather than just the proximal failure? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13639: Skylighting package compilation is glacial
by GHC 19 Mar '18

19 Mar '18

#13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the `skylighting` package in profiled and non-profiled confihratiine takes nearly ten minutes. I haven't looked at the code, but I can't imagine a syntax highlighting package would need to take this long. Investigate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13654: Optimize casMutVar# for single-threaded runtime
by GHC 19 Mar '18

19 Mar '18

#13654: Optimize casMutVar# for single-threaded runtime -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Runtime | Version: 8.2.1-rc1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using the non-threaded RTS, `stg_casMutVarzh`, `stg_atomicModifyMutVarzh`, etc., shouldn't need to actually use atomic instructions, but they seem to do so. I believe this makes them substantially slower than necessary in that context. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks
by GHC 19 Mar '18

19 Mar '18

#13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Andras has a bunch of different benchmarks for different effect handler code which stresses the optimiser in interesting ways. It would be good to add some of these benchmarks to nofib as they are likely quite different from a lot of the examples already in there. https://github.com/AndrasKovacs/misc-stuff/tree/master/haskell/Eff -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13892> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12193: Include target versions of unlit and hsc2hs when cross-compiling
by GHC 19 Mar '18

19 Mar '18

#12193: Include target versions of unlit and hsc2hs when cross-compiling -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello! I have been working on getting ghc packaged on Debian for m68k and sh4. While ghc itself works without any major issues on these targets, the performance is a bit too low to just build ghc from sources on the machines itself. It works, but it may take up to three weeks or more. To workaround this problem, I am using a cross-compiled version of ghc on these platforms which works quite well. However, while using the cross- compiled Debian ghc packaged, I noticed that some packages fail to build from source because my cross-compiled version of ghc is missing the "unlit" utility. Looking at the result of the cross-compiled ghc for m68k, it's obvious why unlit is missing: {{{ glaubitz@ikarus:~/debian/ghc/ghc-8.0.1$ file ./inplace/lib/bin/* ./inplace/lib/bin/ghc-iserv: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=39f595d60d0c596714aa0fedcc0bfa3a35921c41, not stripped ./inplace/lib/bin/ghc-iserv-prof: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=f83f10fc7d925f54fb18816384ae91ae6c1b9ac8, not stripped ./inplace/lib/bin/ghc-pkg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=41d534ca0e83df11274eade67477db1e9667fec5, not stripped ./inplace/lib/bin/ghc-stage1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=089a2121e49e16ea7ba721c350b04a965b19dded, not stripped ./inplace/lib/bin/ghc-stage2: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=589cdca9242bd132e1c80736a79ebf4209eb1c78, not stripped ./inplace/lib/bin/hpc: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=f401ba499a4cf865def36a7dc6d7c3a32385c85f, not stripped ./inplace/lib/bin/hsc2hs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a532a7cc6f0c1e95e7c66aab2b4c53e1d0b58d88, not stripped ./inplace/lib/bin/unlit: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=30ab37170ddcb09bcb7885ae3c18a353f6d128b7, not stripped glaubitz@ikarus:~/debian/ghc/ghc-8.0.1$ }}} Thus, both "unlit" and "hsc2hs" are not built for the target architecture when cross-compiling. After a quick look at utils/unlit/ghc.mk, it becomes obvious why that's the case: {{{ $(eval $(call build-prog,utils/unlit,dist,0)) }}} Would it be possible to change the build configuration such that "unlit" and "hsc2hs" are built for the target as well when cross-compiling? That would be great :). Adrian [1] [https://buildd.debian.org/status/fetch.php?pkg=haskell- fmlist&arch=m68k&ver=0.9-4&stamp=1465990971] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14282: tagToEnum# . dataToTag# not optimized away
by GHC 19 Mar '18

19 Mar '18

#14282: tagToEnum# . dataToTag# not optimized away -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: datacon-tags | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{#!hs foo :: Int# -> Int# foo x = dataToTag# (tagToEnum# x :: Bool) bar :: Bool -> Bool bar x = tagToEnum# (dataToTag# x) }}} These are both effectively identity functions. But while `foo` simplifies to one, `bar` does not! We might want to fix that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14282> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14501: hp2ps and unlit are compiled by the stage0 compiler
by GHC 19 Mar '18

19 Mar '18

#14501: hp2ps and unlit are compiled by the stage0 compiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In looking at #14057 I noticed that the hp2ps and unlit binaries that we install are both produced by the stage0 compiler. This will almost certainly break during cross-compilation and it generally breaks release hygiene. We should fix this in Hadrian (assuming angerman hasn't fixed it already). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12038: Shutdown interacts badly with requestSync()
by GHC 19 Mar '18

19 Mar '18

#12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12715: T3994 is intermittently broken on Windows
by GHC 19 Mar '18

19 Mar '18

#12715: T3994 is intermittently broken on Windows --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The `T3994` testcase sometimes appears to crash on Windows, {{{ +++ ../../libraries/process/tests/T3994.run/T3994.run.stderr.normalised 2016-10-16 03:11:54.601205700 +0000 @@ -0,0 +1,2 @@ + 1521 [main] sh 5272 child_copy: cygheap read copy failed, 0x1802FE408..0x180307A08, done 0, windows pid 5272, Win32 error 299 + 7952 [main] sh 5272 C:/msys64/usr/bin/sh: *** fatal error in forked process - ccalloc would have returned NULL }}} This very well may be an msys issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2