October 2018 - ghc-tickets

[GHC] #15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks
by GHC 13 Oct '18

13 Oct '18

#15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.5 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15508 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While debugging #15508 I found a case where eager blackholing in AP_STACK causes `closure_sizeW()` to return incorrect size, which in turn causes incorrect slop zeroing by `OVERWRITING_CLOSURE()`, which breaks sanity checks. To reproduce, cd into `testsuite/tests/concurrent/prog001`, then: {{{ $ ghc-stage2 Mult.hs -fforce-recomp -debug -rtsopts $ ./Mult +RTS -DS Mult: internal error: checkClosure: stack frame (GHC version 8.7.20180825 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} Here's how the problem occurs: 1. Allocate an AP_STACK in a generation during a GC. 2. Evaluate the AP_STACK. The entry code first WHITEHOLEs and then eagerly BLACKHOLEs it. At this point size of the STACK becomes 2 because that's the size of (eager or not) BLACKHOLE. 3. To start a GC the thread does `threadPaused`, which in line 342 actually BLACKHOLEs the eager blackhole (is this part really correct?) and zeros the slop, but because the eager blackhole has the same size as BLACKHOLE it doesn't actually zero the stack frames in the original AP_STACK's payload. 4. In the next GC, in pre-GC sanity check we check the whole heap. When checking the generation that the BLACKHOLE (the AP_STACK that became a BLACKHOLE in step (2)) resides in we check the closure, and then check `closure + 2` (2 is the size of BLACKHOLE) instead of `closure + <size of the stack>`, and end up checking a stack frame of the original AP_STACK. This causes the sanity check to fail because we don't expect to see a stack frame outside of a stack. In summary, normally when blackhole an object we zero the space after the blackhole (i.e. some part of the original object's payload) so that in sanity checks we can skip over that space, but we can't do this when eagerly blackholing (because the payload of the original object will be used) which causes sanity check failures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15053: Compiler panic on invalid syntax (unterminated pragma)
by GHC 13 Oct '18

13 Oct '18

#15053: Compiler panic on invalid syntax (unterminated pragma) -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Parser) | 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: -------------------------------------+------------------------------------- The following minimal example causes a compiler panic. {{{ {-# OPTIONS_GHC -O1 } " #-} }}} {{{ ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.5.20180413 for x86_64-unknown-mingw32): getOptions'.parseToks: Couldn't read "\r\n\"\r\n " as String Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Happens in HEAD and 8.2.2 at least. Double quotes seem to confuse the parser. Also panics if there are two doublequotes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14907: Error message: (%, %) shows up when with accidental paren
by GHC 13 Oct '18

13 Oct '18

#14907: Error message: (%,%) shows up when with accidental paren -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I accidentally wrote an extra closing parens in instance declaration {{{#!hs $ ghci -ignore-dot-ghci -XRankNTypes GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> class (Category (Src f), forall xx. xx => Eq xx)) => Functor f <interactive>:1:8: error: Unexpected type ‘Category (Src f)’ In the class declaration for ‘GHC.Classes.(%,%)’ A class declaration should have form class GHC.Classes.(%,%) a b where ... Prelude> }}} `(%,%)` shouldn't show up here, same happens on 8.5.20180105 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)
by GHC 12 Oct '18

12 Oct '18

#8763: forM_ [1..N] does not get fused (10 times slower than go function) ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Apparently idiomatic code like {{{forM_ [1.._N]}}} does not get fused away. This can give serious performance problems when unnoticed. {{{ -- Slow: forM_ [0.._N-1] $ \i -> do ... -- Around 10 times faster: loop _N $ \i -> do ... {-# INLINE loop #-} loop :: (Monad m) => Int -> (Int -> m ()) -> m () loop bex f = go 0 where go !n | n == bex = return () | otherwise = f n >> go (n+1) }}} Full code example: https://gist.github.com/nh2/8905997 - the relevant alternatives are commented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 86

[GHC] #15196: Invert floating point comparisons such that no extra parity check is required.
by GHC 12 Oct '18

12 Oct '18

