January 2018 - ghc-tickets

[GHC] #14664: "GHC.Integer can't throw exceptions" is wrong
by GHC 13 Jan '18

13 Jan '18

#14664: "GHC.Integer can't throw exceptions" is wrong -------------------------------------+------------------------------------- Reporter: Zemyla | Owner: (none) Type: feature | Status: new request | Priority: low | 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: -------------------------------------+------------------------------------- The various integer packages, and anything else that might be loaded before the Prelude, goes through contortions to report errors, or else doesn't report them and crashes, because those packages are compiled before the `Exception` type is available. However, there is a way to throw exceptions from code that only has access to `ghc-prim`. It relies on the fact that the RTS itself throws an exception in a certain circumstance: when `atomically` is called from within `atomically`. This gives us the following: {{{#!hs {-# LANGUAGE MagicHash, UnboxedTuples, NoImplicitPrelude #-} import GHC.Prim import GHC.Magic atomicLoop :: State# RealWorld -> (# State# RealWorld, a #) atomicLoop s = atomically atomicLoop s exception :: a exception = runRW# (\s -> case atomicLoop s of (# _, a #) -> a) }}} I think that `integer-simple` and `integer-gmp`, and maybe the very earliest parts of `base`, are the only packages that would benefit from this circumlocution; however, having the error be a catchable exception rather than a straight-up crash has benefits. Priority is low because I don't think there have been any bugs regarding GHC.Integer crashing; I just think it might make the code a bit more elegant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14664> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 13 Jan '18

13 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I found your analysis instructive osa1, thank you. My current understanding is now that the cost-centres are, modulo bugs, removed when they aren't wrapping any work. I don't think we have any examples here of erroneous cost-centre removal, do you agree? As for how to implement alternative (2) in comment:10, Note [inline scc] summarises the difficulty: {{{ -- Note [inline sccs] -- -- It should be reasonable to add ticks to INLINE functions; however -- currently this tickles a bug later on because the SCCfinal pass -- does not look inside unfoldings to find CostCentres. It would be -- difficult to fix that, because SCCfinal currently works on STG and -- not Core (and since it also generates CostCentres for CAFs, -- changing this would be difficult too). }}} Could we collect SCCs from all unfoldings in `corePrepPgm`, and union them with the result of `myCoreToStg`? What could go wrong? Are there any pathological scenarios where large numbers of SCCs would be created? That would fix the bug alluded to in the note, so if we go forward with that idea let's not forget to update the note and create a ticket for the task of reevaluating the sites referencing said note. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14578: Incorrect parenthesization of types in -ddump-deriv
by GHC 13 Jan '18

13 Jan '18

#14578: Incorrect parenthesization of types in -ddump-deriv -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this program on GHC 8.2 or later: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where import Control.Applicative import Data.Functor.Compose import Data.Semigroup newtype App f a = MkApp (f a) deriving (Functor, Applicative) instance (Applicative f, Semigroup a) => Semigroup (App f a) where (<>) = liftA2 (<>) newtype Wat f g a = MkWat (App (Compose f g) a) deriving Semigroup }}} Will result in some incorrectly pretty-printed types in the `-ddump-deriv` output: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs -dsuppress-uniques GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: <elided for brevity> instance (Data.Semigroup.Semigroup a, GHC.Base.Applicative g, GHC.Base.Applicative f) => Data.Semigroup.Semigroup (Bug.Wat f g a) where (Data.Semigroup.<>) = GHC.Prim.coerce @(Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(Bug.Wat f g a -> Bug.Wat f g a -> Bug.Wat f g a) (Data.Semigroup.<>) Data.Semigroup.sconcat = GHC.Prim.coerce @(Data.List.NonEmpty.NonEmpty Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(Data.List.NonEmpty.NonEmpty Bug.Wat f g a -> Bug.Wat f g a) Data.Semigroup.sconcat Data.Semigroup.stimes = GHC.Prim.coerce @(forall (b :: TYPE GHC.Types.LiftedRep). GHC.Real.Integral b => b -> Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(forall (b :: TYPE GHC.Types.LiftedRep). GHC.Real.Integral b => b -> Bug.Wat f g a -> Bug.Wat f g a) Data.Semigroup.stimes }}} Notice that is shows `Bug.App Data.Functor.Compose.Compose f g a`, which is wrong. It should be `Bug.App (Data.Functor.Compose.Compose f g) a`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14640: Div and Mod type families don't have the same fixities as their term-level counterparts
by GHC 13 Jan '18

13 Jan '18

#14640: Div and Mod type families don't have the same fixities as their term-level counterparts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: | Version: 8.4.1-alpha1 libraries/base | 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: -------------------------------------+------------------------------------- Commit fa8035e3ee83aff5a20fc5e7e2697bac1686d6a6 added `Div` and `Mod` type families to `GHC.TypeNats`. However, they did not add the corresponding fixities! Currently, we have that both `div` and `mod` (at the value level) are `infixl 7`, so we should adopt the same fixities for the type- level `Div` and `Mod` as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 13 Jan '18

