September 2016 - ghc-tickets

Re: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h"
by GHC 16 Sep '16

16 Sep '16

#8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8040#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h"
by GHC 16 Sep '16

16 Sep '16

#8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2530 Comment: See Phab:D2530 for a possible fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8040#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12433: GHCi produces incorrect results when evaluating with compiled code
by GHC 16 Sep '16

16 Sep '16

#12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: ghci, dynamic | Operating System: Linux linking, compiled code | Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When GHCi evaluates in non-interpreted mode, it sometimes produces incorrect results. The following example---extracted from a much larger program---illustrates the problem: {{{#!hs import Lex num = 100000 txt1 = "aaa,aaa" main :: IO () main = print $ sum $ map (length . haskellLex) $ replicate num txt1 }}} This program lexes the same string 100000 times, and prints the total number of tokens. Since we are lexing the same string, we'd expect to always get the same result, but due to this bug, this is not the case! We repeat the process 100000 times so that we can encounter the bug somewhat reliably---the problem does not occur every time. To reproduce the problem, we need to load `Lex` in compiled form, not interpreted and with some optimizations: {{{ ghc -c -O1 -dynamic Lex.hs }}} The source code for the "lexer" is as follows: {{{#!haskell module Lex (haskellLex) where cclass :: Char -> Int cclass c = case c of 'a' -> 10 ',' -> 11 'A' -> 0 'B' -> 0 'C' -> 0 'D' -> 0 'E' -> 0 'F' -> 0 haskellLex :: String -> [()] haskellLex [] = [] haskellLex (i:is) = case cclass i of 10 -> haskellLex62 is 11 -> () : haskellLex is haskellLex62 :: String -> [()] haskellLex62 [] = [()] haskellLex62 (i:is) = case cclass i of 0 -> [()] 1 -> [()] 2 -> [()] 3 -> [()] 4 -> [()] 10 -> haskellLex62 is 11 -> () : haskellLex (i:is) x -> error ("[GHC BUG] cclass returned: " ++ show (i,x) }}} This is a minimized version from a full lexer. As odd as it looks, removing pretty much anything seems to cause the bug to go away. This is what happens when we run the program: {{{ runhaskell test.hs test.hs: [GHC BUG] cclass returned: (',',-556) CallStack (from HasCallStack): error, called at Lex.hs:36:12 in main:Lex }}} The problem is that after many evaluations, the function `cclass` returned `-556` for character `,`, when it should have returned `11`. I've been able to reproduce this on two Linux machines, both running 64-bit Ubuntu (16.04). The issue does not seem to happen on Mac OS. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12433> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12370: Implement LetUp in DmdAnal (or document why we do not do it)
by GHC 15 Sep '16

15 Sep '16

#12370: Implement LetUp in DmdAnal (or document why we do not do it) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- The paper “Modular, Higher-Order Cardinality Analysis in Theory and Practice” has two rules for analizing let-bindings: LetDown, used for functions, that determines the function’s strictness signature, and passes it down, and LetUp, used for thunks, which uses the demand coming from the scope. The implementation uses only LetDown for all let-bindings. I wonder why this is so. I implemented something that looks like LetUp and will validate and performance-test it soon, in order to either make the implementation match the analysis, or alternatively document why this is the case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #393: functions without implementations
by GHC 15 Sep '16

