September 2017 - ghc-tickets

[GHC] #13956: ghc panic compiling lame-0.1.1
by GHC 04 Sep '17

04 Sep '17

#13956: ghc panic compiling lame-0.1.1 -------------------------------------+------------------------------------- Reporter: uznx | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the package lame-0.1.1 using cabal, with profiling: [2 of 2] Compiling Codec.Audio.LAME ( Codec/Audio/LAME.hs, dist/build/Codec/Audio/LAME.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170704 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone lvl_soT9 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 504681 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This is a regression; the package compiles fine with GHC 8.0.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't
by GHC 03 Sep '17

03 Sep '17

#14167: GHC often depicts H98 datatypes as GADTs when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: GADTs, | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Spun off from Phab:D3880.) There are at least a couple of points in the GHC codebase where poor decisions are made regarding whether to depict a datatype using H98 syntax or GADT syntax. In particular: 1. When reifying a datatype in Template Haskell, some complicated heuristics are used to determine whether a datatype is reified with `(Rec)GadtC` or not (see `Note [Reifying GADT data constructors]` in `TcSplice` for the horrifying details). But these heuristics are far from perfect, as they will cause some vanilla datatypes to be reified as GADTs (e.g., `data T a = (a ~ Int) => MkT`). 2. When pretty-printing a datatype (for instance, via the `:info` command in GHCi), GHC also chooses to sometimes depict vanilla datatypes as GADTs. For instance: {{{ λ> :set -XExistentialQuantification λ> data Foo a = Show a => Foo λ> :i Foo type role Foo nominal data Foo a where Foo :: Show a => Foo a }}} `Foo` is depicted as a GADT, despite the fact that we didn't use GADT syntax. There might be other places in the code that exhibit these symptoms too—we should take a closer look. I use the phrase "poor decisions" above since GHC really does have the right info it needs to make the correct decisions. That info is in the form of the `isGadtSyntaxTyCon`, which conveniently recalls whether a datatype was declared with GADT syntax or not. With this, we should be able to eliminate the flawed heuristics that GHC is currently using and accurately depict datatypes the way users wrote them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides)
by GHC 03 Sep '17

03 Sep '17

#14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | 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): | Wiki Page: -------------------------------------+------------------------------------- I'm trying to define my own fancy strict maybe types, and so i've written some pattern synonyms to wrap them up. imagine my surprise when i find i can write bang patterns on the *right* hand side, but not the left hand! {{{ data MyMaybe a = JustC a | NothingC pattern MyJust :: a -> MyMaybe a -- pattern MyJust !a = JustC a -- this fails pattern MyJust a = JustC !a -- this is fine }}} is this deliberate or a leakage of how desugaring works? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13885: Template Haskell doesn't freshen GADT kind variables properly when imported from another package
by GHC 03 Sep '17

03 Sep '17

#13885: Template Haskell doesn't freshen GADT kind variables properly when imported from another package -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A simple way to illustrate this bug is with this code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} module Foo where import qualified Data.Type.Equality as DTE ((:~:)) import Language.Haskell.TH data a :~: b where Refl :: a :~: a $(return []) main :: IO () main = do putStrLn "Imported\n-----" putStrLn $(reify ''(DTE.:~:) >>= stringE . pprint) putStrLn "-----\n\nLocally defined\n-----" putStrLn $(reify ''(:~:) >>= stringE . pprint) putStrLn "-----" }}} Here, I'm pretty-printing the reified Template Haskell information about two datatypes: one that is imported from another package (`base`), and another that is defined locally. Aside from their definition sites, they are otherwise identical. However, when reifying them with Template Haskell, there is another distinction one can observe: {{{ $ /opt/ghc/8.2.1/bin/runghc Foo.hs Imported ----- data Data.Type.Equality.:~: (a_0 :: k_1) (b_2 :: k_1) where Data.Type.Equality.Refl :: forall (k_1 :: *) (a_0 :: k_1) . Data.Type.Equality.:~: a_0 a_0 ----- Locally defined ----- data Foo.:~: (a_0 :: k_1) (b_2 :: k_1) where Foo.Refl :: forall (k_3 :: *) (a_4 :: k_3) . Foo.:~: a_4 a_4 ----- }}} The locally defined information looks fine, but the one imported from `base` is suspicious. Namely, the `k_1` variable is used both in the datatype head and in the quantified variables for the constructor! To confirm this, you can print out more verbose info with `show` instead of `pprint`: {{{ Imported ----- TyConI (DataD [] Data.Type.Equality.:~: [KindedTV a_6989586621679026781 (VarT k_6989586621679026780),KindedTV b_6989586621679026782 (VarT k_6989586621679026780)] Nothing [ForallC [KindedTV k_6989586621679026780 StarT,KindedTV a_6989586621679026781 (VarT k_6989586621679026780)] [] (GadtC [Data.Type.Equality.Refl] [] (AppT (AppT (ConT Data.Type.Equality.:~:) (VarT a_6989586621679026781)) (VarT a_6989586621679026781)))] []) ----- Locally defined ----- TyConI (DataD [] Foo.:~: [KindedTV a_6989586621679016094 (VarT k_6989586621679016098),KindedTV b_6989586621679016095 (VarT k_6989586621679016098)] Nothing [ForallC [KindedTV k_6989586621679016108 StarT,KindedTV a_6989586621679016096 (VarT k_6989586621679016108)] [] (GadtC [Foo.Refl] [] (AppT (AppT (ConT Foo.:~:) (VarT a_6989586621679016096)) (VarT a_6989586621679016096)))] []) ----- }}} Sure enough, the variable `k_6989586621679026780` is used in both places. I would expect this not to happen, since the two sets of variables are scoped differently, and in practice, I have to work around this by freshening the type variables for the constructor, which is annoying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread
by GHC 02 Sep '17

