February 2017 - ghc-tickets

Re: [GHC] #797: nofib tests fail on Windows due to different EOL convention in output files
by GHC 18 Feb '17

18 Feb '17

#797: nofib tests fail on Windows due to different EOL convention in output files -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 6.4.1 suite | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3030 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Fixed in 307ae61121a99f6ffd3d5fa56e5d37b1b91a492b {{{ This allows nofib to run on Windows using `msys`. Also deprecates the old `cygwin` stuff. Test Plan: make clean && make Reviewers: bgamari Reviewed By: bgamari Subscribers: RyanGlScott, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3030 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/797#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #797: nofib tests fail on Windows due to different EOL convention in output files
by GHC 18 Feb '17

18 Feb '17

#797: nofib tests fail on Windows due to different EOL convention in output files -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 6.4.1 suite | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3030 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * differential: => Phab:D3030 * resolution: => fixed * milestone: 6.6 => 8.4.1 Old description: New description: Fixed in 307ae61121a99f6ffd3d5fa56e5d37b1b91a492b {{{ This allows nofib to run on Windows using `msys`. Also deprecates the old `cygwin` stuff. Test Plan: make clean && make Reviewers: bgamari Reviewed By: bgamari Subscribers: RyanGlScott, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3030 }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/797#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12409: Unboxed tuples have no type representations
by GHC 18 Feb '17

18 Feb '17

#12409: Unboxed tuples have no type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket continues with the long tradition of types missing type representations (see #12082, #12132, #11120). This time the culprit is unboxed tuples, {{{ $ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import Data.Typeable λ> :set -XUnboxedTuples λ> typeRep (Proxy :: Proxy (#Int, Int#)) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): tyConRep (#,#) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The problem, as usual, is that the tycons are missing from `knownKeyNames`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] Trac email verification for user: praduca
by GHC 17 Feb '17

17 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=4D_eeaAv> Username: praduca Verification Token: 4D_eeaAv -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13293: ConstrainedClassMethods makes GeneralizedNewtypeDeriving fail
by GHC 17 Feb '17

17 Feb '17

#13293: ConstrainedClassMethods makes GeneralizedNewtypeDeriving fail -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Example: {{{ {-# language GeneralizedNewtypeDeriving #-} {-# language ConstrainedClassMethods #-} instance ToDoc Int where toDoc = undefined newtype P = P Int deriving ( ToDoc ) type Doc = () class ToDoc a where toDoc :: ToDoc a => a -> Doc }}} compile with ghc-8.0.2: {{{ C.hs:6:30: error: • Couldn't match type ‘Int’ with ‘P’ arising from the coercion of the method ‘toDoc’ from type ‘ToDoc Int => Int -> Doc’ to type ‘ToDoc P => P -> Doc’ • When deriving the instance for (ToDoc P) }}} With ghc-8.0.1, it is fine. When I drop the constraint on the method declaration, ghc-8.0.2 compiles the program. This repetition of the class constraint in the method declaration actually came from a copy-paste error, so this issue does not affect my code, but it's still puzzling. Repeating the class constraint should not change the meaning of the program? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13291: bpk15 and bkp47 fail with -dunique-increment=-1
by GHC 17 Feb '17

17 Feb '17

#13291: bpk15 and bkp47 fail with -dunique-increment=-1 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4012 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This happens on master. Repro command: {{{ cd testsuite/; make EXTRA_HC_OPTS='-dunique-increment=-1' TEST="bkp15 bkp47" }}} Result: {{{ Compile failed (exit code 1) errors were: [1 of 3] Processing p [1 of 1] Compiling A[sig] ( p/A.hsig, nothing ) [2 of 3] Processing q [1 of 1] Compiling A[sig] ( q/A.hsig, nothing ) [3 of 3] Processing r [1 of 2] Compiling A[sig] ( r/A.hsig, nothing ) bkp47.bkp:10:9: error: • Class ‘C’ has conflicting definitions in the module and its hsig file Main module: class C a where g :: a -> a f :: a -> a {-# MINIMAL f | g #-} Hsig file: class C a where f :: a -> a g :: a -> a {-# MINIMAL f #-} The methods do not match: The names ‘f’ and ‘g’ are different The names ‘g’ and ‘f’ are different • while merging the signatures from: • p[A=<A>]:A • q[A=<A>]:A • ...and the local signature for A bkp47.bkp:10:9: error: • Class ‘C’ has conflicting definitions in the module and its hsig file Main module: class C a where g :: a -> a f :: a -> a {-# MINIMAL f | g #-} Hsig file: class C a where f :: a -> a g :: a -> a {-# MINIMAL g #-} The methods do not match: The names ‘f’ and ‘g’ are different The names ‘g’ and ‘f’ are different • while merging the signatures from: • p[A=<A>]:A • q[A=<A>]:A • ...and the local signature for A }}} {{{ Compile failed (exit code 1) errors were: bkp15.bkp:1:26: warning: -XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language. [1 of 5] Processing p [1 of 1] Compiling H[sig] ( p/H.hsig, nothing ) [2 of 5] Processing q [1 of 1] Compiling H[sig] ( q/H.hsig, nothing ) [3 of 5] Processing r [1 of 2] Compiling H[sig] ( r/H.hsig, nothing ) bkp15.bkp:36:9: error: • Class ‘Bloop’ has conflicting definitions in the module and its hsig file Main module: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool {-# MINIMAL xa | y | xa | y #-} Hsig file: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering {-# MINIMAL xa | y #-} The methods do not match: The names ‘xa’ and ‘y’ are different The types of ‘xa’ are different The default methods associated with ‘xa’ are not compatible The names ‘y’ and ‘xa’ are different The types of ‘y’ are different The default methods associated with ‘y’ are not compatible • while merging the signatures from: • p[H=<H>]:H • q[H=<H>]:H • ...and the local signature for H bkp15.bkp:36:9: error: • Class ‘Bloop’ has conflicting definitions in the module and its hsig file Main module: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool {-# MINIMAL xa | y | xa | y #-} Hsig file: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering {-# MINIMAL xa | y #-} The methods do not match: The names ‘xa’ and ‘y’ are different The types of ‘xa’ are different The default methods associated with ‘xa’ are not compatible The names ‘y’ and ‘xa’ are different The types of ‘y’ are different The default methods associated with ‘y’ are not compatible • while merging the signatures from: • p[H=<H>]:H • q[H=<H>]:H • ...and the local signature for H }}} This indicates some dependence on Unique ordering. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13291> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7398: RULES don't apply to a newtype constructor
by GHC 17 Feb '17

