- ghc-tickets - Haskell.org

[GHC] #14931: Segfault compiling files with -fprof-all
by GHC 25 Mar '18

25 Mar '18

#14931: Segfault compiling files with -fprof-all -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.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: -------------------------------------+------------------------------------- Originally noticed [https://github.com/llvm-hs/llvm- hs/issues/86#issuecomment-373710312 here]. Take the following two files: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE UndecidableInstances #-} module State (MonadState(..), Lazy.evalState) where import qualified Control.Monad.Trans.State.Lazy as Lazy (StateT, get, put, evalState) class Monad m => MonadState s m | m -> s where get :: m s put :: s -> m () instance Monad m => MonadState s (Lazy.StateT s m) where get = Lazy.get put = Lazy.put }}} {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Prelude (Int, IO, Bool(..), Num(..), Monad(..), not, print) import qualified Language.Haskell.TH.Syntax as TH import State wat :: IO () wat = print $(let playGame [] = do (_, score) <- get return score playGame (x:xs) = do (on, score) <- get case x of 'a' | on -> put (on, score + 1) 'b' | on -> put (on, score - 1) 'c' -> put (not on, score) _ -> put (on, score) playGame xs startState :: (Bool, Int) startState = (False, 0) in TH.lift (evalState (playGame "abcaaacbbcabbab") startState) ) }}} Compiling them like so leads to a segfault: {{{ $ ~/Software/ghc-8.4.1/bin/ghc -c -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi State.hs $ ~/Software/ghc-8.4.1/bin/ghc -c -O -prof -osuf p_o -hisuf p_hi State.hs -fprof-auto $ ~/Software/ghc-8.4.1/bin/ghc -c -O -prof -osuf p_o -hisuf p_hi Bug.hs Segmentation fault (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14931> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration
by GHC 23 Mar '18

23 Mar '18

#13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10607 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, if you try to use a wildcard anywhere in an instance context, it will fail immediately: {{{ $ ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> instance _ => Show (Maybe a) <interactive>:1:10: error: Wildcard ‘_’ not allowed in an instance declaration for ‘Show’ }}} But there's one situation where we could lift this restriction: the context of a standalone, derived instance declaration. That is, something like this: {{{#!hs deriving instance _ => Show (Maybe a) }}} Why? Because GHC already has the machinery needed to infer what the context should be (see [http://git.haskell.org/ghc.git/blob/8a6b8c5fb96472d7c2e2cd1918950dd50f2fef7… this part] of `TcDerivInfer`), so if a user turned on `PartialTypeSignatures`, GHC could just fill in the wildcard with the inferred constraints. The implementation won't be //that// easy, however, since we'd also have to watch out for trickery such as: {{{#!hs deriving instance (C a, _) => C (T a b c) }}} I only mentioned putting wildcards in a derived instance //context//, because I think allowing the use of wildcards elsewhere in the instance head might be too difficult to deal with. I mean, how would you fill in this, for example? {{{#!hs instance (_ a) }}} This mini-feature has a very practical application: it would allow users to wield the flexibility of `StandaloneDeriving` without having to manually type in the instance context every time. That is, users could type in these instances: {{{#!hs deriving instance _ => Data (T a b c) deriving instance _ => Eq (T a b c) }}} Instead of their fully spelled-out, more laborious counterparts. This would be crucial for Template Haskell, as its ability to infer these contexts is quite limited (see #10607 for an example where this cropped up). Idle thought: could this be generalized to work for the instance context of //any// instance declaration (and not just derived ones)? From an outside perspective, it seems like typechecking other instances would require inferring constraints in a fashion quite similar to that of derived instances. But I am not at all familiar with that part of the typechecker, so I might be totally off here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #5041: Incorrect Read deriving for MagicHash constructors
by GHC 23 Mar '18

23 Mar '18