02 Sep '17

#5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #12038 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #12038 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5553#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread
by GHC 02 Sep '17

02 Sep '17

#5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed Comment: I'm unable to reproduce this in 8.2.1. I think it may have been fixed by d5cd505bc484edee3dbd5d41fb7a27c2e18d528d {{{ Author: Ben Gamari <bgamari.foss(a)gmail.com> Date: Tue Jan 17 15:52:37 2017 -0500 event manager: Don't worry if attempt to wake dead manager fails This fixes #12038, where the TimerManager would attempt to wake up a manager that was already dead, resulting in setnumcapabilities001 occassionally failing during shutdown with unexpected output on stderr. I'm frankly still not entirely confident in this solution but perhaps it will help to get a few more eyes on this. My hypothesis is that the TimerManager is racing: thread TimerManager worker ------- -------------------- requests that thread manager shuts down begins to clean up, closing eventfd calls wakeManager, which tries to write to closed eventfd To prevent this `wakeManager` will need to synchronize with the TimerManger worker to ensure that the worker doesn't clean up the `Control` while another thread is trying to send a wakeup. However, this would add a bit of overhead on every timer interaction, which feels rather costly for what is really a problem only at shutdown. Moreover, it seems that the event manager (e.g. `GHC.Event.Manager`) is also afflicted by a similar race. This patch instead simply tries to catch the write failure after it has happened and silence it in the case that the fd has vanished. It feels rather hacky but it seems to work. Test Plan: Run `setnumcapabilities001` repeatedly Reviewers: hvr, austin, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2957 GHC Trac Issues: #12038 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5553#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14176: sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted"
by GHC 02 Sep '17

02 Sep '17

#14176: sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: kostmo | 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: -------------------------------------+------------------------------------- Given the following code (full Stack project attached): {{{#!haskell module Foo where import Data.List data MyRecord = MyRecord { f1 :: Maybe String , f2 :: Maybe String , f3 :: Maybe String , f4 :: Maybe String , f5 :: Maybe String , f6 :: Maybe String , f7 :: Maybe String , f8 :: Maybe String , f9 :: Maybe String , f10 :: Maybe String , f11 :: Maybe String , f12 :: Maybe String } getComparisonValue x = ( f1 x , f2 x , f3 x , f4 x , f5 x , f6 x , f7 x , f8 x , f9 x ) doSort = sortOn getComparisonValue }}} The following error results: {{{ $ stack build ghc-bug-0.0.0: build (lib) Preprocessing library ghc-bug-0.0.0... [1 of 1] Compiling Foo ( Foo.hs, .stack-work/dist/x86_64 -linux-nopie/Cabal-1.24.2.0/build/Foo.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $j_s72t To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 324566 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package ghc-bug-0.0.0 using: /home/kostmo/.stack/setup-exe-cache/x86_64-linux-nopie/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64 -linux-nopie/Cabal-1.24.2.0 build lib:ghc-bug --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} Generating a tuple from elements of an object for the purpose of sorting is an idiom I have used in Python at times. The original use case in Haskell for me was excluding some fields of the record in the comparison (e.g. `f10`, `f11`, `f12` fields), rather than using a simple `sort` with `deriving Ord` on `MyRecord`. I worked around the issue for now by blanking out the record fields I with to ignore, instead of re-instantiating a tuple of field values: {{{#!haskell getComparisonValue x = x { f10 = Nothing , f11 = Nothing , f12 = Nothing } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0
by GHC 01 Sep '17

01 Sep '17

#14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Angerman points out on [[https://mail.haskell.org/pipermail/ghc- devs/2017-September/014572.html|ghc-devs]] a rather frightenin-looking regression involving integer constant folding. It seems that 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 flipped the order of arguments in the constant-folding logic for binary-operations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14177: initTc: unsolved constraints
by GHC 01 Sep '17

01 Sep '17

#14177: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: satnam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC asked me to report this is a bug... so I am just doing what I am told. ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] cValues_abIT :: t_abIS[tau:1] (CHoleCan: cValues)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1