15 Sep '16

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): [https://www.reddit.com/r/haskell/comments/52una4/question_from_a_beginner_i… example]: > You could do: > > {{{#!hs > data LeafNode a = LeafNode { leafMeta :: LeafMetaData, things :: [a] } > }}} > > And then put the constraint in your functions instead: > > {{{#!hs > myFun :: MyTypeClass a => LeafNode a -> b > myFun = undefined > }}} {{{#!hs myFun :: MyTypeClass a => LeafNode a -> b }}} would be valid syntax. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12015: Add conditional CallStack constraints to common partial utility functions
by GHC 15 Sep '16

15 Sep '16

#12015: Add conditional CallStack constraints to common partial utility functions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- There are a variety of common utility functions used throughout GHC which are partial (e.g. many of the helpers in `Type`, for instance, `kindPrimRep`). It would be great if [ImplicitCallStacks] would identify their callers. However, we likely don't want to pay the cost of passing around `CallStacks` during normal compilation so I propose we make them conditional on `DEBUG`. That is, define {{{#!hs #if DEBUG type DebugCallStack = CallStack #else type DebugCallStack = (() :: Constraint) #endif }}} Now we can sprinkle `DebugCallStack` constraints about GHC and get the best of both worlds! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7019: Wrong error message when using forall in constraints
by GHC 14 Sep '16

14 Sep '16

#7019: Wrong error message when using forall in constraints -------------------------------------+------------------------------------- Reporter: sjoerd_visscher | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T7019, T7019a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This compiles using [https://hackage.haskell.org/package/constraints-0.8/docs/Data-Constraint- Forall.html Data.Constraint.Forall] for the record: {{{#!hs import Data.Constraint import Data.Constraint.Forall newtype Free c a = Free { runFree :: forall r. c r => (a -> r) -> r } deriving Functor class c (Free c a) => C c a instance c (Free c a) => C c a instance Applicative (Free c) where pure :: a -> Free c a pure a = Free ($ a) (<*>) :: Free c (a -> b) -> (Free c a -> Free c b) Free f <*> Free g = Free (\bfr -> f (\ab -> g (bfr . ab))) instance Forall (C c) => Monad (Free c) where return :: a -> Free c a return a = Free ($ a) (>>=) :: forall a b. Free c a -> (a -> Free c b) -> Free c b Free f >>= g = f g \\ inst @(C c) @b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7019#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12573: Allow the user to pick the address that the RTS reserves for the heap
by GHC 13 Sep '16

13 Sep '16

#12573: Allow the user to pick the address that the RTS reserves for the heap -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 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: -------------------------------------+------------------------------------- We stumbled upon a case where an external library (OpenCL) does not work if a specific address (0x200000000) is taken. It so happens that `osReserveHeapMemory` starts trying to `mmap` at `0x200000000`: {{{ void *hint = (void*)((W_)8 * (1 << 30) + attempt * BLOCK_SIZE); at = osTryReserveHeapMemory(*len, hint); }}} This makes it impossible to use Haskell programs compiled with GHC 8 with C functions that use OpenCL. See this example https://github.com/chpatrick/oclwtf for a repro. My proposal is to allow the user to work around this kind of behavior outside our control by letting the user override the starting address through an RTS command line flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12583: Deriving standalone Ix instance for GADT leads to GHC panic
by GHC 13 Sep '16

13 Sep '16

#12583: Deriving standalone Ix instance for GADT leads to GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On GHC 8.0.1 and HEAD, the following code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} module Bug where import Data.Ix data Foo a where MkFoo :: (Eq a, Ord a, Ix a) => Foo a deriving instance Ix (Foo a) }}} results in a GHC panic: {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160908 for x86_64-unknown-linux): Prelude.foldl1: empty list Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The culprit is [http://git.haskell.org/ghc.git/blob/1b5f9207a649a64a1bba20b0283253425f9208d… here], in the code which generates an `inRange` implementation for a derived `Ix` instance for a datatype with exactly one constructor. Normally, this code wouldn't be reached for a datatype like `data Bar = MkBar`, since GHC would treat that as an enumeration and generate different code for `inRange`. That is, normally, the only time this `foldl1` would be reached is if we were dealing with exactly one constructor with one or more arguments (making the use of `foldl1` justified). However, there's a catch: the function which checks if a datatype is an enumeration (`isEnumerationTyCon`) will reject any GADT-like datatypes. `gen_Ix_binds` uses `isEnumerationTyCon` [http://git.haskell.org/ghc.git/blob/1b5f9207a649a64a1bba20b0283253425f9208d… here] to determine whether to use the case that goes through `foldl1` or not, and since `Foo` as above is a GADT, it defaults to the case that uses `foldl1`. What's interesting is that this bug is //not// present in GHC 7.10.3 and earlier. Instead, it will simply error out with an appropriate error message: {{{ $ /opt/ghc/7.10.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:1: Can't make a derived instance of ‘Ix (Foo a)’: ‘Foo’ must be an enumeration type (an enumeration consists of one or more nullary, non-GADT constructors) or ‘Foo’ must have precisely one constructor In the stand-alone deriving instance for ‘Ix (Foo a)’ }}} That's because before `gen_Ix_binds` is reached, the `sideConditions` function [http://git.haskell.org/ghc.git/blob/1b5f9207a649a64a1bba20b0283253425f9208d… checks] if the datatype meets the requirements imposed by `isEnumerationTyCon` or `isProductTyCon`. In GHC 7.10.3 and earlier, the implementation of `isProductTyCon` is: {{{#!hs isProductTyCon :: TyCon -> Bool -- True of datatypes or newtypes that have -- one, vanilla, data constructor isProductTyCon tc@(AlgTyCon {}) = case algTcRhs tc of DataTyCon{ data_cons = [data_con] } -> isVanillaDataCon data_con NewTyCon {} -> True _ -> False isProductTyCon (TupleTyCon {}) = True isProductTyCon _ = False }}} But as a result of [ this commit] of Simon's, the implementation of `isProductTyCon` in GHC 8.0.1 and later is: {{{#!hs isProductTyCon :: TyCon -> Bool -- True of datatypes or newtypes that have -- one, non-existential, data constructor -- See Note [Product types] isProductTyCon tc@(AlgTyCon {}) = case algTcRhs tc of DataTyCon{ data_cons = [data_con] } -> null (dataConExTyVars data_con) NewTyCon {} -> True _ -> False isProductTyCon (TupleTyCon {}) = True isProductTyCon _ = False }}} Before, `isProductTyCon` rejected all GADTs, but now, it only checks if there are no existentially quantified type variables, which allows `Foo` to slip through the cracks. ----- The question is: how should we fix this? Should we generate the code the same code as we do for enumerations in this case? i.e., {{{#!hs instance Ix (Foo a) where ... inRange (a_a27l, b_a27m) c_a27n = case ($con2tag_PPfAWSX7zu8vtuLB8bgeJ a_a27l) of { a#_a27o -> case ($con2tag_PPfAWSX7zu8vtuLB8bgeJ b_a27m) of { b#_a27p -> case ($con2tag_PPfAWSX7zu8vtuLB8bgeJ c_a27n) of { c#_a27q -> (&&) (tagToEnum# (c#_a27q >=# a#_a27o)) (tagToEnum# (c#_a27q <=# b#_a27p)) } } } }}} Or should we generate the even-simpler definition: {{{#!hs instance Ix (Foo a) where ... inRange (MkFoo, MkFoo) MkFoo = True }}} FWIW, I think the Haskell Report [https://www.haskell.org/onlinereport/haskell2010/haskellch19.html#x27-22700… doesn't specify exactly] how this kind of case should be handled, so we should have some leeway in picking a solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12583> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12572: `readdir_r` is deprecated
by GHC 12 Sep '16

12 Sep '16

#12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building GHC git HEAD on Debian Testing I get: {{{ libraries/unix/cbits/HsUnix.c: In function ‘__hscore_readdir’: libraries/unix/cbits/HsUnix.c:64:3: error: error: ‘readdir_r’ is deprecated [-Werror=deprecated-declarations] res = readdir_r(dirPtr, p, pDirEnt); ^~~ In file included from libraries/unix/include/HsUnix.h:71:0: error: 0, from libraries/unix/cbits/HsUnix.c:9: /usr/include/dirent.h:183:12: error: note: declared here extern int readdir_r (DIR *__restrict __dirp, ^~~~~~~~~ }}} According to the man page: > This function is deprecated; use readdir(3) instead. > > The readdir_r() function was invented as a reentrant version of readdir(3). It reads the next directory entry from the directory stream dirp, and returns it in the caller-allocated buffer pointed to by entry. > > It is expected that a future version of POSIX.1 will make readdir_r() obsolete, and require that readdir() be thread-safe when concurrently employed on different directory streams. In order to support all of the various *nix systems, we probably need to detect if `readdir_r` is deprecated and only use `readdir` where `readdir_r` is in fact deprecated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12572> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11