February 2019 - ghc-tickets

[GHC] #14533: Make GHC more robust against PC crashes by using atomic writes
by GHC 10 Mar '19

10 Mar '19

#14533: Make GHC more robust against PC crashes by using atomic writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Yesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well). That made me think if we should change ghc to write its output with atomic moves. Discussion on `#ghc`: {{{ bgamari: nh2: well, perhaps I'm not sure it's terribly common for compilers to take such precautions though and if we were to do it for interface files then presumably we would also want to do it for object files siarheit_: that would be very nice geekosaur: compilers in general are happy to write out incomplete/garbage object files bgamari: it seems that way nh2: bgamari: right, if we wanted to do it we should do it for all files ghc writes. Possible that other compilers can also write garbage, but maybe ghc can do better -- one less thing the developer has to think about Phyx-: most compilers also don't do the aggressive recompilation avoidance things we do either.. corrupt hi files wouldn't be an issue if the next time it would override them :) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13839: GHC warnings do not respect the default module header
by GHC 09 Mar '19

09 Mar '19

#13839: GHC warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) 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: -------------------------------------+------------------------------------- If I compile this program with `-Wall`, I get no warnings: {{{#!hs type T = Int main :: IO () main = return () }}} If I add a module header: {{{#!hs module Main(main) where type T = Int main :: IO () main = return () }}} I now get a warning: {{{ ghcbug2.hs:3:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘T’ }}} Yet, according to Haskell2010 (section 5.1): > An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be ‘module Main(main) where’. Therefore, the right behaviour should be to print a warning in the first case as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14741: High-memory usage during compilation using Template Haskell
by GHC 09 Mar '19

09 Mar '19

#14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- When trying to embed some files into an executable using Template Haskell, I find that memory usage during compilation exceeds 4GB and often crashes my laptop. The files I am trying to embed are only about 25MB in size (totally 35MB in size). I made a somewhat minimal example to demonstrate this problem. To embed the files, I am using the [https://hackage.haskell.org/package/file-embed `file-embed`] package (the issue persists when using the alternative [https://hackage.haskell.org/package/wai-app-static `wai-app-static`] package too. The code to demonstrate runs in Linux and is available here - https://github.com/donatello/file-embed-exp. To try it out, just clone the repository and run Make (it uses the Haskell Stack tool and the Linux dd utility). This appear to be an issue in GHC. Is there anyway to mitigate the issue in the current version? Related discussion: https://github.com/snoyberg/file-embed/issues/24 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #16325: Hadrian should respect the build root setting for the testsuite and its own binaries
by GHC 09 Mar '19

09 Mar '19

#16325: Hadrian should respect the build root setting for the testsuite and its own binaries -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | 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: -------------------------------------+------------------------------------- Currently the `--build-root` setting is respected only partially: * The `test` rule appears to be placing all testsuite build artefacts right in the GHC tree `./testsuite`. * Hadrian puts its own binaries also in the GHC tree, into the `./hadrian/X` directory, where `X` depends on whether we build with Cabal or Stack. We should improve on this and provide more guarantees about where all build artefacts go. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10069: CPR related performance issue
by GHC 09 Mar '19

09 Mar '19

#10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- By default CRP analysis can be too aggressive in trying to pass as much as possible in unboxed tuples, in general it's not a problem but when one big datatype is passed to several consumers it might end up pushed to stack several times instead of once - to heap, things are getting worse when there are sufficient fields to cause stack overflow which otherwise is possible to avoid - in our codebase adding one field with ExistentialQuantification (unused, but that prevents ghc from doing CRP transformation) reduces number of stack overflow by a factor of 1000 and increases overall performance by 10%. In provided example performance for both A and B should be identical and yet B is consistently faster by 3-5% It's possible to increase this performance gap by adding more and more fields. I was able to replicate this issue in ghc 7.8.3 and 7.10,1rc2 {{{#!hs {-# LANGUAGE ExistentialQuantification #-} module Blah where import Criterion import Criterion.Main import Data.Typeable data A = A () !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int data B = forall rep. (Typeable rep) => B rep !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int a :: A a = A () 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 b :: B b = B () 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 {-# NOINLINE a1 #-} a1 :: A -> Int a1 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f1 {-# NOINLINE a2 #-} a2 :: A -> Int a2 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f2 {-# NOINLINE a3 #-} a3 :: A -> Int a3 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f3 {-# NOINLINE a4 #-} a4 :: A -> Int a4 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f4 {-# NOINLINE b1 #-} b1 :: B -> Int b1 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f1 {-# NOINLINE b2 #-} b2 :: B -> Int b2 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f2 {-# NOINLINE b3 #-} b3 :: B -> Int b3 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f3 {-# NOINLINE b4 #-} b4 :: B -> Int b4 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f4 {-# NOINLINE fa #-} fa :: A -> Int fa a = a1 a + a2 a + a3 a + a4 a {-# NOINLINE fb #-} fb :: B -> Int fb b = b1 b + b2 b + b3 b + b4 b main :: IO () main = defaultMain [ bgroup "single call" [ bench "A" $ whnf fa a , bench "B" $ whnf fb b ] ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #16164: Provide bitreverse primop
by GHC 09 Mar '19

