August 2015 - ghc-tickets

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 29 Aug '15

29 Aug '15

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, | deepseq, evaluate, exceptions Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #5129 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"15cb83d4e98c2c356bf0e3eb0df6d322755337bd/ghc" 15cb83d4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="15cb83d4e98c2c356bf0e3eb0df6d322755337bd" Add testcase for #7411 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 29 Aug '15

29 Aug '15

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: Phab:D1180 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"c1d7b4b43bbc4c7a590a8b942adc09e654d0659d/ghc" c1d7b4b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1d7b4b43bbc4c7a590a8b942adc09e654d0659d" StgCmmHeap: Re-add check for large static allocations This should at least help alleviate the annoyance of #4505. This reintroduces a compile-time check originally added in a278f3f02d09bc32b0a75d4a04d710090cde250f but dropped with the new code generator. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10808: Odd interaction between record update and type families
by GHC 29 Aug '15

29 Aug '15

#10808: Odd interaction between record update and type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following example {{{#!hs {-# LANGUAGE TypeFamilies #-} type family F a type family G a data T1 type instance F T1 = Char type instance G T1 = Int data T2 type instance F T2 = Bool type instance G T2 = Int data R a = R { x :: F a, y :: G a } r1 :: R T1 r1 = R { x = 'a', y = 2 } r2 :: R T2 r2 = r1 { x = True } -- error: Cannot match T1 with T2 r3 :: R T2 r3 = r1 { x = True, y = y r1 } -- OK }}} The error for `r2` is odd because types `R T1` and `R T2` differ only in the type of `x`, so if we start with a value of type `R T1`, and update the field where the types differ, we should end up with a valid value of type `R T2`. The fact that `r2` is OK is demonstrated by `r3` where we update the other field with its own value, and now the type checker is happy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10808> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 28 Aug '15

28 Aug '15

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: Phab:D1180 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: D1180 => Phab:D1180 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM
by GHC 28 Aug '15

28 Aug '15

#10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Compile-time Test Case: compile a | crash big web project | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I'm trying to get either yesod or scotty to build on my raspberry pi 2, which is running arch. Arch sports the newest working compiler for ghc, 7.8.2. Unfortunately llvm on arch is TOO new, and one must downgrade llvm, and the llvm downgrade packages are not available anywhere officially. I, however, happen to have these packages. These are for llvm 3.4.2-1.1. At any rate, I find I'm at an impasse with both Yesod and with Scotty. Sample output is attached. There's quite a bit of success, having compiled a lot of libraries, but it fails at the end. I thought it might be a lack of memory, so I gave it a try with a 1G swapfile as well, but that didn't help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10801> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10805: Could not deduce (a ~ b) implies (f a ~ f b), because a type function may not be injective
by GHC 28 Aug '15

28 Aug '15

#10805: Could not deduce (a ~ b) implies (f a ~ f b), because a type function may not be injective -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (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 Revisions: | -------------------------------------+------------------------------------- I don't know if the summary I provided is what's really going on here, but I'm a little baffled why this doesn't typecheck. I can't see what injectivity has to do with it, since we're not trying to deduce that the arguments are the same from the result of an application being the same; rather we're doing the opposite. I've encountered plenty of obvious arithmetic laws that I've needed to unsafeCoerceConstraint away with doing type level arithmetic, but this seems like it should be trivial regardless. {{{#!hs {-# LANGUAGE GADTs, ExplicitNamespaces, TypeOperators, DataKinds #-} {-# LANGUAGE ConstraintKinds, KindSignatures, PatternGuards #-} import Data.Type.Equality ((:~:)(..)) import GHC.TypeLits (Nat, type (<=), type (-), type (+), type (<=?)) data SNat :: Nat -> * where SSucc :: SNat a -> SNat (a + 1) SZero :: SNat 0 heqHet :: SNat a -> SNat b -> Maybe (a :~: b) heqHet SZero SZero = Just Refl heqHet (SSucc a) (SSucc b) | Just Refl <- heqHet a b = Just Refl heqHet _ _ = Nothing data Slice :: Nat -> Nat -> * where Slice :: ((start + 1) <= end, end <= numElements) => SNat numElements -> SNat start -> SNat end -> Slice numElements (end - start) heqHet' :: Slice a b -> Slice a b' -> Bool heqHet' (Slice _ start end) (Slice _ start' end') | Just _ <- heqHet start start' , Just _ <- heqHet end end' = True | otherwise = False }}} {{{#!hs Slice.hs:24:10: Could not deduce (((start + 1) <=? a) ~ ((start + 1) <=? a)) from the context (b ~ (end - start), (start + 1) <= end, end <= a) bound by a pattern with constructor Slice :: forall (numElements :: Nat) (start :: Nat) (end :: Nat). ((start + 1) <= end, end <= numElements) => SNat numElements -> SNat start -> SNat end -> Slice numElements (end - start), in an equation for ‘heqHet'’ at Slice.hs:24:10-26 or from (b' ~ (end1 - start1), (start1 + 1) <= end1, end1 <= a) bound by a pattern with constructor Slice :: forall (numElements :: Nat) (start :: Nat) (end :: Nat). ((start + 1) <= end, end <= numElements) => SNat numElements -> SNat start -> SNat end -> Slice numElements (end - start), in an equation for ‘heqHet'’ at Slice.hs:24:30-48 NB: ‘GHC.TypeLits.<=?’ is a type function, and may not be injective Relevant bindings include heqHet' :: Slice a b -> Slice a b' -> Bool (bound at Slice.hs:24:1) In the pattern: Slice _ start end In an equation for ‘heqHet'’: heqHet' (Slice _ start end) (Slice _ start' end') | Just _ <- heqHet start start', Just _ <- heqHet end end' = True | otherwise = False Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10804: Rules conditional on strictess properties
by GHC 28 Aug '15

