July 2016 - ghc-tickets

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 31 Jul '16

31 Jul '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): I tried implementing a {{{String#}}} type which would carry the length as an {{{Int#}}} at its beginning and two functions to extract the length and address of the string literal. However, it quickly got a little bit out of hand: - {{{unpackCString#}}} etc. had to be adopted, breaking backwards compatibility. To avoid this, I tried to create wrapper functions {{{unpackCStringLit#}}}, which would extract the address and call the original {{{unpackCString#}}} function. - I could not solve the question how to adopt the rewrite rules dealing with strings without duplicating them for the {{{Addr#}}} and {{{String#}}} versions. I could also not figure out when {{{unpackCStringLit#}}} should inline to avoid the overhead of the new address computation. - It took a while to find all (most?) of the places (library, some hardcoded types in {{{Id}}}s, a place in the type checker, generating record selector errors) where types where wired in, especially for exceptions like {{{absentError}}} and {{{recSelError}}}. - Implementing a new {{{String#}}} also asked the question whether {{{"foo"##}}} should be the corresponding literal for it. However, adding it from the parser to the backend seemed quite complex, so I tried a different approach. Instead of creating a new type {{{String#}}}, I rewrote {{{unpackCStringLit#}}} to have the type {{{Addr# -> Int# -> [Char]}}}. It would then just throw its second argument away and inline in some phase. However, it still meant duplicating rewrite rules, which seemed not like an idea solution. My next idea was to push the length information into an ignored argument to a function giving us the address: {{{cStringLitAddr# :: Addr# -> Int# -> Addr#}}}. This could just be passed as an argument to {{{unpackCString#}}}, thus I was quite confident that it would remain backwards compatible and no extra rewrite rules were needed to maintain the current behavior (but extra rules to use the length information, e.g. to construct bytestrings, but this seems like an acceptable cost). However, I did not anticipate the let/app invariant, thus my original design of {{{unpackCString# (cStringLitAddr# "foo"# 3#)}}} caused lint to warn me. After reading up about the invariant, I decided that {{{cStringLitAddr#}}}, applied to two literals, should be okay for speculation, as it did not have side effects nor could fail or anything. However, while now the generated core was accepted, it was useless, as it would not match the rewrite rules written by a user. Their rules would be translated to something like {{{case cStringLitAddr# addr len of { tmp -> unpackCString# tmp } }}}. Thus, I decided to generate matching core and removed my fix to make {{{cStringLitAddr#}}} okay for speculation. In the current version, it is possible to create a bytestring in O(1) with rewrite rules. However, I have broken the general list fusion (or at least the built-in rules {{{match_eq_string}}} and {{{match_append_lit}}}), as the case statement gets in the way between {{{foldr}}} and {{{build}}}, causing them to not be optimized out (but maybe this is generally a missed opportunity, if I have {{{foo (case something of { tmp -> bar tmp }) }}}, maybe it should be possible to rewrite {{{foo (bar x) = baz x}}} anyway, leading to {{{case something of { tmp -> baz tmp } }}}, iff {{{something}}} is safe to evaluate with regards to time, space and exceptions (this is okay-for- speculation, right?)). So right now I am stuck. Maybe it is okay to break backwards compatibility and just change the types of {{{unpackCString#}}} etc. to include an additional (ignored) {{{Int#}}} argument, pushing some #ifs to everyone using {{{unpackCString#}}} (I think this is basically text, bytestring and ghc itself) for the next few years. However, {{{unpackCString#}}} is called at some additional places, namely when constructing modules for {{{Typeable}}}. Right now the types only carry the {{{Addr#}}} to call it, but would then also need the length information (or there would be the risk that something rewrites it and gets a bogus length, if one just passes {{{0#}}} as length information). On the other hand, maybe it would be a good thing to actually pass the length along to {{{unpackCString#}}}, making it mandatory, as this would avoid the need to null-terminate the strings, allowing {{{'\NUL'}}} characters to be encoded with one byte instead of two (which may be of interest for bytestring). On the other hand, I could imagine this breaking stuff if strings are no longer null- terminated in subtle ways... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #860: CPP fails when a macro is used on a line containing a single quote character
by GHC 31 Jul '16

31 Jul '16

#860: CPP fails when a macro is used on a line containing a single quote character -------------------------------------+------------------------------------- Reporter: ketil@… | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: cpp quote | prime Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andreas.abel): > There are other gotchas with CPP (e.g. the backslash-at-the-end-of-the- line thing). See, for instance, ticket:12391 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/860#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #860: CPP fails when a macro is used on a line containing a single quote character
by GHC 30 Jul '16

