- ghc-tickets - Haskell.org

[GHC] #16145: runghc with -fobject-code and -osuf fails to find dependencies
by GHC 07 Jan '19

07 Jan '19

#16145: runghc with -fobject-code and -osuf fails to find dependencies -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- F.hs: {{{#!hs module F where import G main = g }}} G.hs: {{{#!hs module G where g = print () }}} Running: {{{ $ runghc --version runghc 8.6.2 $ runghc -- -fobject-code -osuf=hs.o F *** Exception: G.hs.o: getModificationTime:getFileStatus: does not exist (No such file or directory) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16145> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16142: RTS statistic TASKS is not documented
by GHC 07 Jan '19

07 Jan '19

#16142: RTS statistic TASKS is not documented -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.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: -------------------------------------+------------------------------------- The RTS has a output TASKS which is not documented under http://downloads.haskell.org/~ghc/master/users-guide/runtime_control.html #rts-options-to-produce-runtime-statistics / http://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/runtime_contr… #rts-options-to-produce-runtime-statistics -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16142> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16039: 'GHC.Magic.noinline <var>' should not float out
by GHC 07 Jan '19

07 Jan '19

#16039: 'GHC.Magic.noinline <var>' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Keywords: FloatOut | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15155 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on #15155, I discovered that the magic function `GHC.Magic.noinline` tricked the float-out transformation into performing undesirable operations: Looking at the Core produced: {{{#!hs { ghc-prim-0.5.3:GHC.Types.I# x_azMX [Dmd=<S,U>] -> case x_azMX of { __DEFAULT -> jump $j_sMly; 3674937295934324920# -> src<compiler/typecheck/TcTyClsDecls.hs:3561:9-35> check_ty_roles_sLb3 (src<compiler/typecheck/TcTyClsDecls.hs:3561:24-26> env_aqfK) (src<compiler/typecheck/TcTyClsDecls.hs:3561:28-31> role_aqfL) (ghc-prim-0.5.3:GHC.Magic.noinline @ Kind liftedTypeKind) } } }}} After simplification we end up with a toplevel variable basically redirecting to an imported variable. {{{#!hs -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} lvl330_r12qn :: Kind [GblId] lvl330_r12qn = ghc-prim-0.5.3:GHC.Magic.noinline @ Kind liftedTypeKind }}} This would cause `IND_STATIC`s when eventually emitted as assembly. IIRC `GHC.Magic.noinline` was introduced with GHC v8.2. This probably regressed the float-out optimisation. I have a patch to reclassify `noinline <some-var>` as cheap, so that it won't be floated out. N.B.: for more details, see: https://github.com/ghc/ghc/pull/224 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16039> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round`
by GHC 07 Jan '19

07 Jan '19

