October 2018 - ghc-tickets

[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

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): Examples using `map` are important, but they also need to be taken with a grain of salt. List fusion will tear those things apart and put them together again and that can eliminate some problems we want to look at. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:26> 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): It also produces the same core with -O1. With -O0, i see the problem, but i would expect that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:25> 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): I'm using ghc 8.4.3, and compiling your example exactly with -O2 produces no difference whether i compile with '-fpedantic-bottoms' or '-fno- pedantic-bottoms' produce the same core. {{{ module Foo (foo) where (#) :: (b -> c) -> (a -> b) -> a -> c (#) f g = f `seq` g `seq` \x -> f (g x) foo :: (a -> b) -> [a] -> [b] foo f = map (id # f) }}} the core shows `foo = map`. This is in contrast to @nomeata's comment from 5 years ago, where compilation with -fpedantic-bottoms is necessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'
by GHC 18 Oct '18

18 Oct '18

#15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ % cat Nopie.hs module Nopie where main :: IO () main = putStrLn "hi" % ghc -fforce-recomp -c -fhpc Nopie.hs clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] }}} This happens for every source file when -fhpc is given, but also happens on links even when -fhpc isn't given. With -v, I see a call to gcc with -no-pie. When I run the same compile with ghc 8.4.1, I see the same call to gcc, only without that -no-pie flag, so this is new. It seems to be a harmless warning, but really clutters up the output. Incidentally, it looks like the particular spelling of -no-pie was added to LLVM a year ago due to ghc: https://reviews.llvm.org/D35462 Not sure if that's relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17