30 Jul '16

#860: CPP fails when a macro is used on a line containing a single quote character -------------------------------------+------------------------------------- Reporter: ketil@… | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: cpp quote | prime Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/860#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #860: CPP fails when a macro is used on a line containing a single quote character
by GHC 30 Jul '16

30 Jul '16

#860: CPP fails when a macro is used on a line containing a single quote character -------------------------------------+------------------------------------- Reporter: ketil@… | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: cpp quote | prime Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/860#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12121: FlexibleContexts is under specified
by GHC 28 Jul '16

28 Jul '16

#12121: FlexibleContexts is under specified -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: #12010 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been reading the documentation on `FlexibleContexts`. It's pretty confusing. === Structure The documentation is scattered around 3 different sections: * 9.8.1.2. The superclasses of a class declaration (this is where the [http://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.… #ghc-flag--XFlexibleContexts link] from the flag reference takes you). * 9.8.3.3. Relaxed rules for instance contexts * 9.15.2. The context of a type signature Maybe it's ok to separate it like this, but it took me a while to figure out that there //are// actually three different sections. A simple solution would be to mention that there are 3 different sections, in each section (it already does so in the last section). === Specification > The -XFlexibleContexts flag lifts the Haskell 98 restriction that the type-class constraints in a type signature must have the form `(class type-variable)` or `(class (type-variable type1 type2 ... typen))`. That's all fine and well, but hardly teaches me anything. I would like to know which type-class constraints //are// allowed with `FlexibleContexts`. Or in other words: what is a definition of a "type- class constraint" with `FlexibleContexts`? This is the old grammar: {{{ context → class | ( class1 , … , classn ) (n ≥ 0) class → qtycls tyvar | qtycls ( tyvar atype1 … atypen ) (n ≥ 1) }}} What is the new one? === Examples * These are the example mentioned in the section on the context of a class declaration (9.8.1.2): {{{ class Functor (m k) => FiniteMap m k where class (Monad m, Monad (t m)) => Transform t m where lift :: m a -> (t m) a }}} Problem is, they neither require `FlexibleContexts`, nor do they compile with `FlexibleContexts`! Those examples require `MultiParamTypeClasses`. `MultiParamTypeClasses` doesn't enable `FlexibleContexts` automatically. * The section on instance contexts doesn't have any examples. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12445: showSDocUnsafe generate GHC panic
by GHC 28 Jul '16

28 Jul '16

#12445: showSDocUnsafe generate GHC panic -------------------------------------+------------------------------------- Reporter: Bet | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: GHC API | Version: 7.10.3 Keywords: GHC panic | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Try in ghci: {{{#!hs :set -package ghc :m Outputable let x = text "SomeDoc" showSDocUnsafe x }}} The code abobe generate: "ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): v_unsafeGlobalDynFlags: not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12440: Strictness of span and break does not match documentation
by GHC 26 Jul '16

26 Jul '16

#12440: Strictness of span and break does not match documentation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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 [http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#v:span documentation] of `span` says `span p xs` is equivalent to `(takeWhile p xs, dropWhile p xs)` However, that's not literally true since `span p xs` is _|_ if either `xs` is _|_ or `xs = x :_` and `p x` is _|_. This same error is also present in the Haskell 98 report, which states the same property of `span` but gives a definition equivalent to the one used by GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12440> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12436: Too many nested forkProcess's eventually cause SIGSEGV in the child
by GHC 26 Jul '16

26 Jul '16

