July 2016 - ghc-tickets

[GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial
by GHC 25 Nov '16

25 Nov '16

#11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Look at `CoreUtils.exprIsTrivial` and `CorePrep.cpe_ExprIsTrivial`. They are identical! The latter has a comment saying {{{ cpe_ExprIsTrivial :: CoreExpr -> Bool -- Version that doesn't consider an scc annotation to be trivial. }}} but the code does not treat ticks any differently. So the question is: '''are they supposed to be different'''? And if not, can we just combine them? Peter W, Simon M: this is your territory. I don't understand tick stuff well enough. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #11575: Program crashes only when compiled via LLVM
by GHC 23 Nov '16

23 Nov '16

#11575: Program crashes only when compiled via LLVM --------------------------------------+---------------------------------- Reporter: Guest00000 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.3 Keywords: llvm | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- `llvm-test.hs`: {{{#!hs import System.IO import Foreign.Storable import Foreign.Marshal.Alloc import Data.Word main = do hSetBuffering stdout NoBuffering test 1000 test 5000 where test n = do allocaBytes (n * 4) $ \p -> do sequence_ [ pokeByteOff p (i * 4) (0x12345678 :: Word32) | i <- [ 0 .. n - 1 ] ] putStrLn $ show n ++ " fine" }}} ---- Cygwin shell: {{{ user@pc ~ $ ghc llvm-test.hs && ./llvm-test.exe [1 of 1] Compiling Main ( llvm-test.hs, llvm-test.o ) Linking llvm-test.exe ... 1000 fine 5000 fine user@pc ~ $ touch llvm-test.hs user@pc ~ $ ghc llvm-test.hs -fllvm && ./llvm-test.exe [1 of 1] Compiling Main ( llvm-test.hs, llvm-test.o ) Linking llvm-test.exe ... 1000 fine Segmentation fault }}} ---- {{{ <erikd> `Guest00000: try adding -O2 to the compiler command line. <`Guest00000> erikd: it now segfaults even before printing "1000 fine" <`Guest00000> wait, one time it printed one character "1" before crashing }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11575> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8300: split-objs doesn't split on LLVM
by GHC 22 Nov '16

22 Nov '16

#8300: split-objs doesn't split on LLVM ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `-split-objs` is allowed with `-fllvm`, but it doesn't really do anything. E.g. in my perf-llvm build I have a `libHSbase-4.7.0.0.a` with `Applicative__1.o`, `Arrow__1.o` etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12024: GHC leaks GHC.Prim.~# into type
by GHC 21 Nov '16

21 Nov '16

#12024: GHC leaks GHC.Prim.~# into type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | 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: -------------------------------------+------------------------------------- {{{#!hs data A a where X :: A [xxx] pattern X' = X }}} the inferred type of which is {{{ >>> :info X' pattern X' :: () => t GHC.Prim.~# [xxx] => A t }}} Casts use unlifted equality as I understand it, but lifted would present a nicer UI: {{{#!hs pattern X' :: () => t ~> [xxx] => A t pattern X' = X }}} In my own code this means I get the following monster {{{#!hs pattern MkArr :: () => (GetTy a, GetTy b, GetTy t, a GHC.Prim.~# 'Sca ('Number 'I32), b GHC.Prim.~# 'Sca a1, t GHC.Prim.~# 'Arr a1, GetSca a1) => Exp a -> Id -> Exp b -> Exp t }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12024> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12079: seg fault while using gtk
by GHC 19 Nov '16

19 Nov '16

#12079: seg fault while using gtk --------------------------------------+---------------------------------- Reporter: doofin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- {{{#!hs {-# LANGUAGE OverloadedStrings #-} module Main where import Graphics.UI.Gtk import System.Glib.Signals import Graphics.UI.Gtk.SourceView import Graphics.UI.Gtk.SourceView.SourceGutter import Graphics.UI.Gtk.SourceView.SourceCompletion import Graphics.UI.Gtk.SourceView.SourceMark import Graphics.UI.Gtk.SourceView.SourceBuffer import Graphics.UI.Gtk.Multiline.TextBuffer import Graphics.UI.Gtk.Gdk.EventM import Control.Monad.Trans import System.FSNotify import System.Environment import Control.Concurrent (threadDelay) import Control.Monad (forever) import qualified Data.Text as T import qualified Data.Text.IO as T import Data.Tuple import Data.Tuple.HT import Control.Concurrent main=do args<-getArgs print args let filename=head args txt<-T.readFile filename gtk txt $ \srcbf->do notify $ \evt -> case evt of Modified fp _->if (T.unpack $ Prelude.last $ T.splitOn "/" $ T.pack fp)==filename then do txtnew<-T.readFile $ head args postGUIAsync $ textBufferSetText srcbf (txtnew::T.Text) else return () _->return () return () notify action=withManager $ \mgr-> do --mgr<-startManager watchTree mgr -- manager "." -- directory to watch (const True) -- predicate $ \evt->do print evt-- action action evt forever $ threadDelay 1000000 -- sleep forever (until interrupted) gtk inittext act= do initGUI window <- windowNew windowSetDefaultSize window 900 600 windowSetPosition window WinPosCenter srcbf<-sourceBufferNew Nothing sourceView <- sourceViewNewWithBuffer srcbf scrolledWindow <- scrolledWindowNew Nothing Nothing sourceViewSetShowLineNumbers sourceView True textViewSetWrapMode sourceView WrapWord textBufferInsertAtCursor srcbf ("fdsf"::String) textBufferSetText srcbf inittext scrolledWindow `containerAdd` sourceView window `containerAdd` scrolledWindow widgetShowAll window on sourceView keyPressEvent $ do kl<-eventKeyName liftIO $ putStr $ show $ kl liftIO $ mapM_ (\(x,y)->if x==kl then textBufferInsertAtCursor srcbf (y::String) else return ()) pairs return False on window deleteEvent $ liftIO mainQuit >> return False connectGeneric "notify::cursor-position" False srcbf $ do print "adsfd" forkIO $ do act srcbf --onDestroy window mainQuit mainGUI pairs=[("parenleft",")"),("[","]")] }}} the program runs ok before adding the line {{{#!hs connectGeneric "notify::cursor-position" False srcbf $ do print "adsfd" }}} then i run ghc thisfile.hs -debug gdb thisfile run somefile move the cursor inside the textview,then seg fault happened bt {{{ result: Program received signal SIGSEGV, Segmentation fault. 0x00007fffeea0f4f0 in ?? () (gdb) bt #0 0x00007fffeea0f4f0 in ?? () #1 0x00000000000002f5 in ?? () #2 0x0000000000000309 in ?? () #3 0x00007fffffff44f8 in ?? () #4 0x00007fffffff4458 in ?? () #5 0x00007fff04fe0101 in ?? () #6 0x0000000000000113 in ?? () #7 0x00000000000002e5 in ?? () #8 0x0000000001db00ac in ?? () #9 0x00007fffeea13a21 in ?? () #10 0x00007fffeeaf5010 in ?? () #11 0x0000000000a8d709 in base_GHCziIOziFD_zdfBufferedIOFD2_closure () #12 0x00007fffeea07942 in ?? () #13 0x0000000000a8593a in base_GHCziIOziBuffer_WriteBuffer_closure () #14 0x0000000000000800 in ?? () #15 0x0000000000000000 in ?? () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11532: ghc: panic! occured
by GHC 19 Nov '16

19 Nov '16

#11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | 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: -------------------------------------+------------------------------------- I'd like to try install by following: {{{ $ cabal sandbox init $ cabal install metadata Resolving dependencies... Notice: installing into a sandbox located at /home/cutsea110/devel/haskell/sandbox/.cabal-sandbox Configuring metadata-0.4.2.0... Building metadata-0.4.2.0... : : [1036 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation[boot] ( Text/HTML5/MetaData/Schema/TelevisionStation.hs-boot, dist/dist-sandbox- 304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o-boot ) [1037 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation ( Text/HTML5/MetaData/Schema/TelevisionStation.hs, dist/dist-sandbox- 304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): LocalReg's live-in to graph cpd3t {_sp8MJ::P64} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: metadata-0.4.2.0 failed during the building phase. The exception was: ExitFailure 1 }}} -- regards. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ()))
by GHC 18 Nov '16

18 Nov '16

#12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) -------------------------------------+------------------------------------- Reporter: lspitzner | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DeriveDataTypeable, StandaloneDeriving, PolyKinds #-} import qualified Data.Data data Mu f = Mu (f (Mu f)) deriving instance Data.Data.Data (Mu (Const ())) }}} produces {{{ • No instance for (Data (Const () (Mu (Const ())))) arising from a use of ‘k’ • In the expression: (z Mu `k` a1) In an equation for ‘gfoldl’: gfoldl k z (Mu a1) = (z Mu `k` a1) When typechecking the code for ‘gfoldl’ in a derived instance for ‘Data (Mu (Const ()))’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Data (Mu (Const ()))’ }}} while other type constructors work, e.g. {{{#!hs deriving instance Data.Data.Data (Mu []) deriving instance Data.Data.Data (Mu ((,) ())) }}} i am not sure if #10835 is related. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8321: improve basic block layout on LLVM backend by predicting stack/heap checks
by GHC 17 Nov '16

17 Nov '16

#8321: improve basic block layout on LLVM backend by predicting stack/heap checks ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (LLVM) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently we don't give the LLVM optimizer any information about which branch of an `if` is likely to be taken. As a result, the optimizer is likely to produce a basic block layout which is not optimal. Improving the layout can improve performance through better instruction cache usage and better branch prediction by the hardware. We can control LLVM's idea of what is likely with the `llvm.expect` intrinsic function. Some obvious branches which we can predict accurately are the stack and heap checks that appear near the entry of many functions. Here's a small example of some Cmm code and the output of the LLVM optimizer/compiler. {{{ block_c2Lc_entry() // [R1, R2] { info_tbl: [(c2Lc, label: block_c2Lc_info rep:StackRep [])] stack_info: arg_space: 0 updfr_space: Nothing } {offset c2Lc: Hp = Hp + 24; if (Hp > HpLim) goto c2Lm; else goto c2Ll; c2Lm: HpAlloc = 24; R2 = R2; R1 = R1; call stg_gc_pp(R2, R1) args: 8, res: 8, upd: 24; c2Ll: I64[Hp - 16] = :_con_info; P64[Hp - 8] = R1; P64[Hp] = R2; R1 = Hp - 14; Sp = Sp + 8; call (P64[Sp])(R1) args: 24, res: 0, upd: 24; } }] }}} {{{ 00000000000002b8 <c2Lc_info>: 2b8: 4c 89 e0 mov %r12,%rax 2bb: 4c 8d 60 18 lea 0x18(%rax),%r12 2bf: 4d 3b a5 18 01 00 00 cmp 0x118(%r13),%r12 2c6: 76 10 jbe 2d8 <c2Lc_info+0x20> 2c8: 49 c7 85 48 01 00 00 movq $0x18,0x148(%r13) 2cf: 18 00 00 00 2d3: e9 00 00 00 00 jmpq 2d8 <c2Lc_info+0x20> 2d4: R_X86_64_PC32 stg_gc_pp+0xfffffffffffffffc 2d8: 48 c7 40 08 00 00 00 movq $0x0,0x8(%rax) 2df: 00 2dc: R_X86_64_32S ghczmprim_GHCziTypes_ZC_con_info 2e0: 48 89 58 10 mov %rbx,0x10(%rax) 2e4: 4c 89 70 18 mov %r14,0x18(%rax) 2e8: 48 8b 45 08 mov 0x8(%rbp),%rax 2ec: 48 83 c5 08 add $0x8,%rbp 2f0: 49 8d 5c 24 f2 lea -0xe(%r12),%rbx 2f5: ff e0 jmpq *%rax 2f7: 90 nop }}} It would likely be better to invert the branch at `2c6` to a `ja`, so that the common case is adjacent to the function entry, and when `llvm.expect` is used on the condition in the branch, the LLVM optimizer does produce this alternate layout. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8321> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing.
by GHC 16 Nov '16

16 Nov '16

#9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. -------------------------------------------+------------------------------- Reporter: Dingus | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: crash, control-c | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- This is printed: (without the quotes at the beginning or end) " ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug " I am able to reproduce it by: 1. starting ghci (with no arguments, or a file as an argument) 2. holding down contol-c for 2 seconds 3. holding down spacebar/a letter key for 2 seconds The timing varies. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11832: Allow reify to yield types in the current declaration group
by GHC 16 Nov '16

16 Nov '16

#11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: template- | Operating System: Unknown/Multiple haskell reify | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: | TemplateHaskell/Reify -------------------------------------+------------------------------------- Here is the motivation TemplateHaskell/Reify. It would be useful to have a way to obtain types of identifiers in the current declaration group in splices. However, {{{reify}}} is defined to provide information about identifiers in previous declaration groups only. It would be fine to allow {{{reify}}} to work in a scheme combined with {{{addModFinalizer}}} or similar so it is executed when the types are known. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11832> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22