August 2016 - ghc-tickets

[GHC] #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler'
by GHC 05 Sep '16

05 Sep '16

#12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' -------------------------------------+------------------------------------- Reporter: DanielG | 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: -------------------------------------+------------------------------------- GHC used to export 'defaultCleanupHandler' going back as far as 7.4, starting with 8.0 no equivalent function seems to be exported. Please consider exporting 'withCleanupSession' as a replacement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10858: Smaller generated instances
by GHC 05 Sep '16

05 Sep '16

#10858: Smaller generated instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- With very large modules with lots of deriving code, GHC spends quite some time compiling. I believe that we can improve things by reducing the size of the generated code. (More in the comments) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10161: GHC does not relink if a library's code changed
by GHC 03 Sep '16

03 Sep '16

#10161: GHC does not relink if a library's code changed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Test case for reproducing: https://github.com/nh2/ghc-relinking-avoidance- bug/ ---- {{{myexe}}} is an executable that depends on {{{mylib}}}, whose {{{myfun = putStrLn "output 1"}}}. If we install {{{mylib}}}, compile {{{myexe}}}, then change mylib's code to {{{myfun = putStrLn "output 2"}}}, re-install it, and then compile {{{myexe}}}, then GHC does not notice that the library code changed. It avoids re-linking myexe, with the result that the program prints {{{output 1}}} when you told it to compile against code that prints {{{output 2}}}. ---- Note that I had to use {{{NOINLINE myfun}}} to trigger the bug, since otherwise {{{myfun}}}'s code would have ended up in the interface file, thus changing the package ID, which naturally forces GHC to relink (even re-compile). With the {{{NOINLINE}}}, the package IDs of the two different versions of {{{myfun}}} are completely identical. I think that is correct, since the package ID only hashes the API and ABI, not the actual implementation, right? How does GHC decide when to relink? I think in the present case, it doesn't notice that the object/archive file of the library changed. Does it check that somehow? Just looking at API and API can't be enough to make a decision for linking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11565: Restore code to handle '-fmax-worker-args' flag
by GHC 02 Sep '16

02 Sep '16

#11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- When i had a pass through DynFlags I've noticed dead code: https://phabricator.haskell.org/D1727 It was accidentally lost 3 years ago in major update changeset:0831a12ea2fc73c33652eeec1adc79fa19700578 The consensus is to try to put option handling back. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11565> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10923: GHC should recompile if flags change
by GHC 02 Sep '16

02 Sep '16

#10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Example: {{{ ezyang@sabre:~$ rm B.hi ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs -O compilation IS NOT required }}} Pretty minor, but would be nice to have fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12557: Regression in type inference with RankNTypes
by GHC 02 Sep '16

02 Sep '16

#12557: Regression in type inference with RankNTypes -------------------------------------+------------------------------------- Reporter: slindley | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs foo :: ((forall a.f a) -> f r) -> f r foo g = undefined }}} In GHC 7.10.3: {{{ *Main> :t \g -> foo g \g -> foo g :: ((forall a. f a) -> f r) -> f r }}} In GHC 8.0.1: {{{ *Main> :t \g -> foo g <interactive>:1:11: error: • Couldn't match expected type ‘(forall a. f a) -> f r’ with actual type ‘t’ ‘t’ is a rigid type variable bound by the inferred type of it :: t -> f r at <interactive>:1:1 • In the first argument of ‘foo’, namely ‘g’ In the expression: foo g In the expression: \ g -> foo g • Relevant bindings include g :: t (bound at <interactive>:1:2) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11740: RFC kind synonyms
by GHC 02 Sep '16

02 Sep '16

