- ghc-tickets - Haskell.org

[GHC] #14712: After git pull make can't work with make clean
by GHC 26 Jan '18

26 Jan '18

#14712: After git pull make can't work with make clean -------------------------------------+------------------------------------- Reporter: jiamo | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 8.5 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the clean master repo: configure make can work. But after git pull. Just run make. It always failed. After make clean. it can success. But it will take long time as in the clean repo. (It is not bug I can find other type to desc) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14712> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13352: Strange requirement for re-exported duplicate record fields
by GHC 26 Jan '18

26 Jan '18

#13352: Strange requirement for re-exported duplicate record fields -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- In the following example, {{{ module A(A(..)) where data A = A {x::Int} module B(B(..)) where data B = B {x::Bool} {-# LANGUAGE DuplicateRecordFields #-} module C(A(..),B(..)) where import A(A(..)) import B(B(..)) }}} I get an error about `conflicting exports for 'x'`. This doesn't seem right to me: I've got `-XDuplicateRecordFields` exactly where the duplicate occurs. However, I noticed that the if I move the pragma to A.hs, C.hs compiles without error: {{{ {-# LANGUAGE DuplicateRecordFields #-} module A(A(..)) where data A = A {x::Int} module B(B(..)) where data B = B {x::Bool} module C(A(..),B(..)) where import A(A(..)) import B(B(..)) }}} This is bizarre because it is asymmetric (I arbitrarily put the pragma in A.hs, but it need not occur in B.hs), and because no duplicate records exist in module A, but they ''do'' exist in module C, where the pragma isn't needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13352> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14721: internal error: stg_ap_v_ret
by GHC 25 Jan '18

25 Jan '18

#14721: internal error: stg_ap_v_ret --------------------------------------+--------------------------------- Reporter: jdm12 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I got the following message when trying to inspect an unboxed vector: <interactive>: internal error: stg_ap_v_ret (GHC version 8.0.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) ... so here I am, following instructions :) I'm running Kubuntu Zesty (4.13.0-25-generic) in a VirtualBox vm on a Win10 host. I don't know what other info will help, but I'll save the code as it stands and provide details on request. If the core dump will be useful, I'm happy to provide, but will need help finding it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14718: Add Boolean type families to 'base' package
by GHC 25 Jan '18

25 Jan '18

#14718: Add Boolean type families to 'base' package -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.5 Libraries | Keywords: base, type | Operating System: Unknown/Multiple families, Bool | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sometimes you want type families to perform type level computation with booleans. Specifically: {{{#!hs type family If (p :: Bool) (ifTrue :: k) (ifFalse :: k) :: k where ... type family (a :: Bool) && (b :: Bool) :: Bool where ... type family (a :: Bool) || (b :: Bool) :: Bool where ... type family Not (a :: Bool) :: Bool where }}} Similar to existing module [https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Bool.html Data.Bool] in `base` package for boolean expressions. There's not a single package with such type families for type-level boolean computations. Even if it exists it probably would very small. And as a library author you probably don't wan extra dependencies for your package because cost of adding new dependency for your project is much bigger than cost of adding module to existing dependencies (if it's possible of course). It seems to me that such operations are kinda basic. And they just promote behavior of already existed expression-level functions to type level. And we already have type families for `Integer`, `Natural` and `String` (aka `Symbol`) and several type families returning `Bool` (`==`, `<=?`) in `base`. So I propose to add couple useful utilities to operate with `Bool` explicitly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14688: Note [Lone variables] leads to missing a case-of-case opportunity
by GHC 25 Jan '18

25 Jan '18

#14688: Note [Lone variables] leads to missing a case-of-case opportunity -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- After the simplifier, my program ends up in the following state. {{{ foo = \f s -> let x = case s of { T1 a b -> a :> b :> Nil } in fmap (\v -> case x of { _v1 :> vs -> T1 v (case vs of {v2 :> _ -> v2}) }) (f (case x of {v1 :> _ -> v1})) }}} Now if I understand `Note [Lone variables]` correctly, `x` is NOT inlined into the call sites, no matter what I do as `x` is work-free. However, this is bad as if we were to inline `x` we get a case-of-case opportunity. {{{ => Inline foo = \f s -> let x = case s of { T1 a b -> a :> b :> Nil } in fmap (\v -> case (case s of { T1 a b -> a :> b :> Nil }) of { _v1 :> vs -> T1 v (case vs of {v2 :> _ -> v2}) }) (f (case x of {v1 :> _ -> v1})) => case of case foo = \f s -> let x = case s of { T1 a b -> a :> b :> Nil } in fmap (\v -> case s of { T1 a b -> case (a :> b :> Nil) of { _v1 :> vs -> T1 v (case vs of {v2 :> _ -> v2}) }) (f (case x of {v1 :> _ -> v1})) => case of known constructor foo = \f s -> let x = case s of { T1 a b -> a :> b :> Nil } in fmap (\v -> case s of { T1 a b -> T1 v b}) (f (case x of {v1 :> _ -> v1})) => Same for the other branch foo = \f s -> fmap (\v -> case s of { T1 a b -> T1 v b}) (case s of T1 a b -> a) }}} Which no longer mentions the intermediate representation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7414: plugins always trigger recompilation
by GHC 25 Jan '18

