May 2017 - ghc-tickets

[GHC] #11773: linux/powepc : ghc-stage1 segfaults when building unregisterised
by GHC 19 Mar '18

19 Mar '18

#11773: linux/powepc : ghc-stage1 segfaults when building unregisterised --------------------------------+---------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Building unregisterised to test code paths that don't get tested in the registerised compile mode. The segfault: {{{ "inplace/bin/ghc-stage1" -static -O -H64m -Wall -Iincludes -Iincludes/dist \ -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header \ -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP \ -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen \ -Irts/dist/build -Irts/dist/build/autogen -O2 -Wnoncanonical-monad- instances \ -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o }}} seems to occur on powerpc, but not on x86_64 or armhf. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11765: Allow documentary type signatures
by GHC 19 Mar '18

19 Mar '18

#11765: Allow documentary type signatures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (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: -------------------------------------+------------------------------------- In some cases (e.g., `lens`) it's useful to document a binding with a more specific type signature than the true one, to show a useful special case. Unfortunately, this documentation can potentially be wrong or go out of date. I'd like to propose a pragma for this: {{{#!hs {-# Documentary #-} f :: T -> U }}} would ask the type checker to verify that `f :: T -> U`. Specifically, it would have the effect of creating and type checking, but then discarding, a hidden binding {{{#!hs f_doc :: T -> U f_doc t = f t }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13690: Running profiling tests in the GHCi way is extremely slow
by GHC 19 Mar '18

19 Mar '18

#13690: Running profiling tests in the GHCi way is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- Running, e.g., `profinline001` in the GHCi way takes somewhere around eleven seconds. This seems pretty extreme. I noticed this when writing T12962 in the as-yet-unmerged Phab:D3550, which takes about the same amount of time. These are very small and very simple bits of code that don't do much at all, so it seems the problem must lie elsewhere. I have no idea where, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #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] #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