#5041: Incorrect Read deriving for MagicHash constructors -------------------------------------+------------------------------------- Reporter: dolio | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.0.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_run/T5041 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott <ryan.gl.scott@…>): In [changeset:"d5577f44eaf3b9dfdfc77828038782bf818c176a/ghc" d5577f44/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d5577f44eaf3b9dfdfc77828038782bf818c176a" Special-case record fields ending with hash when deriving Read Summary: In commit dbd81f7e86514498218572b9d978373b1699cc5b, a regression was inadvertently introduced which caused derived `Read` instances for record data types with fields ending in a `#` symbol (using `MagicHash`) would no longer parse on valid output. This is ultimately due to the same reasons as #5041, as we cannot parse a field name like `foo#` as a single identifier. We fix this issue by employing the same workaround as in #5041: first parse the identifier name `foo`, then then symbol `#`. This is accomplished by the new `readFieldHash` function in `GHC.Read`. This will likely warrant a `base-4.11.1.0` release. Test Plan: make test TEST=T14918 Reviewers: tdammers, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14918 Differential Revision: https://phabricator.haskell.org/D4502 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5041#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14966: Symbols in -ddump-asm output don't match real output
by GHC 23 Mar '18

23 Mar '18

#14966: Symbols in -ddump-asm output don't match real output -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (NCG) | 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: -------------------------------------+------------------------------------- Symbols in the .s files generated by NCG are properly Z-encoded, but they aren't in the -ddump-asm output. One trivial example: {{{ {-# OPTIONS_GHC -ddump-to-file -ddump-asm -keep-s-files #-} module Fact where fact :: Int -> Int fact 0 = 1 fact n = n * fact (n - 1) }}} The contents of Fact.s: {{{ .section .rdata .align 1 .align 1 r23Y_bytes: .asciz "main" .section .data .align 8 .align 1 r24i_closure: .quad ghczmprim_GHCziTypes_TrNameS_con_info .quad r23Y_bytes ... }}} The contents of Fact.dump-asm: {{{ ==================== Asm code ==================== 2018-03-23 14:00:27.8082773 UTC .section .rdata .align 1 .align 1 $trModule1_r23Y_bytes: .asciz "main" ==================== Asm code ==================== 2018-03-23 14:00:27.8172758 UTC .section .data .align 8 .align 1 $trModule2_r24i_closure: .quad GHC.Types.TrNameS_con_info .quad $trModule1_r23Y_bytes ... }}} This is confirmed on multiple GHC versions, up to 8.5. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14966> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14901: dsrun004 fails with most ways
by GHC 23 Mar '18

23 Mar '18

#14901: dsrun004 fails with most ways -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: dsrun004 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `dsrun004` test doesn't seem to pass for a whole bunch of ways, as a recent `./validate --slow` (against yesterday's master) revealed. {{{#!py # the test options test('dsrun014', normal, compile_and_run, ['-fobject-code']) }}} {{{#!hs -- the haskell program we build & run {-# LANGUAGE UnboxedTuples #-} module Main where import Debug.Trace {-# NOINLINE f #-} f :: a -> b -> (# a,b #) f x y = x `seq` y `seq` (# x,y #) g :: Int -> Int -> Int g v w = case f v w of (# a,b #) -> a+b main = print (g (trace "one" 1) (trace "two" 2)) -- The args should be evaluated in the right order! }}} {{{ # the failing ways /tmp/ghctest-n4fi8zlk/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (hpc) /tmp/ghctest-n4fi8zlk/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (optasm) /tmp/ghctest-n4fi8zlk/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (threaded2) /tmp/ghctest-n4fi8zlk/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (dyn) /tmp/ghctest-n4fi8zlk/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (optllvm) }}} With those 5 ways, the program's trace is `two` then `one` while with some other ways (like ghci or normal) we get (as expected by the testsuite) `one` first and `two` afterwards. I'm not sure whether the expectation is too strong or whether there's something fishy going on with those 5 ways. Simon, could you perhaps comment on this? Is this a "proper" bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14948: A program which benefits from a late specialisation pass
by GHC 23 Mar '18

23 Mar '18

#14948: A program which benefits from a late specialisation pass -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- In this repo there is a small program which performs much better with a late specialisation pass. There is a plugin which implements this pass. Instructions about how to build the repo are in the README. https://github.com/mpickering/legendary-train Without plugin {{{ time benchmarks () real 0m0.112s }}} With plugin (comparable to hand-written code) {{{ time benchmarks () real 0m0.049s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14948> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14942: QuantifiedConstraints: GHC can't infer
by GHC 22 Mar '18

22 Mar '18