17 Feb '17

#7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: (none) 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: #6082, #10418, | Differential Rev(s): #13290 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #6082, #10418 => #6082, #10418, #13290 Comment: #13290 proposes disallowing rules for constructors altogether. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7398#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13227: Loss of full laziness in mapFB
by GHC 17 Feb '17

17 Feb '17

#13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- I've just discovered this {{{ g4 x expensive ys = let h = \7 -> y + expensive x in map h ys }}} Of course we'd expect the `(expensive x)` call to be floated out of the `\y`-abstraction, so that it is only done once. But it isn't! Here's the simplified core with -O: {{{ g4 = \ (@ b_aPG) (@ p_atr) ($dNum_aPP :: Num b) (x_arW :: p) (expensive_arX :: p -> b) (ys_arY :: [b]) -> map @ b @ b (\ (y_as0 [OS=ProbOneShot] :: b) -> + @ b $dNum_aPP y_as0 (expensive_arX x_arW)) ys_arY }}} Yikes! What is happening? Answer: look at that suspicious `ProbOneShot` on the `\y` above. Read `Note [Computing one-shot info, and ProbOneShot]` in `Demand.hs`. When `FloatOut` runs we have {{{ g4 = \ (@ b_aPL) (@ p_atw) ($dNum_aPU :: Num b) (x_as1 :: p) (expensive_as2 :: p -> b) (ys_as3 :: [b]) -> GHC.Base.build @ b (\ (@ b1_aQs) (c_aQt [OS=OneShot] :: b -> b1 -> b1) (n_aQu [OS=OneShot] :: b1) -> GHC.Base.foldr @ b @ b1 (GHC.Base.mapFB @ b @ b1 @ b c_aQt (\ (y_as5 [OS=ProbOneShot] :: b) -> + @ b $dNum_aPU y_as5 (expensive_as2 x_as1))) n_aQu ys_as3) }}} Why is the `\y` marked `ProbOneShot`? Because the occurrence analyser marked it so, based on the cardinality info from `mapFB`, even though `mapFB` was not saturated. So `Demand.argsOneShots` makes a deliberate choice to play risky, and that choice backfires badly for use of `map`. Not good! The offending commit, which introduced this behaviour, is (I think) {{{ commit 80989de947dc7edb55999456d1c1e8c337efc951 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Nov 22 17:13:05 2013 +0000 Improve the handling of used-once stuff Joachim and I are committing this onto a branch so that we can share it, but we expect to do a bit more work before merging it onto head. Nofib staus: - Most programs, no change - A few improve - A couple get worse (cacheprof, tak, rfib) Investigating the "get worse" set is what's holding up putting this on head. The major issue is this. Consider map (f g) ys where f's demand signature looks like f :: <L,C1(C1(U))> -> <L,U> -> . So 'f' is not saturated. What demand do we place on g? Answer C(C1(U)) That is, the inner C1 should stay, even though f is not saturated. I found that this made a significant difference in the demand signatures inferred in GHC.IO, which uses lots of higher-order exception handlers. I also had to add used-once demand signatures for some of the 'catch' primops, so that we know their handlers are only called once. }}} The commit isn't explicit about exactly what the "significant differences" are. Moreover note that in the comment the outer C1 is replaced by C, but nothing like that seems to happen in the code. This needs investigation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #13132: Compilation fails with a panic: get_op runContT
by GHC 17 Feb '17

17 Feb '17

#13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling 'tersmu' from Hackage fails with the following: {{{ [13 of 16] Compiling ParseM ( ParseM.hs, ParseM.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): get_op runContT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code can be found [https://gitlab.com/zugz/tersmu here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12243: RebindableSyntax and OverloadedLabels
by GHC 17 Feb '17

17 Feb '17

#12243: RebindableSyntax and OverloadedLabels -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Should these extensions work together? I wasn't able to come up with a good motivating example; I was playing around with lenses, and thought a more restrictive class definition might aid type inference, though it turned out in that particular case it didn't. In the general case I think it might still be useful. I didn't see any discussion on this, and it seemed like maybe it's an oversight. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4