- ghc-tickets - Haskell.org

[GHC] #14830: Use test instead of cmp for comparison against zero.
by GHC 20 Oct '18

20 Oct '18

#14830: Use test instead of cmp for comparison against zero. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: (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: -------------------------------------+------------------------------------- For comparisons `test r, r` and `cmp r, $0` are interchangeable at least on x86. However using test leads to slightly smaller code. (Saves a byte per comparison). A good starting point is stmtToInstrs in compiler/nativeGen/X86/CodeGen starting with how CmmCondBranch is compiled to Instructions. From there it should be not too hard to track down the required changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15757: Coercion Variable Almost Devoid Checking in ForAllCo
by GHC 19 Oct '18

19 Oct '18

#15757: Coercion Variable Almost Devoid Checking in ForAllCo -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15497 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1074&context=co… Richard's thesis] Section 5.8.5.2, there is a restriction on where a coercion variable can appear in `ForAllCo` for the sake of consistency: the coercion variable can appear nowhere except in coherence coercions. Currently this restriction is missing in coercion quantification (see #15497). The goal of this ticket is to add the missing restriction. After discussion with Richard, we restate the restriction a little bit: the coercion variable can appear nowhere except in `GRefl` and `Refl`. Allowing it to appear in `Refl` should not break consistency. Notice that this also means `liftCoSubst` might fail when it lifts a `ForAllTy` over a coercion variable to a `ForAllCo`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15757> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15775: Interpreter is treating a comment character as an identifier character.
by GHC 19 Oct '18

19 Oct '18

#15775: Interpreter is treating a comment character as an identifier character. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.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: -------------------------------------+------------------------------------- When bringing dhall-lang up in a REPL I stumbled across a warning about a character in a haddock comment. Should the interpreter be treating a comment character as an identifier character? https://github.com/dhall-lang/dhall- haskell/issues/646#issuecomment-430776320 {{{#!hs {-# LANGUAGE CPP #-} data Expr s a -- | > Combine x y ~ x ∧ y = Combine (Expr s a) (Expr s a) }}} {{{ > stack runghc -- --interactive Intersect.hs Intersect.hs:13:29: error: warning: treating Unicode character <U+2227> as identifier character rather than as '^' symbol [-Wunicode-homoglyph] -- | > Combine x y ~ x ∧ y ^ | 13 | -- | > Combine x y ~ x ∧ y | ^ 1 warning generated. > stack runghc -- --version runghc 8.4.3 }}} There's a [https://github.com/BlockScope/unicode-homoglyph unicode- homoglyph] repo with the reproduction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin
by GHC 19 Oct '18

19 Oct '18

#15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple SourcePlugins, plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs. {{{ WARNING in hptSomeThingsBelowUs missing module CoercePlugin Probable cause: out-of-date interface files }}} I don't know if this just started happening or has been going on for a while. Is this warning cause for concern? Everything appears to work as expected despite this hiccup. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15349: fixST is a bit wrong
by GHC 19 Oct '18

19 Oct '18

#15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.5 Libraries | 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: -------------------------------------+------------------------------------- Lazy blackholing lets some `ST` calculations complete that shouldn't. {{{#!hs import Control.Monad.ST.Strict import Control.Monad.Fix import Data.STRef foo :: ST s Int foo = do ref <- newSTRef True mfix $ \res -> do x <- readSTRef ref if x then do writeSTRef ref False return $! (res + 5) else return 10 main = print $ runST foo }}} When this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`. Should we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15328: cpphs: internal error: evacuate(static): strange closure type 8440
by GHC 19 Oct '18

19 Oct '18

#15328: cpphs: internal error: evacuate(static): strange closure type 8440 -------------------------------------+------------------------------------- Reporter: cnmne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Package | Version: 8.4.3 system | Keywords: cabal, cpphs, | Operating System: MacOS X strange closure | Type of failure: Building GHC Architecture: x86 | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Attempting to install Agda via Cabal fails. I've installed cpphs through Cabal and {{{~/Library/Haskell/bin}}} is in my path. {{{~/.cabal/config}}} is default, but in {{{/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3 /settings}}} I have changed only {{{("C compiler supports -no- pie","NO")}}} (from "YES") because that was giving me errors earlier. The log states: "Please report this as a GHC bug..." so here I am :] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15328> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15776: Untested modules excluded from hpc coverage report
by GHC 18 Oct '18

