November 2018 - ghc-tickets

[GHC] #15921: Foldable.maximumBy uses counter-intuitive ordering
by GHC 28 Dec '18

28 Dec '18

#15921: Foldable.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: List | Operating System: Unknown/Multiple maximumBy minimumBy | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs Data.List.maximumBy (Data.Ord.comparing snd) [(0, 1), (3, 2), (2, 2), (1, 1)] }}} What do you expect the outcome to be? All Haskell-programmers I know that I asked this question, would answer, based on their intuition, `(3, 2)`. However, this is not the behaviour that `Data.List.maximumBy` currently has: Instead, `(2, 2)` (the ''last'' occurrence of a 'maximum' element) is kept. Furthermore, this behaviour is different from the one used by `Data.List.minimumBy`. I would therefore like to request: - If its behaviour is unintentionally different from `minimumBy`, alter the implementation to match it. - If its behaviour is intentionally the opposite, this should be specified in the documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler.
by GHC 28 Dec '18

28 Dec '18

#14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- For simple code such as `if a > 10 then foo else bar` it can make a big difference if we jump on `a > 10` or `a <= 10`. We already tracked the likelyhood of such conditionals for stack/heap checks in Cmm. I recently updated the native codegen on X86 to take this information into account where available and in one edge case this improved execution time from 1.7s to 1.5s! Having this info available for other cases like bound checking (assume valid) or partial pattern matches (assume no match failure) should be a small win for most programs and hopefully a big one for a few of them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8316: GHCi debugger segfaults when trying force a certain variable
by GHC 28 Dec '18

28 Dec '18

#8316: GHCi debugger segfaults when trying force a certain variable ------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The file Test.hs has following definitions: {{{ whnf :: a -> IO () whnf a = a `seq` (return ()) foo :: [Int] foo = [1..] }}} Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}} and bebugging foo like this: {{{ *Main> :b foo Breakpoint 0 activated at Test.hs:5:7-11 *Main> foo Stopped at Test.hs:5:7-11 _result :: [Int] = _ [Test.hs:5:7-11] *Main> :p foo foo = (_t1::[Int]) [Test.hs:5:7-11] *Main> whnf _t1 }}} results in this segault: {{{ <interactive>: internal error: TSO object entered! (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #15911: internal error: evacuate(static): strange closure type -127533247
by GHC 27 Dec '18

27 Dec '18

#15911: internal error: evacuate(static): strange closure type -127533247 -------------------------------------+------------------------------------- Reporter: bfraikin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- internal error: evacuate(static): strange closure type -127533247 (GHC version 8.4.4 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15911> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15939: StgLint fails because Stg bindings are not dependency-ordered
by GHC 27 Dec '18

27 Dec '18

#15939: StgLint fails because Stg bindings are not dependency-ordered -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9718 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After Phab:D5370 if I enable `-dstg-lint` when running the test suite I get about a dozen failures. I didn't check all, but most of them are because Stg bindings are not dependency-ordered, so some bindings come later in the list of bindings than their uses. I added a few debug prints to figure out if we ever have the bindings ordered in the pipeline. As far as I can see, by the time we desugar we have dependency-ordered bindings, but simplifier breaks the ordering by introducing uses. There are also "implicit" bindings introduced after simplifications (e.g. in CorePrep). Because of this by the time we start Stg generation we already have incorrect ordering. I think we have these options: - Don't assume dependency ordering in StgLint. Bring all top-level binders into the scope before linting bindings. - Somehow maintain dependency ordering in all of the Core passes so that by the time we start generating Stg we have an ordered list of bindings. (seems hard) - Sort Stg bindings in `CoreToStg`. (1) and (3) are equally simple, but (3) requires an extra pass over bindings. However, to be able to do the `CafInfo` analysis for #9718 efficiently we need (3), so I suggest implementing (3). We can then enable `-dstg-lint` in the test suite for all tests (add it to `TEST_HC_OPTS` in `testsuite/mk/test/mk`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14375: Implement with# primop
by GHC 27 Dec '18

27 Dec '18

#14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4110 | Wiki Page: -------------------------------------+------------------------------------- In Trac #14346 we proposed the new `with#` primop {{{ with# :: a -> (State# s -> (# State# s, b #)) -> State# s -> (# State# s, b #) }}} This ticket is to track progress. See Phab:D4110. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files
by GHC 26 Dec '18

26 Dec '18

#15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- Piyush has graciously volunteered to fix this. Relevant commit c5609577fab8a214c50561bea861c70d4bfd47c7 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15379> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #15842: Exponentiation needs PrelRules
by GHC 26 Dec '18

26 Dec '18

#15842: Exponentiation needs PrelRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 a user writes `a ^ lb`, where `lb` is an integer literal, the type of `lb` defaults to `Integer` unless it's annotated. If `lb` is very small, then `RULES` will expand the whole expression into a few multiplications. If not, the computation will pay the price of `Integer` arithmetic. If we want, we should be able to improve this with a special compilation rule. When `lb :: Integer`, and `0 <= lb <= maxBound :: Word`, we should be able to replace `lb` by the equivalent `Word`. The same problem appears with `^^` and `stimes`. Perhaps those can be fixed up as well, somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12034: Template Haskell + hs-boot = Not in scope during type checking, but it passed the renamer
by GHC 26 Dec '18

26 Dec '18

#12034: Template Haskell + hs-boot = Not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: backpack | 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 don't think this is a very harmful bug but it definitely is a bug. Consider: {{{ -- A.hs-boot module A where data T -- B.hs module B (module A) where import {-# SOURCE #-} A -- A.hs {-# LANGUAGE TemplateHaskell #-} module A where import qualified B import Language.Haskell.TH f :: B.T -> B.T f x = x $( return [] ) data T = T B.T }}} The point of the splice is to convince GHC to typecheck `f :: B.T -> B.T` before it typechecks the type declaration. But this is not going to work, because `tcLookupGlobal` is going to bail if (1) T is not in the `tcg_type_env` and (2) T comes from this module. It would be a simple matter to improve the error message but from a user's perspective, there is no good reason for this to not typecheck. On the implementation side, I am sympathetic to not letting this typecheck: if it does typecheck, then some `TyCon`s will incorrectly refer to the definition from the hs-boot file, rather than our local definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15915: Add CI for integer-simple
by GHC 25 Dec '18

25 Dec '18

#15915: Add CI for integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Continuous | Version: 8.6.2 Integration | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15915> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6