April 2018 - ghc-tickets

[GHC] #14089: Segmentation fault/access violation using Yesod and Postgresql
by GHC 07 Apr '18

07 Apr '18

#14089: Segmentation fault/access violation using Yesod and Postgresql --------------------------------------+--------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- When trying to build a Yesod site with Postgresql I got the following: I tried to use PostgreSQL and got the following: website-0.0.0: configure (lib) Configuring website-0.0.0... website-0.0.0: build (lib) Preprocessing library website-0.0.0... [ 1 of 11] Compiling Settings ( src\Settings.hs, .stack- work\dist\ca59d0ab\build\Settings.o ) [ 2 of 11] Compiling Settings.StaticFiles ( src\Settings\StaticFiles.hs, .stack-work\dist\ca59d0ab\build\Settings\StaticFiles.o ) Segmentation fault/access violation in generated code -- While building package website-0.0.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe --builddir=.stack- work\dist\ca59d0ab build lib:website --ghc-options " -ddump-hi -ddump-to- file" Process exited with code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15004: Building HEAD fails with -j3 because of unrecorded dependencies.
by GHC 06 Apr '18

06 Apr '18

#15004: Building HEAD fails with -j3 because of unrecorded dependencies. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There seem to be some missing dependencies. {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries /ghc-prim/dist-install/build -ilibraries/ghc-prim/dist- install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-trustworthy- safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist- install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic- too -c libraries/ghc-prim/./GHC/Magic.hs -o libraries/ghc-prim/dist- install/build/GHC/Magic.o -dyno libraries/ghc-prim/dist- install/build/GHC/Magic.dyn_o libraries/base/GHC/IO.hs-boot:9:12: error: • Failed to load interface for ‘GHC.Integer.Type’ There are files missing in the ‘integer-gmp-1.0.1.0’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. • In the type signature: mplusIO :: IO a -> IO a -> IO a | 9 | mplusIO :: IO a -> IO a -> IO a | ^^^^^^^^^^^^^^^^^^^^ }}} It seems Magic.hs depends in integer-gmp. Which happened to be not yet built so it fails. I'm not sure which import it is that is missing but recording it here. Commit for head is 72b5f649ede82ab3bb429aa72ee1c572f415b0eb Building single threaded for a while and then continuing the build with -j3 seems to be a valid workaround. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11815: Data.List: Add a function to get consecutive elements (mapConsecutives)
by GHC 06 Apr '18

06 Apr '18

#11815: Data.List: Add a function to get consecutive elements (mapConsecutives) -------------------------------------+------------------------------------- Reporter: holmisen | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: | Version: libraries/base | 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: -------------------------------------+------------------------------------- A recurring pattern is to get a list of all consecutive elements of a list, for further processing. I propose adding the following function to `Data.List` for this: {{{ mapConsecutives :: (a -> a -> b) -> [a] -> [b] mapConsecutives _ [] = [] mapConsecutives f xs = zipWith f xs (tail xs) }}} Since it requires pattern matching, to separate the empty case, it is not practical to inline at each use site. Sidenote: A similar function `mapAdjacent` is available in the `utility- ht` library (with a partial implementation(!)) [1]. I realise that `Data.List` is often imported unqualified and hence additions may cause trouble. I would have raised this on the libraries mailing list first, but the guidelines for proposals pointed me here. [1] http://hackage.haskell.org/package/utility-ht-0.0.11/docs/Data-List- HT.html#v:mapAdjacent -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #14951: SpecContsr needs two runs when one should suffice
by GHC 06 Apr '18

06 Apr '18