18 Oct '18

#15776: Untested modules excluded from hpc coverage report -------------------------------------+------------------------------------- Reporter: ramirez7 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 8.4.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: -------------------------------------+------------------------------------- If I add a new module to my project without adding testing and then generate a code coverage report, there is no mention of the new module in the report. I believe the correct behavior is for the module to be included with it being 0% covered (w/corresponding highlighted source) I posted some details here: https://www.reddit.com/r/haskell/comments/9mjwr6/how_to_get_hpc_to_include_… As a workaround, I could probably use the hpc library to add 0% coverage for all modules to tix files. But that feels hacky. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15772: Strange constraint error that disappears when adding another top-level declaration
by GHC 18 Oct '18

18 Oct '18

#15772: Strange constraint error that disappears when adding another top-level declaration -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (Type checker) | 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: -------------------------------------+------------------------------------- Consider this program: {{{#!hs {-# LANGUAGE DataKinds, TypeFamilies, TypeOperators, UndecidableInstances #-} module CURepro where import Data.Kind data NP (f :: Type -> Type) (xs :: [Type]) type family Curry (f :: Type -> Type) (xs :: [Type]) (r :: Type) (a :: Type) :: Constraint where Curry f xs r (f x -> a) = (xs ~ (x : Tail xs), Curry f (Tail xs) r a) Curry f xs r a = (xs ~ '[], r ~ a) type family Tail (a :: [Type]) :: [Type] where Tail (_ : xs) = xs uncurry_NP :: (Curry f xs r a) => (NP f xs -> r) -> a uncurry_NP = undefined fun_NP :: NP Id xs -> () fun_NP = undefined newtype Id a = MkId a -- test1 :: () -- test1 = uncurry_NP fun_NP (MkId 5) test2 :: () test2 = uncurry_NP fun_NP (MkId True) (MkId 5) (MkId True) }}} With GHC 8.6.1 (and also 8.4.3), this produces the following error message: {{{ CURepro.hs:27:9: error: • Couldn't match type ‘Tail t0’ with ‘Bool : Tail (Tail t0)’ arising from a use of ‘uncurry_NP’ The type variable ‘t0’ is ambiguous • In the expression: uncurry_NP fun_NP (MkId True) (MkId 5) (MkId True) In an equation for ‘test2’: test2 = uncurry_NP fun_NP (MkId True) (MkId 5) (MkId True) | 27 | test2 = uncurry_NP fun_NP (MkId True) (MkId 5) (MkId True) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} However, uncommenting the definition of `test1` makes the whole program check without error! I think both versions of the program should be accepted. I've tried to extract this from a much larger failing example, but did not manage to make it any smaller than this. In particular, the fact that `NP` is parameterised over a type constructor `f` seems to be somehow essential to trigger this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15772> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 18 Oct '18

18 Oct '18

#7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): That does look good. I don't know how we can determine whether the problem is sufficiently fixed. We have an interaction between a weird language feature (detectably lifted functions) and a somewhat illegitimate compiler transformation that tries to avoid paying too much for those. Everything feels a bit brittle and ill-specified. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 18 Oct '18

18 Oct '18

#7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): Ah, you're right. look at this: {{{ module Foo (foo) where data List a = Nil | Cons a (List a) mapList :: (a -> b) -> List a -> List b mapList f Nil = Nil mapList f (Cons a l) = Cons (f a) (mapList f l) (#) :: (b -> c) -> (a -> b) -> a -> c (#) f g = f `seq` g `seq` \x -> f (g x) foo :: (a -> b) -> List a -> List b foo f = mapList (id # f) xs }}} The core i get looks like: {{{ mapList mapList = \ @ a_avr @ b_avs f_atJ ds_d10t -> case ds_d10t of { Nil -> Nil; Cons a1_atL l_atM -> Cons (f_atJ a1_atL) (mapList f_atJ l_atM) foo = \ @ a_avy @ b_avz f_atQ xs_atR -> mapList f_atQ xs_atR }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0