#12436: Too many nested forkProcess's eventually cause SIGSEGV in the child -------------------------------------+------------------------------------- Reporter: tolik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: System | Keywords: forkProcess, | Operating System: Linux SIGSEGV | Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Original Haskell-cafe thread: https://groups.google.com/forum/#!msg /haskell-cafe/kHMsYRMcdPs/vWD9T7saCAAJ Here is a slightly modified test program from that thread: {{{#!hs -- fork-bug.hs import System.Environment (getArgs) import System.Posix.Process (forkProcess) fork_ 0 = putStrLn "Done forking" fork_ n = forkProcess (fork_ (n - 1)) >> return () main = do [n] <- getArgs fork_ (read n) }}} With n big enough the program doesn't print anything and crashes with SIGSEGV at (semi-)random places (the crash is somewhat hard to demonstrate from the shell): {{{ $ ./fork-bug 100; sleep 0.1 Done forking $ ./fork-bug 500; sleep 0.1 Done forking $ ./fork-bug 1000; sleep 0.1 $ }}} Looks like the problem lies in C-stack exhaustion in children - lowering the stack limit makes the crash happen much earlier: {{{ $ (ulimit -s 128; ./fork-bug 5; sleep 0.1) Done forking $ (ulimit -s 128; ./fork-bug 6; sleep 0.1) Done forking $ (ulimit -s 128; ./fork-bug 7; sleep 0.1) $ (ulimit -s 128; ./fork-bug 8; sleep 0.1) $ }}} Tracing with gdb shows that with each forkProcess the stack in the forked child goes deeper and deeper, although gdb shows call stacks of constant depth: {{{ $ gdb -q fork-bug Reading symbols from fork-bug...(no debugging symbols found)...done. (gdb) set follow-fork-mode child (gdb) break forkProcess Breakpoint 1 at 0x470a60 (gdb) display $rsp (gdb) run 3 Starting program: /tmp/fork-bug 3 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, 0x0000000000470a60 in forkProcess () 1: $rsp = (void *) 0x7fffffff9e28 (gdb) bt #0 0x0000000000470a60 in forkProcess () #1 0x0000000000406215 in s3sP_info () #2 0x0000000000000000 in ?? () (gdb) continue Continuing. [New process 20434] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Switching to Thread 0x7ffff7fd5740 (LWP 20434)] Breakpoint 1, 0x0000000000470a60 in forkProcess () 1: $rsp = (void *) 0x7fffffff5d08 (gdb) bt #0 0x0000000000470a60 in forkProcess () #1 0x0000000000406215 in s3sP_info () #2 0x0000000000000000 in ?? () (gdb) continue Continuing. [New process 20435] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Switching to Thread 0x7ffff7fd5740 (LWP 20435)] Breakpoint 1, 0x0000000000470a60 in forkProcess () 1: $rsp = (void *) 0x7fffffff1be8 (gdb) bt #0 0x0000000000470a60 in forkProcess () #1 0x0000000000406215 in s3sP_info () #2 0x0000000000000000 in ?? () (gdb) continue Continuing. [New process 20436] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Done forking [Inferior 4 (process 20436) exited normally] }}} These results are from Ubuntu 14.04.4 with GHC 7.6.3, although OP reported using 7.10.3 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12436> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12431: Type checker rejects valid program
by GHC 26 Jul '16

26 Jul '16

#12431: Type checker rejects valid program -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since at least 6e280c2c5b2903ae38f4da15a41ea94793907407 GHC fails to compile `resourcet` due to a likely erroneous type error. Here is a minimal case that reproduces the error, {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE FlexibleContexts #-} module Hi where import Control.Monad (liftM, ap) data Allocated a = Allocated a newtype Acquire a = Acquire ((forall b. IO b -> IO b) -> IO (Allocated a)) instance Functor Acquire where fmap = liftM instance Applicative Acquire where pure a = Acquire (\_ -> return (Allocated a)) (<*>) = ap instance Monad Acquire where return = pure Acquire f >>= g' = Acquire $ \restore -> do Allocated x <- f restore let Acquire g = g' x Allocated y <- g restore return $! Allocated y }}} This fails with, {{{ $ ghc Hi.hs [1 of 1] Compiling Hi ( Hi.hs, Hi.o ) Hi.hs:22:21: error: • Couldn't match expected type ‘t’ with actual type ‘(forall b1. IO b1 -> IO b1) -> IO (Allocated b)’ ‘t’ is a rigid type variable bound by the inferred type of g :: t at Hi.hs:22:13-28 • In the pattern: Acquire g In a pattern binding: Acquire g = g' x In the expression: do { Allocated x <- f restore; let Acquire g = g' x; Allocated y <- g restore; return $! Allocated y } • Relevant bindings include g' :: a -> Acquire b (bound at Hi.hs:20:19) (>>=) :: Acquire a -> (a -> Acquire b) -> Acquire b (bound at Hi.hs:20:15) }}} Despite compiling with 8.0.1 and earlier versions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12434: Test suite should not copy in un-versioned files
by GHC 25 Jul '16

25 Jul '16

#12434: Test suite should not copy in un-versioned files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- This is something like a follow on to #12112. Basically, this bug was fixed by blacklisting the copying of some files. Well I observed that for some test-cases I was working on, where I specified `-outputdir`, my local output directory was being copied... because its file name didn't match. Wouldn't it be better to just not copy any files which are not versioned? I guess this won't work if the test suite is being run from not Git, but if Git is available that seems like a more accurate test. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12434> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0