- ghc-tickets - Haskell.org

[GHC] #13370: exprIsBottom inconsistend with strictness analyser
by GHC 07 Mar '17

07 Mar '17

#13370: exprIsBottom inconsistend with strictness analyser -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Because of `Note [IO hack in the demand analyser]` (which I hate), an expression like {{{ f :: Int -> State# RealWorld -> (# State# RealWorld, Int #) f x s = case blah of (# s::State# RealWorld, r::() #) -> error (show x) }}} is not reported as a bottoming function by the strictness analyser. But `exprBotStrictness_maybe` will say that the RHS ''is'' bottoming. That ultimately comes from `CoreArity.arityType` which has no analogous hack to the demand analyser. These can't both be right! We could * Cripple `exprBotStrictness_maybe` a bit by adding the hack there too. * Weaken the hack so that it propagates divergence. The demand-analyser hack note says {{{ {- Note [IO hack in the demand analyser] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There's a hack here for I/O operations. Consider case foo x s of { (# s, r #) -> y } Is this strict in 'y'? Normally yes, but what if 'foo' is an I/O operation that simply terminates the program (not in an erroneous way)? In that case we should not evaluate 'y' before the call to 'foo'. Hackish solution: spot the IO-like situation and add a virtual branch, as if we had case foo x s of (# s, r #) -> y other -> return () So the 'y' isn't necessarily going to be evaluated A more complete example (Trac #148, #1592) where this shows up is: do { let len = <expensive> ; ; when (...) (exitWith ExitSuccess) ; print len } }}} I wonder if we could weaken the hack so that it propagated divergence /exception-thowing, while still making mentioned variables lazy. The big reason I'd like to do this is if we have {{{ case f x s of (# s',r #) -> BIG }}} then I really want to discard the alternative (since `f x s` is guaranteed to throw an exception) to give {{{ case f x s of {} }}} This is absolutely kosher; no change in evaluation order or anything. But weakening the IO hack in this way can change strictness. For example {{{ g A x y z s = x `seq` y `seq` (# s, () #) g B x y z s = x `seq` case blah2 of (# s', _ #) -> y `seq` (# s', () #) g C x y z s = case blah of (# s', _ #) -> error (show z) }}} Currently we treat this as lazy in x,y and z. With the above change, it'd become strict in `x` but not `y` or `z`, which is a little weird. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5611: Asynchronous exception discarded after safe FFI call
by GHC 07 Mar '17

07 Mar '17

#5611: Asynchronous exception discarded after safe FFI call -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.0.3 Resolution: | Keywords: FFI, | exception, Exceptions 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: FFI, exception => FFI, exception, Exceptions -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5611#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5611: Asynchronous exception discarded after safe FFI call
by GHC 07 Mar '17

07 Mar '17

#5611: Asynchronous exception discarded after safe FFI call -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.0.3 Resolution: | Keywords: FFI, | exception 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: 7.2.1 => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5611#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3094: Some GHC.* module should export word size and heap object header size
by GHC 07 Mar '17

07 Mar '17

#3094: Some GHC.* module should export word size and heap object header size -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries | Version: 6.10.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: 6.12.1 => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3094#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows
by GHC 07 Mar '17

07 Mar '17

#13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Commit c8d995db5d743358b0583fe97f8113bf9047641e in ghc bumped the `time` submodule to the latest version 4eb06c0e (`time-1.8`). But it caused a Core Lint error while compiling `Distribution.Compat.Time`, in the Cabal library: {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** <no location info>: warning: In the expression: $wsystemToUTCTime (case lvl_sdDL of v_B1 { I# v_B2 -> v_B2 }) (case lvl_sdDM of v_B1 { W# v_B2 -> v_B2 }) This argument does not satisfy the let/app invariant: case lvl_sdDL of v_B1 { I# v_B2 -> v_B2 } }}} See https://phabricator.haskell.org/harbormaster/build/21371/ for the full build log. For now the submodule bumps have been reverted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13349: Make GHC handle orphan COMPLETE sets of conlikes better
by GHC 07 Mar '17

07 Mar '17

#13349: Make GHC handle orphan COMPLETE sets of conlikes better -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Like orphan rewrite rules, it's possible to define orphan `COMPLETE` sets. For instance: {{{#!hs module Foo where {-# COMPLETE False #-} }}} I suppose that we could define an orphan `COMPLETE` set as one that lives in a module where none of the conlikes are defined (or should we say "where one or more of the conlikes are not defined"? I'm not sure.) Like orphan `RULES`, orphan `COMPLETE` sets are important to track properly when transitively reading from interface files, as failing to bring an orphan `COMPLETE` set into scope could affect pattern-match exhaustivness warnings that users see. After discussing this with rwbarton and mpickering IRC, we decided that one of the two should happen: 1. Treat orphan `COMPLETE` sets like orphan `RULES`. That is, mark a module as an orphan if it defines an orphan `COMPLETE` set, and thread a "`COMPLETE` pragma visibility" state through various places. 2. Disallow orphan `COMPLETE` sets entirely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13350: COMPLETE sets aren't read from external packages
by GHC 07 Mar '17