#16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider this simple code: {{{#!hs {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -ddump-simpl -ddump-to-file -ddump-rule-firings #-} module C (f, g) where import Data.Int (Int64) f :: Double -> Int64 f = round g :: Double -> Int64 g = fromIntegral @Int @Int64 . round }}} There is a rule in {{{GHC.Int}}} that should translate {{{f}}} into {{{g}}} {{{#!hs "round/Double->Int64" round = (fromIntegral :: Int -> Int64) . (round :: Double -> Int) }}} If I compile the above module, I see {{{ Rule fired: round/Double->Int64 (GHC.Int) Rule fired: fromIntegral/a->Int64 (GHC.Int) Rule fired: fromIntegral/Int->Int (GHC.Real) Rule fired: fromIntegral/a->Int64 (GHC.Int) Rule fired: fromIntegral/Int->Int (GHC.Real) Rule fired: round/Double->Int (GHC.Float) }}} however in Core the functions end up different: {{{g}}} has an extra dictionary passed around: {{{#!hs -- RHS size: {terms: 11, types: 6, coercions: 0, joins: 0/0} f :: Double -> Int64 [GblId, Arity=1, Str=<S(S),1*U(U)>m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x_a1sG [Occ=Once!] :: Double) -> case x_a1sG of { GHC.Types.D# ww1_a28u [Occ=Once] -> case GHC.Float.$w$cround @ Int GHC.Real.$fIntegralInt ww1_a28u of { GHC.Types.I# x#_a1Rr [Occ=Once] -> GHC.Int.I64# x#_a1Rr } }}] f = \ (x_a1sG :: Double) -> case x_a1sG of { GHC.Types.D# ww1_a28u -> case GHC.Float.$w$cround @ Int GHC.Real.$fIntegralInt ww1_a28u of { GHC.Types.I# x#_a1Rr -> GHC.Int.I64# x#_a1Rr } } -- RHS size: {terms: 12, types: 14, coercions: 0, joins: 0/0} g :: Double -> Int64 [GblId, Arity=1, Caf=NoCafRefs, Str=<S(S),1*U(U)>m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x_X1sX [Occ=Once!] :: Double) -> case x_X1sX of { GHC.Types.D# ds1_a28C [Occ=Once] -> case {__pkg_ccall base-4.12.0.0 Double# -> State# RealWorld -> (# State# RealWorld, Double# #)}_a28B ds1_a28C GHC.Prim.realWorld# of { (# _ [Occ=Dead], ds3_a28H [Occ=Once] #) -> GHC.Int.I64# (GHC.Prim.double2Int# ds3_a28H) } }}] g = \ (x_X1sX :: Double) -> case x_X1sX of { GHC.Types.D# ds1_a28C -> case {__pkg_ccall base-4.12.0.0 Double# -> State# RealWorld -> (# State# RealWorld, Double# #)}_a28B ds1_a28C GHC.Prim.realWorld# of { (# ds2_a28G, ds3_a28H #) -> GHC.Int.I64# (GHC.Prim.double2Int# ds3_a28H) } } }}} This makes it over an order of magnitude slower than what it should be! {{{ benchmarked f time 111.1 ns (109.1 ns .. 113.9 ns) 0.997 R² (0.996 R² .. 0.998 R²) mean 111.1 ns (110.4 ns .. 112.0 ns) std dev 2.724 ns (2.195 ns .. 3.271 ns) benchmarked g time 7.160 ns (7.104 ns .. 7.224 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 7.196 ns (7.171 ns .. 7.231 ns) std dev 100.5 ps (71.97 ps .. 153.8 ps) }}} I don't know why the dictionary is present in {{{f}}} but not in {{{g}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8326: Place heap checks common in case alternatives before the case
by GHC 07 Jan '19

07 Jan '19

#8326: Place heap checks common in case alternatives before the case ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | ------------------------------------+------------------------------------- We would like to have functions that check whether an `Int#` is a valid tag to represent `Bool` (see Note [Optimizing isTrue#] in ghc-prim): {{{ isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False isFalse# :: Int# -> Bool isFalse# 0# = True isFalse# _ = False }}} We could use them with comparison primops like this: {{{ f :: Int# -> Int f x | isTrue# (x ># 0#) = I# x | otherwise = -(I# x) }}} `isTrue#` is optimized away at the Core level: {{{ A.f = \ (x_aqM :: GHC.Prim.Int#) -> case GHC.Prim.># x_aqM 0 of _ { __DEFAULT -> GHC.Types.I# (GHC.Prim.negateInt# x_aqM); 1 -> GHC.Types.I# x_aqM } }}} but the code genrator produces very bad Cmm code, because it pushes heap checks into case alternatives: {{{ {offset cFd: // stack check if ((Sp + -16) < SpLim) goto cFr; else goto cFs; cFr: // not enough place on the stack, call GC R2 = R2; R1 = A.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; cFs: // scrutinize (x ># 0#) _sEU::I64 = R2; _sEV::I64 = %MO_S_Gt_W64(R2, 0); if (_sEV::I64 != 1) goto cFg; else goto cFo; cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cFo: // True branch Hp = Hp + 16; if (Hp > HpLim) goto cFv; else goto cFu; cFv: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFn; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8; cFn: // re-do the True branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFo; cFu: // RHS of True branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = _sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }}} This results in average 2.5% increase in binary size. By contrast, if we use `tagToEnum#` instead of `isTrue#` heap check will be placed before `case` expression and the code will be significantly shorter (this is done by a special case-on-bool optimization in the code generator - see #8317). What we would like to do here is: 1. compile case alternatives without placing heap checks inside them 2. each compiled alternative should return amount of heap it needs to allocate 3. code generator inspects amounts of heap needed by each alternative and either adds heap checks in alternatives or puts a single check before the case expression. Getting this right might be a bit tricky. 1. if all branches allocate some heap then we can just put a common heap check before the case. Note that we must allocate the higgest amount required by any of the alternatives and then alternatives that use less heap must retract the heap pointer accordingly. 2. if we have two alternatives, one of which allocates heap and the other does not, we should place the heap check only in the alternative that allocates the stack. This will solve #1498. 3. it is not clear to me what to do if we have combination of the above (more than one branch that allocates heap and at least one branch that does not). If we place heap check before the `case` expression we lose optimization of recursive functions and face the problem described in #1498. If we push heap checks into branches that allocate heap then we get code duplication, i.e. the problem that we're addressing in this ticket. I guess the only way to make correct decission here is to try different aproaches and measure their performance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8326> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #16126: Make -threaded the default
by GHC 07 Jan '19