#14942: QuantifiedConstraints: GHC can't infer -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This works {{{#!hs {-# Language QuantifiedConstraints, GADTs, KindSignatures, RankNTypes, ConstraintKinds #-} import Data.Kind newtype Free :: (Type -> Constraint) -> (Type -> Type) where Free :: (forall x. cls x => (a -> x) -> x) -> Free cls a var :: a -> Free cls a var a = Free $ \var -> var a oneTwo :: (forall x. semi x => Semigroup x) => Free semi Int oneTwo = Free $ \var -> var 1 <> var 2 nil :: (forall x. mon x => Monoid x) => Free mon Int nil = Free $ \var -> mempty together :: (forall x. mon x => Monoid x) => [Free mon Int] together = [var 0, nil, oneTwo] }}} If we comment out `together`'s type signature GHC cannot infer it back, shouldn't it be able to though? {{{ $ ./ghc-stage2 --interactive -ignore-dot-ghci Proposal.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Proposal.hs, interpreted ) Proposal.hs:21:20: error: • Could not deduce (Monoid x) arising from a use of ‘nil’ from the context: cls x bound by a quantified context at Proposal.hs:21:1-31 Possible fix: add (Monoid x) to the context of a quantified context • In the expression: nil In the expression: [var 0, nil, oneTwo] In an equation for ‘together’: together = [var 0, nil, oneTwo] | 21 | together = [var 0, nil, oneTwo] | ^^^ Proposal.hs:21:25: error: • Could not deduce (Semigroup x) arising from a use of ‘oneTwo’ from the context: cls x bound by a quantified context at Proposal.hs:21:1-31 Possible fix: add (Semigroup x) to the context of a quantified context • In the expression: oneTwo In the expression: [var 0, nil, oneTwo] In an equation for ‘together’: together = [var 0, nil, oneTwo] | 21 | together = [var 0, nil, oneTwo] | ^^^^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14942> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14962: "ghc: Out of memory" upon compiling combination of map/foldl/setBit
by GHC 22 Mar '18

22 Mar '18

#14962: "ghc: Out of memory" upon compiling combination of map/foldl/setBit -------------------------------------+------------------------------------- Reporter: | Owner: (none) martijnbastiaan | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code snippet: {{{#!hs module Test where import Data.Bits (setBit) import Data.List f :: Integer f = foldl setBit 0 toSet where toSet = [n | (n, _) <- zip [0..] [1]] }}} Fails to compile, yielding: {{{ martijn@qbltop:~/code/scratch$ ghc Test.hs -O1 [1 of 1] Compiling Test ( Test.hs, Test.o ) ghc: Out of memory }}} A few observations: - Compiling with no optimizations (-O0) works fine - I have not found a function other than setBit which triggers this behavior - Changing foldl to its strict brother foldl' does not help - Changing the type signature of "f" from "Integer" to "Int" causes the code to compile just fine I have been unable to reduce this example any further. I am using GHC 8.2.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #94: Bad space behaviour with huge input file
by GHC 22 Mar '18

22 Mar '18

#94: Bad space behaviour with huge input file --------------------------------+--------------------- Reporter: ajk | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.04 Resolution: Rejected | Keywords: Type of failure: None/Unknown | --------------------------------+--------------------- Changes (by Simon Peyton Jones <simonpj@…>): * failure: => None/Unknown Comment: In [changeset:"411a97e2c0083529b4259d0cad8f453bae110dee/ghc" 411a97e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="411a97e2c0083529b4259d0cad8f453bae110dee" Allow as-patterns in unidirectional patttern synonyms This patch implements GHC Proposal #94, described here https://github.com/ghc-proposals/ghc-proposals/pull/94 The effect is simply to lift a totally-undocumented restriction to unidirecional pattern synonyms, namely that they can't have as-patterns or n+k patterns. The fix is easy: just remove the checks. I also took the opportunity to improve the manual entry for the semantics of pattern matching for pattern synonyms. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/94#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14731: Document alignment invariants for array types in GHC.Prim
by GHC 21 Mar '18

21 Mar '18

#14731: Document alignment invariants for array types in GHC.Prim -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #2917 #9806 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Through a combination of reading some of the wiki entries on the RTS, some trac tickets, and experimentation I've inferred that the payloads for bytearray types will always be aligned to the machine word size, even after GC. I guess this is obvious in retrospect since otherwise non-pinned arrays would be pretty useless. I'm not sure what the promises are for all the `Foreign` stuff. It can be frustrating to use `GHC.Prim` in particular due to this sort of lack of commitment in the docs, and these compound. Usually I end up trying to find an example in `text` or `bytestring` that would be horribly broken if some undocumented behavior changed, and hang my hat on that with a sad comment in the code I'm writing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5