07 Mar '17

#13350: COMPLETE sets aren't read from external packages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you define these two modules: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo where data KindRep = KindRepTyConApp | KindRepVar | KindRepApp | KindRepFun | KindRepTYPE | KindRepTypeLitS | KindRepTypeLitD pattern KindRepTypeLit :: KindRep pattern KindRepTypeLit = KindRepTypeLitD {-# COMPLETE KindRepTyConApp, KindRepVar, KindRepApp, KindRepFun, KindRepTYPE, KindRepTypeLit #-} }}} {{{#!hs module Bar where import Foo krInt :: KindRep -> Int krInt KindRepTyConApp{} = 0 krInt KindRepVar{} = 1 krInt KindRepApp{} = 2 krInt KindRepFun{} = 3 krInt KindRepTYPE{} = 4 krInt KindRepTypeLit{} = 5 }}} And you compile `Bar.hs` with `-Wall` on, it will not emit any pattern- match exhaustiveness warnings, as expected. However, something different happens if you import all of these `KindRep` conlikes from `Type.Reflection.Unsafe` instead: {{{#!hs module Bar where import Type.Reflection.Unsafe krInt :: KindRep -> Int krInt KindRepTyConApp{} = 0 krInt KindRepVar{} = 1 krInt KindRepApp{} = 2 krInt KindRepFun{} = 3 krInt KindRepTYPE{} = 4 krInt KindRepTypeLit{} = 5 }}} {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive -Wall Bar.hs GHCi, version 8.1.20170228: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bar ( Bar.hs, interpreted ) Bar.hs:6:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘krInt’: Patterns not matched: (KindRepTypeLitS _ _) (KindRepTypeLitD _ _) | 6 | krInt KindRepTyConApp{} = 0 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} When the `COMPLETE` set is defined in a module in an //external package// (`base:Type.Reflection.Unsafe`, in this example), GHC doesn't properly take it into account when emitting pattern-match exhaustiveness warnings! This makes `COMPLETE` sets not terribly useful in practice at the moment. (NB: `Type.Reflection.Unsafe`'s definitions of `KindRepTyConApp` //et al.// aren't quite the same as what I defined above, but their exact definitions aren't important here, just that they have the same names and `COMPLETE` set. And this is the only `COMPLETE` set that I could defined in the boot libraries at the moment, making it convenient to use.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13174: Fix mismatch between unsafeDupablePerformIO and note
by GHC 07 Mar '17

07 Mar '17

#13174: Fix mismatch between unsafeDupablePerformIO and note -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.1 Libraries | 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: -------------------------------------+------------------------------------- `ghc/libraries/base/GHC/IO/Unsafe.hs` contains the following note: {{{ -- Note [unsafeDupablePerformIO is NOINLINE] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Why do we NOINLINE unsafeDupablePerformIO? See the comment with -- GHC.ST.runST. Essentially the issue is that the IO computation -- inside unsafePerformIO must be atomic: it must either all run, or -- not at all. If we let the compiler see the application of the IO -- to realWorld#, it might float out part of the IO. }}} However, `unsafeDupablePerformIO` does not actually have a `NOINLINE` pragma. So either the note is out of date and should be removed/modified, or someone messed up the code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11076: Demand information of foreign calls is wrong
by GHC 07 Mar '17

07 Mar '17

#11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Foreign calls of all types (including prim calls) use `mkFCallId` to create a fresh `Id` for each one. This Id claims to be strict in all arguments, which is not correct for foreign calls that allow lifted types to be passed. This also causes some trouble for GHCJS. I hope to get a fix in 7.10.3. Can we leave the strictness sig out entirely perhaps? Most arguments would be trivially strict since they're unboxed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11076> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13141: Don't check for Perl in ./configure when not splitting objects
by GHC 07 Mar '17

07 Mar '17

#13141: Don't check for Perl in ./configure when not splitting objects -------------------------------------+------------------------------------- Reporter: dobenour | Owner: dobenour Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- GHC needs Perl for exactly two reasons: - To run `boot` and the Autotools - For the splitter As such, there is no reason to check for Perl in `./configure` unless split-objs is supported. Even then, Perl is optional. The current check most likely comes from the days of the Evil Mangler. I'll take this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2