13 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): We discussed this with @bgamari on IRC and I did some experimenting with the flags, and I think this story makes sense: Answer to question "why are these cost centers eliminated in the definition site (in module B) but not in use site (in module A)" is because worker for `split` is not inlined in module A. It's inlined when I compile module B with `-fspec-constr`: {{{ Inlining done: B.$wsplit Inlined fn: \ (w :: GHC.Integer.Type.Integer) (w1 [Occ=Once!] :: GHC.Base.Maybe GHC.Integer.Type.Integer) -> case w1 of { GHC.Base.Nothing -> (# scc<split> B.plus_noinline w B.split3, scc<split> B.plus_noinline w B.split2 #); GHC.Base.Just m -> case scc<split> GHC.Integer.Type.eqInteger# w B.split1 of { __DEFAULT -> scc<split> B.split_$s$wsplit m (GHC.Integer.Type.minusInteger w B.split3); 1# -> (# m, m #) } } Cont: ApplyToVal nodup w ApplyToVal nodup w1 Select nodup ww Stop[BoringCtxt] (GHC.Integer.Type.Integer, GHC.Integer.Type.Integer) }}} with this I no longer get any linker errors. In comment:19 I said that `SpecConstr` pass doesn't actually change the program -- this is correct, we don't need `SpecConstr` in A, we need it in B to make the worker for `split` available in module A. Once we compile `B` with `-fspec-constr` the worker becomes available in when compiling `A`. Hopefully this explains. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 13 Jan '18

13 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > osa1, can you clarify what A is? It's the module A in the test case (testsuite/tests/profiling/should_compile/T5889/A.hs) and B is the module B. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 13 Jan '18

13 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > The same pass in A does nothing. osa1, can you clarify what `A` is? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 12 Jan '18

12 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I wonder if this could be related with inlining worker for `split`. This program {{{ import A {-# NOINLINE b #-} b :: Integer b = bar 100 Nothing }}} compiles to {{{ ds_r4vL :: (Integer, Integer) [GblId] ds_r4vL = scc<bar> scc<bar.(...)> case B.$wsplit n_r4u9 (GHC.Base.Nothing @ Integer) of { (# ww1_s2sg, ww2_s2sh #) -> (ww1_s2sg, ww2_s2sh) } b [InlPrag=NOINLINE] :: Integer [GblId] b = scc<bar> plus_noinline (scc<bar.y> case ds_r4vL of { (y_a2pz, z_a2pB) -> y_a2pz }) (scc<bar.z> case ds_r4vL of { (y_a2pz, z_a2pB) -> z_a2pB }) }}} and fails the same way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 12 Jan '18

12 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I just checked what simplifier pass optimizes these cost centers in the definition site, and then checked why the same pass does not optimize the same way in the use site. The pass is `post-worker-wrapper`. Before the pass `bar` looks like this: {{{ bar = \ (n_a1Gx :: Integer) (m_a1Gy [Dmd=<S,U>] :: Maybe Integer) -> scc<bar> let { ds_s2rs [Dmd=<S(SS),U(U,U)>] :: (Integer, Integer) [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] ds_s2rs = let { ds_s2rs [Dmd=<S(SS),U(U,U)>] :: (Integer, Integer) [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] ds_s2rs = scc<bar.(...)> split n_a1Gx m_a1Gy } in case ds_s2rs of ww_s2sc { (ww_s2sd [Dmd=<S,U>], ww_s2se [Dmd=<S,U>]) -> (ww_s2sd, ww_s2se) } in plus_noinline (scc<bar.y> case ds_s2rs of { (y_a2pz [Dmd=<S,U>], z_a2pB [Dmd=<L,A>]) -> y_a2pz }) (scc<bar.z> case ds_s2rs of { (y_a2pz [Dmd=<L,A>], z_a2pB [Dmd=<S,U>]) -> z_a2pB }) }}} after: {{{ bar = \ (n_a1Gx :: Integer) (m_a1Gy :: Maybe Integer) -> scc<bar> case scc<bar.(...)> split n_a1Gx m_a1Gy of { (ww_s2sd [Dmd=<S,U>], ww_s2se [Dmd=<S,U>]) -> plus_noinline ww_s2sd ww_s2se } }}} The same pass in `A` does nothing. The program before and after the pass looks like this: {{{ ds_s4uU :: (Integer, Integer) [LclId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 50 30}] ds_s4uU = scc<bar> scc<bar.(...)> case B.$wsplit n_s4uS (GHC.Base.Nothing @ Integer) of { (# ww1_s2sg, ww2_s2sh #) -> (ww1_s2sg, ww2_s2sh) } main_s37c :: String [LclId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 110 30}] main_s37c = case GHC.Show.$w$cshowsPrec4 0# (scc<bar> plus_noinline (scc<bar.y> case ds_s4uU of { (y_a2pz [Dmd=<S,U>], z_a2pB [Dmd=<L,A>]) -> y_a2pz }) (scc<bar.z> case ds_s4uU of { (y_a2pz [Dmd=<L,A>], z_a2pB [Dmd=<S,U>]) -> z_a2pB })) (GHC.Types.[] @ Char) of { (# ww3_a376, ww4_a377 #) -> GHC.Types.: @ Char ww3_a376 ww4_a377 } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 12 Jan '18

12 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I just realized that in the test program `-fspec-constr` eliminates the cost centers in the use site. So - `-O` fails, cost centers are there in the use site - `-O -fspec-constr` works -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0