25 Jan '18

#7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => high * milestone: => 8.6.1 Comment: Is there anything blocking this ticket or does someone just need to implement it? It makes using plugins quite a bit more hassle than necessary. See also #12567 I really think this should be a priority for the next release (8.6) Ben said in an email thread last year that these should be the steps. But, if the implementation is slightly broken, implementing anything will be better than the current situation I posit! We can get back to the current situation by using `-fforce-recomp` after all. {{{ I think the real question is what sort of interface do plugin authors need? I suspect there are a few distinct tasks here, * compute and record module implementation hashes in interface files * to include plugin implementation hashes in the recompilation check * to provide an interface allowing a plugin to compute a hash of its arguments which can be included into the recompilation check. One way of realising this would be to add a field like the following to Plugin, pluginHash :: [CommandLineOption] -> Maybe Fingerprint -- Nothing would denote "always rebuild" Would this help in your case? This would allow us to fix the TH problem in #7277 and fix the plugins problem in #7414 and #12567 in a nearly optimal way (assuming the plugin author is able to precisely define a hash). None of this is terribly difficult and given Nick's recent work on his row types plugin, it seems like it's getting more urgent. Cheers, - Ben }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7414#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5793: make nofib awesome
by GHC 24 Jan '18

24 Jan '18

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): > Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful. Windows suffers especially from this as the cpuTime measurement has less accuracy there. See #14714 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14714: RTS Timings on windows are somewhat unreliable
by GHC 24 Jan '18

24 Jan '18

#14714: RTS Timings on windows are somewhat unreliable -------------------------------------+------------------------------------- Reporter: AndreasK | 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: -------------------------------------+------------------------------------- Times given by the RTS are very unreliable on small scales. Part of that is I assume simply the lack of precision. But CPU Time often is reported higher than wall clock time (using the single threaded RTS) as well. Examples: {{{ $ ./binary-trees 12 +RTS -t stretch tree of depth 13 check: -1 ... long lived tree of depth 12 check: -1 <<ghc: 43098232 bytes, 42 GCs, 345148/647488 avg/max bytes residency (2 samples), 3M in use, 0.000 INIT (0.000 elapsed), 0.016 MUT (0.009 elapsed), 0.000 GC (0.003 elapsed) :ghc>> $ ./binary-trees 12 +RTS -t stretch tree of depth 13 check: -1 8192 trees of depth 4 check: -8192 ... 32 trees of depth 12 check: -32 long lived tree of depth 12 check: -1 <<ghc: 43098232 bytes, 42 GCs, 345148/647488 avg/max bytes residency (2 samples), 3M in use, 0.000 INIT (0.000 elapsed), 0.000 MUT (0.010 elapsed), 0.016 GC (0.003 elapsed) :ghc>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14504: Nofib is broken on Windows
by GHC 24 Jan '18

24 Jan '18

#14504: Nofib is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib | Version: 8.2.1 benchmark suite | 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: -------------------------------------+------------------------------------- It seems like nofib is currently broken on Windows. Specifically, it fails for me with {{{ ... /home/ben/ghc/inplace/bin/ghc-stage2 -M -dep-suffix "" -dep-makefile .depend -osuf o -O2 -Rghc-timing -H32m -hisuf hi -rtsopts -XBangPatterns -O2 Main.hs <<ghc: 21000792 bytes, 9 GCs, 781824/1421072 avg/max bytes residency (2 samples), 26M in use, 0.000 INIT (0.000 elapsed), 0.031 MUT (0.037 elapsed), 0.016 GC (0.022 elapsed) :ghc>> Finished making boot in fannkuch-redux: 0 ------------------------------------------------------------------------ == make boot --no-print-directory; in /home/ben/ghc/nofib/shootout/fasta ------------------------------------------------------------------------ $topdir/../mingw/bin/gcc.exe -std=gnu99 -O3 -fomit-frame-pointer fasta-c.c -o fasta-c /bin/sh: /../mingw/bin/gcc.exe: No such file or directory }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14646: GHC 8.4.1 regression: rank-n types no longer parenthesized when pretty-printed
by GHC 24 Jan '18

24 Jan '18

#14646: GHC 8.4.1 regression: rank-n types no longer parenthesized when pretty- printed -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Take this file: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Language.Haskell.TH $([d| f :: (forall a. a) -> Int f _ = undefined |]) }}} In GHC 8.2.2, `-ddump-splices` behaves as you'd expect: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(8,3)-(9,24): Splicing declarations [d| f_a1zL :: (forall a_a1zM. a_a1zM) -> Int f_a1zL _ = undefined |] ======> f_a49Z :: (forall a_a4a0. a_a4a0) -> Int f_a49Z _ = undefined Ok, one module loaded. }}} But in GHC 8.4.1-alpha (and HEAD), the GHC pretty-printer incorrectly leaves off the parentheses around the type `(forall a. a)`: {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20171222: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(8,3)-(9,24): Splicing declarations [d| f_a1EF :: (forall a_a1EG. a_a1EG) -> Int f_a1EF _ = undefined |] ======> f_a4ap :: forall a_a4aq. a_a4aq -> Int f_a4ap _ = undefined Ok, one module loaded. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11