28 Aug '15

#10804: Rules conditional on strictess properties -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hi, This is taking note of a rough idea, i.e. something that I might want to investigate more deeply some day. The current libraries contain this code, which makes the compiler switch from `foldl` to `foldl'` for certain types where `min` is known to be strict in the first argument. {{{#!hs minimum :: (Ord a) => [a] -> a {-# INLINE [1] minimum #-} minimum [] = errorEmptyList "minimum" minimum xs = foldl1 min xs {-# RULES "minimumInt" minimum = (strictMinimum :: [Int] -> Int); "minimumInteger" minimum = (strictMinimum :: [Integer] -> Integer) #-} strictMinimum :: (Ord a) => [a] -> a strictMinimum [] = errorEmptyList "minimum" strictMinimum xs = foldl1' min xs }}} Is is a bit sad that this can only be done by listing explicit instances. What I would like to see is that it sufficies to write {{{#!hs minimum :: (Ord a) => [a] -> a {-# INLINE [1] minimum #-} minimum [] = errorEmptyList "minimum" minimum xs = foldl1 min xs }}} and then there are general rules taking care of choosing the right `foldl` variant: {{{#!hs {-# RULES "strict foldl" forall f. mumble_mumble f ==> foldl f = foldl' f "strict foldl1" forall f. mumble_mumble f ==> foldl1 f = foldl1' f #-} }}} The `mumble_mumble` would be some way of specifying the required strictness properties of `f`, which would be checked use the strictness analyzer. A simple `isStrict f` is probably not sufficient (The information that `f` is strict in the first argument also depends on how many arguments we pass to f, as `min ⊥ ≠ ⊥`, but `∀x. min ⊥ x = ⊥`). Maybe `∀x. min ⊥ x = ⊥`, or some ASCIIfication of it, is indeed the proper sytanx.... This is related to #9137, which also wants conditional rewrite rules with certain compiler-checked aspectes of some of the matched variables. I think there is also a ticket (or at least an idea) about rewrite rules being conditional on some equation (e.g. (not very useful) `RULES forall f (*). (forall x y. x * y ≡ y * x) ==> foldl1 (*) (reverse xs) == foldl (*) xs`). I guess the rather vague #9601 covers that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10804> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10802: remote-debugger crashes with IntelliJ Haskell plugin in Mac OS X
by GHC 28 Aug '15

28 Aug '15

#10802: remote-debugger crashes with IntelliJ Haskell plugin in Mac OS X -------------------------------------+------------------------------------- Reporter: smcho | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- With `cabal install remote-debugger` to use debugger in IntelliJ on Mac OS X, but I have "Debug execution error: Internel error occurred while executing debug process for ..." error when I tried to debug a program in IntelliJ. In command line, I got this error. {{{ ~> remote-debugger remote-debugger: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): Main module not specified Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10802> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 27 Aug '15

27 Aug '15

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, | deepseq, evaluate, exceptions Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #5129 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #5129 Comment: See also: https://ghc.haskell.org/trac/ghc/ticket/5129#comment:17. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 27 Aug '15

27 Aug '15

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: D1180 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: simonmar => bgamari -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0