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

[GHC] #12737: T12227 is failing on ghc-8.0
by GHC 19 Mar '18

19 Mar '18

#12737: T12227 is failing on ghc-8.0 -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Visual | Version: 8.0.1 Haskell | 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: -------------------------------------+------------------------------------- Fresh validate from 5eab189b329344630f76b8751c1289ce480ca46b on x86_64 Linux: {{{ =====> T12227(normal) 1 of 1 [0, 0, 0] cd ./perf/compiler && "/home/hs01/ezyang/ghc-validate/inplace/test spaces/ghc-stage2" -c T12227.hs -fforce-recomp -dno-debug-output -fshow- warning-groups -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn- missed-specialisations -fno-ghci-history -O2 -ddump-hi -ddump-to-file +RTS -M1G +RTS -V0 -tT12227.comp.stats --machine-readable -RTS > T12227.comp.stderr 2>&1 bytes allocated value is too high: Expected T12227(normal) bytes allocated: 1822822016 +/-5% Lower bound T12227(normal) bytes allocated: 1731680915 Upper bound T12227(normal) bytes allocated: 1913963117 Actual T12227(normal) bytes allocated: 9256914200 Deviation T12227(normal) bytes allocated: 407.8 % *** unexpected stat test failure for T12227(normal) }}} That's a pretty awful regression, if it is real. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12619: Allow users guide to be built independently from GHC
by GHC 19 Mar '18

19 Mar '18

#12619: Allow users guide to be built independently from GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: -------------------------------------+------------------------------------- At HIW 2016 it was suggested that this would greatly reduce the friction to contributing users guide fixes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12389: Limit duplicate export warnings for datatypes
by GHC 19 Mar '18

19 Mar '18

#12389: Limit duplicate export warnings for datatypes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11959 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `containers` sometimes exports data constructors/patterns conditionally (depending on GHC version and whether `TESTING` is defined). Presently, to avoid a duplicate export warning, it's necessary to write a separate export line for each combination of exported constructors, which is horrible: {{{#!hs module Foo ( #ifdef TESTING #ifdef USE_PATTERN_SYNONYMS Foo (Foo, Pat1, Pat2) #else Foo (Foo) #endif #elif USE_PATTERN_SYNONYMS Foo (Pat1, Pat2) #else Foo #endif }}} or to break up the lines with CPP, which is so horrible I can't even bring myself to write it. I'd much rather be able to write {{{#!hs module Foo ( Foo #ifdef TESTING ,Foo(Foo) #endif #ifdef USE_PATTERN_SYNONYMS ,Foo(Pat1, Pat2) #endif ) }}} The trouble here is that GHC warns about duplicate export of the type `Foo`. I think there's a pretty simple partial solution: only warn about a type export that is *completely* redundant, adding neither type constructor nor pattern. And offer a way to turn off the redundant export warning entirely for types and classes without turning it off for bindings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10774: Use `Natural` rather than `Integer` in `GHC.TypeLits`
by GHC 19 Mar '18

19 Mar '18

#10774: Use `Natural` rather than `Integer` in `GHC.TypeLits` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: | Version: 7.10.2 libraries/base | Keywords: TypeLits | Operating System: Unknown/Multiple Natural | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When the numeric type-literals were implement via `GHC.TypeLits` there was no `Natural` type in `base` yet. But since GHC 7.10 we finally have `Natural` available in base! Specifically, the following 3 type-signatures in `GHC.TypeLits` cpmtaom `Integer` that ought rather be `Natural`s: {{{#!hs someNatVal :: Integer -> Maybe SomeNat natVal :: forall n proxy. KnownNat n => proxy n -> Integer natVal' :: forall n. KnownNat n => Proxy# n -> Integer }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9671: Allow expressions in patterns
by GHC 16 Mar '18

16 Mar '18

#9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: patterns, pattern | Operating System: synonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've outlined a proposal for extending pattern synonyms to depend on terms (PatternFamilies), the name is less than ideal but I'll keep the page under that name for now. The proposal's introduction has been rewritten. The simplest use case are patterns that matches only when a set contains an element (`IsMember`) or when a set does not contain an element (`NotMember`): [[Image(wiki:PatternFamilies:member.png)]] {{{#!hs hasKeys :: Set Item -> IO () hasKeys (IsMember "keys") = leaveHouse hasKeys (NotMember "keys") = findKeys >> leaveHouse }}} or a pattern that matches a map if the key exists: [[Image(wiki:PatternFamilies:lookup.png)]] used like this: {{{#!hs age :: Map Person Age -> String age (Lookup "Alice" 60) = "Alice is 60 years old!" age (Lookup "Alice" age) = "Alice is " ++ show age ++ "." age (Lookup "Bob" _) = "No info on Alice but we know how old Bob is." age _ = "..." }}} Further details and examples can be found here: PatternFamilies, I discussed it with several people ICFP 2014. This would not require a new extension but would extend PatternSynonyms. This feature can be quite useful, especially when working with deeply nested structures (ASTs, JSON, XML, ...). If people are fine with it I will implement it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11312: GHC inlining primitive string literals can affect program output
by GHC 14 Mar '18

14 Mar '18

#11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #11292 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First noted in #11292, this program, when compiled with `-O1` or higher: {{{#!hs {-# LANGUAGE MagicHash #-} module Main (main) where import GHC.Exts (Addr#, isTrue#) import GHC.Prim (eqAddr#) data A = A { runA :: Addr# } a :: A a = A "a"# main :: IO () main = print (isTrue# (eqAddr# (runA a) (runA a))) }}} will result in the following after inlining: {{{ Main.main2 = case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.eqAddr# "a"# "a"#) of _ [Occ=Dead] { GHC.Types.False -> GHC.Show.shows26; GHC.Types.True -> GHC.Show.shows24 } }}} As a result, there are two of the same string constant with different addresses, which causes `eqAddr#` to return `False`. If compiled without optimizations, `"a"#` is not inlined, and as a result, `eqAddr#` returns `True`. Two questions: 1. Is this okay semantics-wise? Or is this a necessary risk when working with primitive string literals, and should programmers judiciously use `{-# NOINLINE #-}` with them? 2. Is this okay from a code duplication standpoint? As Reid Barton noted in #11292, `"a"#` is duplicated due to inlining. In this example, not much is duplicated, but if it were a longer string constant, that could result in a noticeable increase in the object file size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14