09 Mar '19

#16164: Provide bitreverse primop -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- We already have nice primops like {{{byteSwap#}}}, it'd be nice to also have {{{bitreverse}}}. Clang provides {{{__builtin_bitreverse}}} (http://clang.llvm.org/docs/LanguageExtensions.html#builtin-bitreverse) functions which could be the default. GCC currently doesn't have a built- in (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481) One prominent place where this primop could be used is Data.IntSet.Internal where it's implemented as a {{{revNat}}}. Many other libraries also define own versions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore)
by GHC 08 Mar '19

08 Mar '19

#11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Allow intermediate code inline. == Inline ''Core'' == Typeable/WithTypeable: > {{{#!hs > withTypeable :: TTypeRep a -> (Typeable a => r) -> r > }}} > > Currently, `withTypeable` cannot be written in Haskell, but it is straightforward to write in Core. Can we fix this? [http://www.seas.upenn.edu/~sweirich/papers/wadlerfest2016.pdf A reflection on types] (''2016''): > We cannot implement ''withTypeable'' in Haskell source. But we ''can'' implement it in GHC's statically-typed intermediate language, System FC. The definition is simple, roughly like this: > > {{{#!hs > withTypeable tr k = k tr -- Not quite right > }}} > > Its second argument ''k'' expects a ''Typeable'' dictionary as its value argument. But since > a ''Typeable'' dictionary is represented by a ''TypeRep'', we can simply pass ''tr'' to ''k''. > When written in System FC there is a type-safe coercion to move from ''TypeRep a'' to ''Typeable a'', > but that coercion is erased at runtime. Since the definition can be statically type checked, > ''withTypeable'' does not form part of the trusted code base. == Inline ''Cmm'' == Edkward Kmett writes his own `.cmm` [https://github.com/ekmett/concurrent/blob/master/cbits/hashmap.cmm hither], [https://github.com/ekmett/concurrent/blob/master/cbits/array.cmm yon]. == Inline ''Strict Core'' == Should [http://research.microsoft.com/en-us/um/people/simonpj/papers /strict-core/tacc-hs09.pdf Types are calling conventions] (''2009'') be implemented: > === '''4.4 The ''`seq`'' function''' === > > A nice feature of Strict Core,,ANF,, is that it is possible to give a straightforward definition of the primitive ''seq'' function of Haskell: > {{{#!hs > seq : {a:* -> b:* -> {a} -> {b} -> b} > = { \a:*. \b:*. \x:{a}. \y:{b}. let _:a = x <> in y <> } > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11315: GHC doesn't restore split objects
by GHC 08 Mar '19

08 Mar '19

#11315: GHC doesn't restore split objects -------------------------------------+------------------------------------- Reporter: snowleopard | 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: -------------------------------------+------------------------------------- While working on the new Shake-based build system I came across an annoying problem related to missing split objects ([#note see note]). I still don't fully understand the reasons behind the problem, but I found that GHC doesn't restore missing split objects, as explained in the example below. I think this is a bug, but maybe this is actually a missing feature. I think it shouldn't be difficult to fix. {{{#!hs module Test (test) where test :: Int test = 0 }}} I compile the above with `ghc -split-objs Test.hs` and get two split object files in `Test_o_split`. Then if I delete any of these files, or even the whole folder, and rerun `ghc -split-objs Test.hs` the compiler doesn't bother to restore split objects, pretending that everything is up- to-date. However, if I delete `Test.o` all object files are restored. Another related issue reported by Neil Mitchell (which may be worth a separate ticket) is that even if we corrupt `Test.o` and rerun `ghc -split-objs Test.hs`, the compiler doesn't restore the object file (nor missing split objects) to the consistent state. ---- [=#note Note:] The problem I have is described here: https://github.com/snowleopard/shaking-up-ghc/issues/30. It's not necessary to follow the link to understand this ticket, however I'd appreciate any insight you might have about the reasons behind the problem and/or a possible solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11315> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9832: Get rid of PERL dependency of `ghc-split`
by GHC 08 Mar '19

08 Mar '19

#9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (writeme) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9832> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm
by GHC 08 Mar '19

08 Mar '19

#8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- ...since the pretty-printer attempts to force the blocks list of the split_marker_entry proc. I'm not really sure what the right way to fix this is: just provide an empty block list, or hack the pretty-printer to treat split markers specially. But should be easy to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5