November 2015 - ghc-tickets

[GHC] #8098: Faulty Word64 arithmetic if optimized
by GHC 02 Dec '15

02 Dec '15

#8098: Faulty Word64 arithmetic if optimized ----------------------------+--------------------------------- Reporter: achp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The following program produces different results depending on optimization: Checked.hs: {{{ module Checked ((.-.)) where (.-.) :: (Bounded a, Integral a) => a -> a -> Maybe a x .-. y | x >= 0 && y < 0 = if z > x then Just z else Nothing | x >= 0 = if z <= x then Just z else Nothing | x < 0 && y > 0 = if z < x then Just z else Nothing | otherwise = Just z where z = x - y }}} Main.hs: {{{ module Main (main) where import Data.Maybe import Data.Word import Numeric import Checked main :: IO () main = print $ showHex (fromJust ((0xFFFFFFFF00000000 :: Word64) .-. 0x00000000FFFFFFFF)) "" }}} {{{ D:\dev\haskell\ch1>ghc --make Checked.hs Main.hs [1 of 2] Compiling Checked ( Checked.hs, Checked.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... D:\dev\haskell\ch1>Main.exe "fffffffe00000001" D:\dev\haskell\ch1>del *.hi *.o *.exe D:\dev\haskell\ch1>ghc --make -O2 Checked.hs Main.hs [1 of 2] Compiling Checked ( Checked.hs, Checked.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... D:\dev\haskell\ch1>Main.exe "fffe00000001" D:\dev\haskell\ch1> }}} The bug disappears if definition and usage of (.-.) are in the same module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11127: Update cabal submodule to 1.22 branch HEAD
by GHC 01 Dec '15

01 Dec '15

#11127: Update cabal submodule to 1.22 branch HEAD -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | 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 7.10.3, this will fold in a critical fix for Mac (the Cabal side of #10568), along with a fix to prevent c-sources from being recompiled unnecessarily (a big deal when working with large C/C++ bindings). The commit is 5acbc41 https://github.com/haskell/cabal/tree/1.22 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11127> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10896: BadSock triggers failing ASSERT
by GHC 01 Dec '15

01 Dec '15

#10896: BadSock triggers failing ASSERT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ --- ./indexed-types/should_fail/BadSock.stderr.normalised 2015-09-18 20:44:48.437390831 +0000 +++ ./indexed-types/should_fail/BadSock.comp.stderr.normalised 2015-09-18 20:44:48.437390831 +0000 @@ -1,5 +1,5 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 7.11.20150918 for x86_64-unknown-linux): + ASSERT failed! file compiler/typecheck/TcFlatten.hs, line 1041 -BadSock.hs:30:5: - The type family â€˜Readableâ€™ should have 1 argument, but has been given none - In the equations for closed type family â€˜Fooâ€™ - In the type family declaration for â€˜Fooâ€™ \ No newline at end of file +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug \ No newline at end of file *** unexpected failure for BadSock(normal) }}} Haven't investigated any further. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10896> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10839: Consistent pretty-printing of type families
by GHC 01 Dec '15

01 Dec '15

#10839: Consistent pretty-printing of type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.11 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Say I have this silly open type family declaration: {{{#!hs type family F a type instance F a = a type instance F a = Int }}} GHC complains: {{{ Foo.hs:8:15: error: Conflicting family instance declarations: F a -- Defined at Foo.hs:8:15 F a -- Defined at Foo.hs:9:15 }}} Now let's do some silliness with a closed type family: {{{#!hs type family F a where F a = a F a = Int }}} GHC warns: {{{ T6018.hs:9:5: warning: Type family instance equation is overlapped: F a = Int }}} Finally, some silliness with a kind-polymorphic type family: {{{#!hs type family Gc (a :: k) (b :: k) = r | r -> k where Gc a b = Int }}} GHC complains: {{{ T6018.hs:9:5: error: Type family equation violates injectivity annotation. Injective kind variable ‘k’ is not inferable from the RHS type variables. In the RHS of type family equation: forall (k :: BOX) (a :: k) (b :: k). Gc a b = Int In the equations for closed type family ‘Gc’ In the type family declaration for ‘Gc’ }}} There are some inconsistencies in pprinting of type family equations: * for open type families we print the location where the equation was defined but we do not print the RHS * for closed type families we print the RHS but we do not print the location in the source file * kind-polymorphic equations are not indented I would like to have a consistent pretty-printing of type family equations, one that prints the RHS, source code location and indents kind- polymorphic equations. The difference in pretty printing between open and closed type families comes from the difference between pprinting `CoAxBranch` and `FamInst`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7596: Opportunity to improve CSE
by GHC 30 Nov '15

30 Nov '15

#7596: Opportunity to improve CSE -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7596#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 30 Nov '15

30 Nov '15

#2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.10.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 nomeata): Quite right. If one of us can now find the corresponding ticket, then we can continue there, and not hijack the discussion here :-)... there it is: #9291. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 30 Nov '15

30 Nov '15

#2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.10.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 osa1): Why do we need to do CSE in STG level to avoid allocation in `Either`s `fmap`? What does STG give us extra over Core? Do you mean not having type terms help? If so, how? {{{#!haskell -- RHS size: {terms: 14, types: 17, coercions: 0} Main.$fFunctorEither1_$cfmap :: forall a_aOH a1_avU b_avV. (a1_avU -> b_avV) -> Either1 a_aOH a1_avU -> Either1 a_aOH b_avV Main.$fFunctorEither1_$cfmap = \ (@ a_aOH) (@ a1_aOL) (@ b_aOM) (ds_dR3 :: a1_aOL -> b_aOM) (ds1_dR4 :: Either1 a_aOH a1_aOL) -> case ds1_dR4 of _ { Left1 x_avi -> Main.Left1 @ a_aOH @ b_aOM x_avi; Right1 y_avk -> Main.Right1 @ a_aOH @ b_aOM (ds_dR3 y_avk) } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 30 Nov '15

30 Nov '15

#2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.10.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 nomeata): I did? Oh dear. It must have been before I started to dislike CSE very much, because it gets in the way of rules, and can creasing sharing (e.g. by cse’ing `[0..1000]`). Or maybe it was precisely when I startd to dislike CSE... :-) Speaking about the phases CSE should happen: I very much believe we need a CSE phase as an Stg-to-Stg-transformation, to avoid reallocating `Left`s in the code for a `Either`’s `fmap`, for example. (There is a ticket for this, cannot find it right now.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 30 Nov '15

30 Nov '15

#2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.10.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 simonpj): See [wiki:MoreCSE]. I'm inclined to think that it'd be better to do CSE ''earlier'' not ''later''. The main idea (on the [wiki:MoreCSE] page) is this: * Make float-out more aggressive by (a) let-binding every sub-expression, and (b) floating let-bindings out even if they don't escape a lambda. So in your first example {{{ g x = (x + 1, x + 1) }}} we'd get {{{ g x = let v1 = x+1 in let v2 = x+2 in (v1,v2) }}} * Now do CSE as now. The extra let-bindings should give a lot more more opportunities. * Float inwards to reverse the effect of the first pass if CSE did not bite. Also talk to Joachim who wrote [wiki:MoreCSE]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11139: Add Semigroup warnings
by GHC 29 Nov '15

29 Nov '15

#11139: Add Semigroup warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Similar to #8004, do the following for Semigroup/Monoid: 1. Warn when an instance of a class has been given, but the type does not have a certain superclass instance 2. Warn when top-level definitions conflict with future Prelude names -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11139> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5