#15196: Invert floating point comparisons such that no extra parity check is required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (NCG) | Keywords: CodeGen | 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 comment pretty much explains it already: {{{ -- We have to worry about unordered operands (eg. comparisons -- against NaN). If the operands are unordered, the comparison -- sets the parity flag, carry flag and zero flag. -- All comparisons are supposed to return false for unordered -- operands except for !=, which returns true. -- -- Optimisation: we don't have to test the parity flag if we -- know the test has already excluded the unordered case: eg > -- and >= test for a zero carry flag, which can only occur for -- ordered operands. -- -- ToDo: by reversing comparisons we could avoid testing the -- parity flag in more cases. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep
by GHC 12 Oct '18

12 Oct '18

#15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this: {{{#!hs {-# LANGUAGE DataKinds, GADTs, KindSignatures #-} module Holo () where data ADT (p :: Integer) where ADT :: { a :: a , b :: Integer } -> ADT p foo = undefined {b=undefined} }}} ..yields: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): getRuntimeRep p_a29z :: Integer Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1967:18 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -v4 suggests this happend during the occurence analysis phase (log attached). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin
by GHC 12 Oct '18

12 Oct '18

#15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple typeable,knownnat | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10348 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the following Haskell code which uses `ghc-typelits-knownnat-0.5` package as a plugin: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-} module Nats where import Data.Proxy (Proxy (..)) import Data.Typeable (Typeable) import GHC.TypeLits (KnownNat, type (+)) f :: forall n . (Typeable n, KnownNat n) => Proxy n -> () f _ = () f _ = f (Proxy :: Proxy (n + 1)) }}} When I try to compile this code I observe the following error message: {{{ • Could not deduce (Typeable (n + 1)) arising from a use of ‘f’ from the context: (Typeable n, KnownNat n) bound by the type signature for: f :: forall (n :: ghc-prim-0.5.2.0:GHC.Types.Nat). (Typeable n, KnownNat n) => Proxy n -> () at src/Nats.hs:13:1-57 • In the expression: f (Proxy :: Proxy (n + 1)) In an equation for ‘f’: f _ = f (Proxy :: Proxy (n + 1)) | 15 | f _ = f (Proxy :: Proxy (n + 1)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This code works for both GHC-8.2.2 and GHC-8.0.2. I found similar ticket with exactly this problem but looks like this is broken again: #10348 (bug). Originally reported at Github for `ghc-typelits-knownnat` package: * https://github.com/clash-lang/ghc-typelits-knownnat/issues/21 `ghc-typelits-knownnat` package correctly infers `KnownNat (n + 1)` constraint so GHC should be able to infer `Typeable (n + 1)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #15744: Existence of complete pattern synonym hides unrelated incomplete pattern warning
by GHC 12 Oct '18

12 Oct '18

#15744: Existence of complete pattern synonym hides unrelated incomplete pattern warning -------------------------------------+------------------------------------- Reporter: Taneb | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This example {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern Foo :: a -> b -> (a, b) pattern Foo a b = (a, b) {-# complete Foo #-} main :: IO () main = case ((), Nothing :: Maybe Integer) of ((), Just x) -> print x }}} doesn't give a warning for the incomplete pattern match in {{{main}}}, which doesn't involve textually the pattern synonym {{{Foo}}}. Removing the complete pragma or changing the expression being matched on to even {{{(,) () (Nothing :: Maybe Integer)}}} allows the warning -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15476: Add -fwarn-star-is-type to -Wcompat
by GHC 12 Oct '18

12 Oct '18

#15476: Add -fwarn-star-is-type to -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.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: -------------------------------------+------------------------------------- According to the accepted proposal https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0030-remove-star-kind.rst This change must be included in 8.8, but I think it won't do any harm to include it in GHC 8.6 as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15476> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff.
by GHC 12 Oct '18

12 Oct '18

#13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. --------------------------------------+--------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Currently GHC HEAD segfaults on Windows 64-bit when compiling `language-c-quote-0.11.7.1` package. It spits something like `Access violation in generated code when executing data at 0000000102fbcf40` (I'm using my #13108 patch here). After repeated run, when GHC hasn't recompile all files, but only part of them, it succeeds. If I delete intermediate files and repeat clean compilation, it segfaults again. Haddock always segfaults (since it always recompile all files), more details here: https://github.com/haskell/haddock/pull/568. Since these access violations consistently happen on executable data at virtual addresses above 4GB mark, this very much smells as a GHC bytecode generator/linker issue. I believe, GHC and Haddock succeed exactly when all executable addresses stay below 4GB mark. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33