June 2016 - ghc-tickets

[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

[GHC] #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable
by GHC 12 Sep '16

12 Sep '16

#12031: GHCi segfaults on Windows when compiling C code using extern-declared variable ----------------------------------------+------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- Phyx- and I [https://phabricator.haskell.org/D1805#59850 noticed] that `bindings-GLFW` unpredictably segfaults when running this simple program in interpreted code: {{{#!hs module Main where import qualified Graphics.UI.GLFW as G main :: IO () main = do successfulInit <- G.init return () }}} Phyx- [https://phabricator.haskell.org/D1805#60275 suspected] that it had something to do with the `extern`-declared variables used in the GLFW library itself. To avoid requiring a dependency on GLFW, I boiled the issue down to a small, reproducible example with no dependencies, located at https://github.com/RyanGlScott/extern-bug. I will reproduce the code below: {{{#!c // foo.h #ifndef FOO_H #define FOO_H extern int foo; void bar(void); void baz(void); #endif }}} {{{#!c // bar.c #include "foo.h" int foo = 0; void bar(void) { foo = 1; baz(); } }}} {{{#!c // baz.c #include "foo.h" #include <stdio.h> void baz(void) { printf("The value of foo is %d\n", foo); // Segfaults on this line fflush(stdout); } }}} {{{#!hs -- ExternBug.hs {-# LANGUAGE ForeignFunctionInterface #-} module ExternBug (bar) where {-# INCLUDE foo.h #-} foreign import ccall "bar" bar :: IO () }}} While I've managed to reproduce this bug sporadically with GHC 7.10.3, it happens far more reliably with GHC 8.0. Here is what I did to trigger the segfault: 1. Run `ghc bar.c baz.c ExternBug.hs` 2. Run `ghci bar.o baz.o ExternBug.hs` 3. Invoke `bar` I'm not sure what's happening, but there seem to be four important ingredients here: 1. This needs to be run in interpreted code. Compiled code does not have this issue. 2. The C sources need to be compiled to object code using GHC. (For example, if you link the MSYS2-provided `mingw-w64-x86_64-glfw` DLL, it will work correctly.) 3. There needs to be an `extern`-declared variable. (For example, uncommenting the lines mentioning the `foo` variable will make the issue go away.) 4. There needs to be at least two `.c` files. One file needs to assign a value to the `extern`-declared variable, and the other file needs to use the value. (For example, if you put the definitions of `bar` and `baz` in the same file, the bug doesn't occur.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12031> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11691: Documentation indicates RelaxedPolyRec is optional
by GHC 12 Sep '16

12 Sep '16

#11691: Documentation indicates RelaxedPolyRec is optional -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation in "Other Type System Extensions" says "If `-XRelaxedPolyRec` is specified ..." and "With -XRelaxedPolyRec ..." and "This flag implies `-XRelaxedPolyRec`". There may be other references elsewhere. In fact, `RelaxedPolyRec` has been not only the default but in fact ''impossible to turn off'' since at least GHC 7.6.3. The documentation should probably stop mentioning the (long-meaningless) flag, and simply state that GHC uses Jones's extension instead. The Haskell Report section cited regarding contexts in explicit signatures for declaration groups is so vague that I'm not sure it's even worth mentioning that GHC relaxes it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11691> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9089: Local .ghci_history
by GHC 10 Sep '16

10 Sep '16

#9089: Local .ghci_history ------------------------------------+------------------------------------- Reporter: jcristovao | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hello, It would be nice to allow a local .ghci_history to be used (when available) instead of the global .ghc/ghci_history. This would be similar in behaviour to the .ghci rules: http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/ghci-dot-files.html And I believe this should not be too complicated to do (I can even try it myself, if there is interest). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11433: sphinx: Error: source directory and destination directory are same.
by GHC 08 Sep '16

08 Sep '16

#11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1-rc1 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 the Debian package, the build fails with {{{ writing output... [100%] win32-dlls generating indices... genindex writing additional pages... search copying images... [100%] images/prof_scc.svg copying static files... done copying extra files... done dumping search index in English (code: en) ... done dumping object inventory... done build succeeded, 5 warnings. /usr/bin/sphinx-build -b man -d docs/users_guide/.doctrees-man docs/users_guide docs/users_guide Error: source directory and destination directory are same. docs/users_guide/ghc.mk:30: recipe for target 'docs/users_guide/ghc.1' failed make[3]: *** [docs/users_guide/ghc.1] Error 1 Makefile:122: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/<<PKGBUILDDIR>>' }}} Full build log attached. Any idea what might be causing this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11433> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9880: ghc crashes on th splices in instance context
by GHC 07 Sep '16

07 Sep '16

#9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Given Class.hs: {{{#!hs module Class where class Foo a where bar :: a -> Int }}} TH.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} module TH where import Class import Language.Haskell.TH mkFun :: Q [Dec] mkFun = return [FunD 'bar [Clause [WildP] (NormalB (LitE (IntegerL 0))) []]] }}} and Instance.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Instance where import TH import Class instance Foo Bool where $(mkFun) }}} compiling the project crashes ghc with {{{ #ghc --make Instance.hs [2 of 3] Compiling TH ( TH.hs, TH.o ) [3 of 3] Compiling Instance ( Instance.hs, Instance.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): cvBindsAndSigs $[splice{v}]mkFun{v} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9880> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10062: Codegen on sequential FFI calls is not very good
by GHC 05 Sep '16

05 Sep '16

#10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm writing a library for efficiently building up a byte buffer. The fastest approach I've found is via FFI, with restricted effects like ST. It's over twice as fast as ByteString Builder. Consider this example API usage: https://github.com/chadaustin/buffer- builder/blob/6bd0a39c56f63ab751faf29f9784ac87d52638be/bench/Bench.hs#L46 It compiles into an instruction sequence containing direct, sequenced FFI calls. For example, the last three calls work out to: addq $8,%rsp movq %rbx,%rdi movq 72(%rsp),%rax movq %rax,%rsi subq $8,%rsp movl $0,%eax call bw_append_bsz addq $8,%rsp movq %rbx,%rdi movl $35,%esi subq $8,%rsp movl $0,%eax call bw_append_byte addq $8,%rsp movq %rbx,%rdi movq 64(%rsp),%rax movq %rax,%rsi subq $8,%rsp movl $0,%eax call bw_append_bsz I don't know why rsp is being changed so much. I also can't explain the assignment to eax before the call. (It should also be xorl eax,eax, I would think.) To my reading, the above instruction sequence could be reduced to: movq %rbx,%rdi movq 64(%rsp),%rsi call bw_append_bsz movq %rbx,%rdi movl $35,%esi call bw_append_byte movq %rbx,%rdi movq 56(%rsp),%rsi call bw_append_bsz To reproduce, check out git@github.com:chadaustin/buffer-builder.git at revision 6bd0a39c56f63ab751faf29f9784ac87d52638be cabal configure --enable-benchmarks cabal bench And then look at the ./dist/build/bench/bench-tmp/bench/Bench.dump-asm file. This is specifically on OS X 64-bit with GHC 7.8.3, but I saw similar code generation on GHC 7.6 on Linux 64-bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm
by GHC 05 Sep '16

05 Sep '16

#11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building git HEAD with `BuildFlavour = perf-llvm` and then running the tests results in 500+ tests failing, all with the same error: {{{ ghc-stage2: /xxx/libraries/ghc-prim/dist-install/build/HSghc- prim-0.5.0.0.o: unknown symbol `__udivti3' ghc-stage2: unable to load package `ghc-prim-0.5.0.0' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12010: Incorrect return types for recv() and send() on Windows
by GHC 05 Sep '16

05 Sep '16

#12010: Incorrect return types for recv() and send() on Windows --------------------------------------+---------------------------------- Reporter: enolan | Owner: enolan Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- They return signed 32 bit ints on Windows, even on a 64 bit OS, rather than Linux's 64 bit ssize_t. This means when recv() returned -1 to signal an error we thought it was 4294967295. It was converted to an int, -1 and the buffer was memcpy'd which caused a segfault. Other bad stuff happened with send()s. The problem is in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` in `GHC.IO.FD` which are only called in the threaded RTS. See also note CSsize in System.Posix.Internals. I have a patch and a test incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12133: ConstraintKinds inference failure (regression from 7.10)
by GHC 05 Sep '16

05 Sep '16

#12133: ConstraintKinds inference failure (regression from 7.10) -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Posting for a friend who was believed to be spam: {{{#!hs {-# LANGUAGE CPP #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} module T where #if __GLASGOW_HASKELL__ >= 800 import GHC.Classes (IP(..)) #else import GHC.IP (IP(..)) #endif import GHC.Exts (Constraint) -- | From "Data.Constraint": data Dict :: Constraint -> * where Dict :: a => Dict a newtype a :- b = Sub (a => Dict b) infixl 1 \\ -- required comment (\\) :: a => (b => r) -> (a :- b) -> r r \\ Sub Dict = r -- | GHC 7.10.2 type checks this function but GHC 8.0.1 does not unless -- you modify this example in one of the following ways: -- -- * uncomments the type signature for 'Sub' -- -- * flatten the nested pairs of constraints into a triple of constraints -- -- * replace 'IP sym ty' with 'c9', where 'c9' is a new constraint variable. -- -- The error message is listed below. foo :: forall c1 c2 c3 sym ty . (c1, c2) :- c3 -> (c1, (IP sym ty, c2)) :- (IP sym ty, c3) foo sp = ( Sub -- :: ((c1, (IP sym ty, c2)) => Dict (IP sym ty, c3)) -- -> (c1, ((IP sym ty), c2)) :- (IP sym ty, c3) ) ( (Dict \\ sp) :: Dict (IP sym ty, c3) ) {- Compiler error message: GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling T ( t.hs, interpreted ) t.hs:44:13: error: • Could not deduce: IP sym ty arising from a use of ‘Dict’ from the context: (c1, (IP sym ty, c2)) bound by a type expected by the context: (c1, (IP sym ty, c2)) => Dict (IP sym ty, c3) at t.hs:(40,10)-(44,49) or from: c3 bound by a type expected by the context: c3 => Dict (IP sym ty, c3) at t.hs:44:13-22 • In the first argument of ‘(\\)’, namely ‘Dict’ In the first argument of ‘Sub’, namely ‘((Dict \\ sp) :: Dict (IP sym ty, c3))’ In the expression: (Sub) ((Dict \\ sp) :: Dict (IP sym ty, c3)) • Relevant bindings include foo :: (c1, c2) :- c3 -> (c1, (IP sym ty, c2)) :- (IP sym ty, c3) (bound at t.hs:40:1) Failed, modules loaded: none. -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12133> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6