March 2018 - ghc-tickets

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 22 Mar '18

22 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

[GHC] #14960: Invalid law for MonadPlus: v >> mzero = mzero
by GHC 21 Mar '18

21 Mar '18

#14960: Invalid law for MonadPlus: v >> mzero = mzero -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: laws, mzero | 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 of `MonadPlus` states: `v >> mzero = mzero`. This law is broken by `IO`, `MaybeT`, and a few other monads with some notion of "irreversible effects". I propose to just remove that law. https://hackage.haskell.org/package/base-4.11.0.0/docs/Control- Monad.html#t:MonadPlus Another alternative is to keep it but remove unlawful instances, so `MonadPlus` instances can signal that those laws hold, on top of the `Alternative` instances. But that breaks backwards compatibility, because `MonadPlus` for `IO` and `MaybeT` is already used in many places. This thread previously brought up the issue but hasn't been followed up: https://mail.haskell.org/pipermail/libraries/2014-January/021993.html, continued on https://mail.haskell.org/pipermail/libraries/2014-February/022004.html with some interesting discussion about what those laws should be. This even older thread also discusses `MonadPlus` laws, hence it also seems relevant to improve the documentation: https://mail.haskell.org/pipermail/haskell-cafe/2005-January/008751.html. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14954: Passing -fno-code disables reporting of some warnings
by GHC 21 Mar '18

21 Mar '18

#14954: Passing -fno-code disables reporting of some warnings -------------------------------------+------------------------------------- Reporter: mrkkrp | 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: -------------------------------------+------------------------------------- Here is how to reproduce the issue with GHC 8.2.2: {{{ $ cat Main.hs module Main (main) where main = case (1+1) :: Int of 1 -> return () $ ghc -Wall -Werror -fno-code Main.hs [1 of 1] Compiling Main ( Main.hs, nothing ) Main.hs:3:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: main :: IO () | 3 | main = | ^^^^ <no location info>: error: Failing due to -Werror. $ ghc -Wall -Werror Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:3:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: main :: IO () | 3 | main = | ^^^^ Main.hs:4:3: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: p where p is not one of {1} | 4 | case (1+1) :: Int of | ^^^^^^^^^^^^^^^^^^^^... <no location info>: error: Failing due to -Werror. }}} Note that `missing-signature` is reported both times, but the `incomplete- patterns` is not reported with `-fno-code`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14954> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2