- ghc-tickets - Haskell.org

Re: [GHC] #8440: Get rid of the remaining static flags
by GHC 03 Feb '17

03 Feb '17

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.4.1 => 8.2.1 Comment: It's finally done! Thanks hsyl20! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8440: Get rid of the remaining static flags
by GHC 03 Feb '17

03 Feb '17

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"bbd3c399939311ec3e308721ab87ca6b9443f358/ghc" bbd3c39/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bbd3c399939311ec3e308721ab87ca6b9443f358" Ditch static flags This patch converts the 4 lasting static flags (read from the command line and unsafely stored in immutable global variables) into dynamic flags. Most use cases have been converted into reading them from a DynFlags. In cases for which we don't have easy access to a DynFlags, we read from 'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'. It's not perfect (not thread-safe) but it is still better as we can set/unset these 4 flags before each run when using GHC API. Updates haddock submodule. Rebased and finished by: bgamari Test Plan: validate Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2839 GHC Trac Issues: #8440 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13228: Surprising inlining failure
by GHC 03 Feb '17

03 Feb '17

#13228: Surprising inlining failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- When I fail to mark something seemingly unrelated `INLINE`, something else doesn't inline. In the below (cut down dramatically from my recent lazy ST work), if I don't mark `>>` inline in the `Monad` instance, then `*>` never inlines, and none of the rules fire when compiling `foom` and `basic`. If `>>` is marked inline, then everything works as expected. {{{#!hs module RulesLazy (ST, strictToLazyST, lazyToStrictST) where import qualified Control.Monad.ST as ST -- No, this is not really lazy ST newtype ST s a = ST (s -> (a, s)) instance Functor (ST s) where fmap _ _ = undefined instance Applicative (ST s) where pure _ = undefined _ <*> _ = undefined m *> n = m `thenST` n {-# NOINLINE [1] thenST #-} thenST :: ST s a -> ST s b -> ST s b _ `thenST` _ = ST $ \_ -> undefined instance Monad (ST s) where {-# INLINE (>>) #-} -- CRITICAL LINE m >> n = m `thenST` n _ >>= _ = undefined {-# NOINLINE [1] strictToLazyST #-} strictToLazyST :: ST.ST s a -> ST s a strictToLazyST _ = ST $ \_ -> undefined {-# NOINLINE [1] lazyToStrictST #-} lazyToStrictST :: ST s a -> ST.ST s a lazyToStrictST _ = undefined {-# RULES "then/S2L" forall m n . m `thenST` strictToLazyST n = strictToLazyST (lazyToStrictST m *> n) "L2S/S2L" forall m . lazyToStrictST (strictToLazyST m) = m #-} module RulesBurn where import RulesLazy import qualified Control.Monad.ST as SST {-# NOINLINE foom #-} foom :: SST.ST s a -> SST.ST s b -> SST.ST s c -> ST s c foom m n o = (strictToLazyST m *> strictToLazyST n) *> strictToLazyST o {-# NOINLINE basic #-} basic :: ST s a -> SST.ST s b -> ST s b basic m n = m *> strictToLazyST n }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched
by GHC 03 Feb '17

03 Feb '17

#5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this is out of scope of the pattern match checker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5728#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13098: Template Haskell support for Pattern Synonym's Complete Pragma
by GHC 03 Feb '17

03 Feb '17

#13098: Template Haskell support for Pattern Synonym's Complete Pragma -------------------------------------+------------------------------------- Reporter: magesh.b | Owner: mpickering 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: -------------------------------------+------------------------------------- #8779 provides exhaustive checking support for Pattern Synonym via Complete pragma. https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs It would be nice, if we are able to generate those pragma via TH. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis
by GHC 03 Feb '17

03 Feb '17

#10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would expect GHC to warn of a non-exhaustive pattern match at compile- time when faced with this, {{{#!hs {-# LANGUAGE EmptyCase #-} module Test where test :: Bool -> Int test a = case a of }}} Yet it happily accepts this without complaint. If one attempts to evaluate, e.g., `test True` the expected "Non-exhaustive patterns in case" error is thrown at runtime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10746> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