#14951: SpecContsr needs two runs when one should suffice -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: SpecConstr | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14844 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin-off of #14844, which is a spin-off of #14068, but applies on its own. Consider this code: {{{ module T14844Example (topLvl) where topLvl large = (bar1, bar2, foo) where foo :: Integer -> (a -> b -> Bool) -> (a,b) -> Bool foo 0 _ _ = False foo s f t = l s' t where l 0 t = False l 1 t = case t of (x,y) -> f x y l n (x,y) = l (n-1) (x,y) s' = large s bar1 :: Integer -> (a -> b -> Bool) -> a -> b -> Bool bar1 s f x y = foo s f (x,y) bar2 :: Integer -> (a -> b -> Bool) -> a -> b -> Bool bar2 s f x y = foo (s + 1) f (x,y) }}} Status quo: `l` gets specialized, because of the two call patterns `s' t0` and `(s-1) (x,y)`, the second one is interesting *and* its second argument gets scrutinized (the `scu_occs` field reports `ScrutOcc` for `t`). But `foo` does not get specialized: It does have an interesting call pattern, but `scu_occs` reports `UnkOcc`, because `foo`’s parameters are just passed to `t`. But: When we decide to !SpecConstr `l`, we know that one of the calls to `l` is of the shape `s' t0`. This is a boring call, and we do not create a specialization for it. But we create a specialization for `l` using the the other call pattern. This means we know that it would be beneficial if `t0` were a constructor. So can we, at this point, decide to include `t0 ↦ ScrutOcc` in `scu_occs`? First experiments look good, so I am working on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

Re: [GHC] #1013: interpretBCO: unknown or unimplemented opcode 64356
by GHC 06 Apr '18

06 Apr '18

#1013: interpretBCO: unknown or unimplemented opcode 64356 -------------------------------------+------------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.6.1 Component: GHCi | Version: 6.6 Resolution: fixed | Keywords: OSX Sockets Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: ghci002 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * keywords: "OS X" Sockets => OSX Sockets * failure: => None/Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1013#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #898: GHC compiles against Apple's readline, giving error
by GHC 06 Apr '18

06 Apr '18

#898: GHC compiles against Apple's readline, giving error ---------------------------------+----------------------------------- Reporter: doaitse | Owner: thorkilnaur Type: bug | Status: closed Priority: high | Milestone: 6.6.1 Component: Build System | Version: 6.5 Resolution: invalid | Keywords: OSX Sockets Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------------- Changes (by ulysses4ever): * keywords: "OS X" Sockets => OSX Sockets * failure: => None/Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/898#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12949: Pattern coverage mistake
by GHC 06 Apr '18

06 Apr '18

#12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I disabled syntax highlighting below; the bugs highlighting single quotes made the code unreadable. {{{ {-# LANGUAGE DataKinds, TypeFamilies, GADTs, TypeOperators, ScopedTypeVariables, ConstraintKinds, StandaloneDeriving #-} {-# OPTIONS_GHC -Wall #-} import Data.Constraint import Data.Type.Bool -- Bool singletons data Boolly b where Falsey :: Boolly 'False Truey :: Boolly 'True deriving instance Show (Boolly b) class KnownBool b where knownBool :: Boolly b instance KnownBool 'False where knownBool = Falsey instance KnownBool 'True where knownBool = Truey -- OrRel a b r expresses all the usual implications inherent -- in the statement that r ~ (a || b). type OrRel (a :: Bool) (b :: Bool) (r :: Bool) :: Constraint = (r ~ (a || b), If r (If (Not a) (b ~ 'True) (() :: Constraint), If (Not b) (a ~ 'True) (() :: Constraint)) (a ~ 'False, b ~ 'False)) -- Given known Bools, their disjunction is also known abr :: forall a b r p1 p2 . (OrRel a b r, KnownBool a, KnownBool b) => p1 a -> p2 b -> Dict (KnownBool r) abr _ _ = case knownBool :: Boolly a of Truey -> Dict Falsey -> case knownBool :: Boolly b of Truey -> Dict -- Problematic match Falsey -> Dict }}} The trouble is that GHC warns that the problematic match is redundant, which it is not. If I remove it, GHC ''fails'' to warn that the patterns are incomplete, which they are. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #5129: "evaluate" optimized away
by GHC 06 Apr '18

06 Apr '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Changes (by George): * cc: George (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 06 Apr '18

06 Apr '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Comment (by George): Forgive me for asking what seems to be obvious: do we need to run validate ./slow more often? Maybe we have already decided to do that in which case it might be good to record that here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 05 Apr '18

05 Apr '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Phab:D4567 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): We should either stop allocating `CONSTR_NOCAF` on the heap, or apply the patch I submitted. If I'm understanding the story correctly we can legitimately allocate `CONSTR_NOCAF` on the heap so I think the patch is correct. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0