#11740: RFC kind synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Are any of these useful now that we have kind synonyms: {{{#!hs -- Control.Category type Cat k = k -> k -> Type -- Data.Kind type Kind = Type type Types = [Type] type TypeClass = Type -> Constraint }}} `Cat` is not limited to `Control.Category` but applies in all [https://github.com/ekmett/hask/blob/master/src/Hask/Category.hs#L68 hask], [https://github.com/mikeizbicki/subhask/blob/b5433b959914d8214bcc4f130ff1b3d… subhask] and is defined by [https://github.com/ttuegel/recategorize/blob/master/src/Category/Category.h… recategorize]. It lets you rewrite: {{{#!hs -- newtype Yoneda (p :: i -> i -> *) (a :: i) (b :: i) = Op { getOp :: p b a } newtype Yoneda :: Cat i -> Cat i where Op :: { getOp :: p b a } -> Yoneda p a b -- type family Op (p :: i -> i -> *) :: i -> i -> * where type family Op (p :: Cat i) :: Cat i where Op (Yoneda p) = p Op p = Yoneda p -- data CatT (cat :: * -> * -> *) (a :: k) (b :: k) (cat1 :: k -> k -> *) (cat2 :: k -> k -> *) data CatT (cat :: Cat Type) (a :: k) (b :: k) (cat1 :: Cat k) (cat2 :: Cat k) -- class (Category' (Dom f), Category' (Cod f)) => Functor (f :: i -> j) where -- type Dom f :: i -> i -> * -- type Cod f :: j -> j -> * class (Category' (Dom f), Category' (Cod f)) => Functor (f :: i -> j) where type Dom f :: Cat i type Cod f :: Cat j -- data Nat (p :: i -> i -> *) (q :: j -> j -> *) (f :: i -> j) (g :: i -> j) where data Nat (p :: Cat i) (q :: Cat j) (f :: i -> j) (g :: i -> j) where -- instance Cartesian ((->) :: * -> * -> *) where instance Cartesian ((->) :: Cat Type) where }}} and {{{#!hs -- class (f x, g x) => And (f :: * -> Constraint) (g :: * -> Constraint) (x :: *) -- instance (f x, g x) => And (f :: * -> Constraint) (g :: * -> Constraint) (x :: *) class (f x, g x) => And (f :: TypeClass) (g :: TypeClass) (x :: *) instance (f x, g x) => And (f :: TypeClass) (g :: TypeClass) (x :: *) -- ToContext (fs :: [TypeClass]) :: TypeClass where type family ToContext (fs :: [* -> Constraint]) :: * -> Constraint where ToContext (f:g:fs) = And f (ToContext (g:fs)) ToContext '[f] = f }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers
by GHC 01 Sep '16

01 Sep '16

#12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we have in a file: {{{#!hs data X = X String unX (X s) = s }}} And then load the file in ghci with `-fobject-code` and {{{ > data Y = Y String > unX (Unsafe.Coerce.unsafeCoerce (Y "foo")) "Segmentation fault (core dumped) }}} Even though we are shooting ourselves in the foot there, the constructors `X` and `Y` are represented identically internally, so the code is supposed to work. And it does work if we either move `unX` into ghci'd code, or `Y` into compiled code. After a legthy debugging session with @rwbarton over IRC, we've identified the culprit of this. As [[Commentary/Rts/HaskellExecution/PointerTagging]] states, "In the continuation of an algebraic case, R1 is assumed tagged". And all compiled constructors tag the pointer when entered, e.g: {{{ Dump of assembler code for function ghczmprim_GHCziTypes_False_static_info: 0x00007fffef8dd018 <+0>: 48 ff c3 inc %rbx 0x00007fffef8dd01b <+3>: ff 65 00 jmpq *0x0(%rbp) Dump of assembler code for function base_GHCziBase_Just_static_info: 0x00007ffff03eb780 <+0>: 48 83 c3 02 add $0x2,%rbx 0x00007ffff03eb784 <+4>: ff 65 00 jmpq *0x0(%rbp) Dump of assembler code for function ghczmprim_GHCziTypes_GT_static_info: 0x00007fffef8dd1f8 <+0>: 48 83 c3 03 add $0x3,%rbx 0x00007fffef8dd1fc <+4>: ff 65 00 jmpq *0x0(%rbp) Dump of assembler code for function base_GHCziRTSziFlags_HeapByClosureType_static_info: 0x00007ffff057e768 <+0>: 48 ff c3 inc %rbx // more than 7 constructors so all tags are '1' 0x00007ffff057e76b <+3>: ff 65 00 jmpq *0x0(%rbp) }}} Whereas all ghci-bound data constructors share the `stg_interp_constr_entry` entry code (with an optional trampoline leading there): {{{ Dump of assembler code from 0x7ffff7ff3080 to 0x7ffff7ff3090: => 0x00007ffff7ff3080: jmpq *0x2(%rip) # 0x7ffff7ff3088 0x00007ffff7ff3088: 0x00007fffef4c9388 Dump of assembler code for function stg_interp_constr_entry: 0x00007fffef4c9388 <+0>: ff 65 00 jmpq *0x0(%rbp) }}} Relevant code: source:libraries/ghci/GHCi/InfoTable.hsc#L32 So in the end, compiled code relies on the assumption that the pointer is tagged, and ghci constructors produce untagged pointers. Even though it is currently impossible to have compiled code pattern match on a ghci constructor, I think this shouldn't happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12209: Windows: ByteCodeLink can't find labels "lseek" and "write"
by GHC 01 Sep '16