Re: [GHC] #2269: Word type to Double or Float conversions are slower than Int conversions
by GHC 03 Feb '17

03 Feb '17

#2269: Word type to Double or Float conversions are slower than Int conversions -------------------------------------+------------------------------------- Reporter: dons | Owner: dons@… Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: rules, | performance, double, newcomer 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 rwbarton): * keywords: rules, performance, double => rules, performance, double, newcomer Comment: Namely, {{{ double f(unsigned long x) { return x; } /* 0000000000000000 <f>: 0: 66 48 0f 6e cf movq %rdi,%xmm1 5: 66 0f 62 0d 00 00 00 punpckldq 0x0(%rip),%xmm1 # d <f+0xd> c: 00 9: R_X86_64_PC32 .LCPI0_0-0x4 d: 66 0f 5c 0d 00 00 00 subpd 0x0(%rip),%xmm1 # 15 <f+0x15> 14: 00 11: R_X86_64_PC32 .LCPI0_1-0x4 15: 66 0f 70 c1 4e pshufd $0x4e,%xmm1,%xmm0 1a: 66 0f 58 c1 addpd %xmm1,%xmm0 1e: c3 retq */ }}} Compiling the test program here with LLVM there's no measurable difference between the int and word versions, so I guess doing this is worthwhile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2269#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2269: Word type to Double or Float conversions are slower than Int conversions
by GHC 03 Feb '17

03 Feb '17

#2269: Word type to Double or Float conversions are slower than Int conversions -------------------------------------+------------------------------------- Reporter: dons | Owner: dons@… Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: rules, | performance, double 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 rwbarton): Replying to [comment:16 thomie]: > But `testWord` is still 3 times slower than `testInt`. > {{{ > $ time ./testWord > 5.00000005e15 > > real 0m0.579s > user 0m0.575s > sys 0m0.003s > > $ time ./testInt > 5.00000005e15 > > real 0m0.196s > user 0m0.191s > sys 0m0.004s > }}} > > As I can not easily explain this difference, I'll leave this ticket open for now. It's because the x86 NCG implements the new `MO_UF_Conv` as a call to a C function, rather than generating code inline like `MO_SF_Conv` (`cvtsi2sdq`). Unfortunately there's no corresponding instruction for converting an unsigned 64-bit integer to float or double, but for converting to double the code generated by `clang -O` is pretty small and simple and probably worth inlining. It will still be somewhat slower than `Int` though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2269#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 02 Feb '17

02 Feb '17

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'll look forward to the proposal. It's a remarkably small patch! Don't forget to add comprehensive tests etc. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13224: Rules and join points
by GHC 02 Feb '17

02 Feb '17

#13224: Rules and join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From Note [Rules and join points] in `OccurAnal`: Things get fiddly with rules. Suppose we have: {{{ let j :: Int -> Int j y = 2 * y k :: Int -> Int -> Int {-# RULES "SPEC k 0" k 0 = j #-} k x y = x + 2 * y in ... }}} Now suppose that both j and k appear only as saturated tail calls in the body. Thus we would like to make them both join points. The rule complicates matters, though, as its RHS has an unapplied occurrence of j. //However//, if we were to eta-expand the rule, all would be well: {{{ {-# RULES "SPEC k 0" forall a. k 0 a = j a #-} }}} So conceivably we could notice that a potential join point would have an "undersaturated" rule and account for it. This would mean we could make something that's been specialised a join point, for instance. But local bindings are rarely specialised, and being overly cautious about rules only costs us anything when, for some `j`: * Before specialisation, `j` has non-tail calls, so it can't be a join point. * During specialisation, `j` gets specialised and thus acquires rules. * Sometime afterward, the non-tail calls to `j` disappear (as dead code, say), and so now `j` //could// become a join point. This appears to be very rare in practice. TODO Perhaps we should gather statistics to be sure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1