07 Jan '19

#16126: Make -threaded the default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simon M writes back in 2016 > Related to this, I think it's about time we made -threaded the default. We could add a -single-threaded option to get back the old behaviour. > > There is a small overhead to using -threaded, but -threaded is also required to make a lot of things work (e.g. waitForProcess in a multithreaded program, not to mention parallelism). All that needs doing is to add a flag `-single-threaded` to enable the old behaviour and a deprecation warning alerting uses that `-threaded` is the new default. https://mail.haskell.org/pipermail/ghc-devs/2016-October/013101.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics
by GHC 06 Jan '19

06 Jan '19

#1171: GHC doesn't respect the imprecise exceptions semantics -------------------------------------+------------------------------------- Reporter: neil | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: cg059 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edmundnoble): Now that there's a testcase verifying that the original YHC code is currently compiled correctly, should I assume that the issue of the compiler not distinguishing different `error`s in different `case` branches is fixed? Testing the example given in comment9 shows it still behaves the same way, which seems to imply that it isn't and the YHC code working is a fluke. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1171#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16138: Export GHC.TypeNats.natSing for TypeApplications
by GHC 06 Jan '19

06 Jan '19

#16138: Export GHC.TypeNats.natSing for TypeApplications -------------------------------------+------------------------------------- Reporter: HateUsernames | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 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: -------------------------------------+------------------------------------- Now that TypeApplications is available `natSing` can be exposed so that it can be directly used like `natSing @n`. This allows for Proxy not to be used. http://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.TypeNats.html… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16097: Bad error message for a misaligned case block in a do-let expression
by GHC 06 Jan '19

06 Jan '19

#16097: Bad error message for a misaligned case block in a do-let expression -------------------------------------+------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs main = do code <- getCode let value = case code of 1 -> 2 3 -> 4 _ -> 5 print value }}} This is a parse error, as the indent of the case statements is under the indent introduced by let. However, the error message on 8.6 onwards is very misleading: {{{ /home/dkr/example/Bad.hs:2:8: error: Unexpected do block in function application: do code <- getCode let value = ... You could write it with parentheses Or perhaps you meant to enable BlockArguments? | 2 | main = do | ^^... }}} Compare this with 8.4, which is a bit less bad: {{{ /home/dkr/example/Bad.hs:5:6: error: parse error on input ‘1’ | 5 | 1 -> 2 | ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16097> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16137: unhelpful parse error message: Unexpected do block in function application
by GHC 06 Jan '19

06 Jan '19

#16137: unhelpful parse error message: Unexpected do block in function application -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | 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: -------------------------------------+------------------------------------- Not a bug, as ghc correctly rejects an invalid program. But I have the impression that the error message is getting less precise (for reason and location) from 8.4 to 8.6: {{{ foo = do let x = case y of Nothing -> True bar }}} 8.6.3 says {{{ P.hs:1:7: error: Unexpected do block in function application: do let x = ... You could write it with parentheses Or perhaps you meant to enable BlockArguments? | 1 | foo = do | ^^... }}} I am not seeing what application ghc thinks of. 8.4.4 had the more useful {{{ P.hs:3:5: error: parse error on input ‘Nothing’ | 3 | Nothing -> True | ^^^^^^^ }}} More useful, since in the actual code, from which I distilled the above, there were a dozen lines between the locations that were reported by 8.6.3 and 8.4.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1