01 Sep '16

#12209: Windows: ByteCodeLink can't find labels "lseek" and "write" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tests `ffi017` and `ffi021` are failing on Windows, for `WAY=ghci`. > During interactive linking, GHCi couldn't find the following symbol: > lseek > During interactive linking, GHCi couldn't find the following symbol: > write These are regressions from 7.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs
by GHC 01 Sep '16

01 Sep '16

#12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs ------------------------------+--------------------------------- Reporter: pl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+--------------------------------- GHCi (win32, v8.0.1) gives strange unknown symbols when being run using a library that interfaces code written in C or C++. Compiled code runs fine. As an example I use the eigen-2.1.6 package from hackage. However, it should be noted that I get a similar error message when trying to link a package that uses libgsl (gsl has been compiled with the mingw-gcc that ships with haskell-platform). When I compile the little script from the eigen-manual on hackage {{{#!hs module Main where import Data.Eigen.Matrix import Data.Eigen.LA main = do let a :: MatrixXd a = fromList [[1,2,3], [4,5,6], [7,8,10]] b = fromList [[3],[3],[4]] x = solve ColPivHouseholderQR a b putStrLn "Here is the matrix A:" >> print a putStrLn "Here is the vector b:" >> print b putStrLn "The solution is:" >> print x }}} I get (as expected): {{{ Here is the matrix A: Matrix 3x3 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 10.0 Here is the vector b: Matrix 3x1 3.0 3.0 4.0 The solution is: Matrix 3x1 -2.0 1.0000000000000016 0.9999999999999988 }}} However, when I try to run it in GHCi I get {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> main ghc.exe: C:/Program Files (x86)/Haskell Platform/8.0.1/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/libstdc++.a: unknown symbol `___emutls_get_address' ghc.exe: Could not on-demand load symbol '___cxa_get_globals' ghc.exe: C:/Program Files (x86)/Haskell Platform/8.0.1/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/libstdc++.a: unknown symbol `___cxa_get_globals' ghc.exe: Could not on-demand load symbol '___cxa_begin_catch' ghc.exe: D:\Users\U439644\AppData\Roaming\cabal\i386-windows- ghc-8.0.1\eigen-2.1.6-6ZlfU8NIal9qgw3j5GclW\HSeigen-2.1.6-6 ZlfU8NIal9qgw3j5GclW.o: unknown symbol `___cxa_begin_catch' ghc.exe: unable to load package `eigen-2.1.6' }}} I tried the same on OS X using GHCi v8.0.1. There everything works as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12496> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4