February 2017 - ghc-tickets

[GHC] #11006: Warning: Glomming in Main
by GHC 07 Mar '17

07 Mar '17

#11006: Warning: Glomming in Main -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 Travis build bot is reporting a test failure with debugging on, relating to glomming: {{{ Actual stderr output differs from expected: --- /dev/null 2015-01-28 16:31:58.000000000 +0000 +++ ./lib/integer/integerConstantFolding.run.stderr.normalised 2015-10-22 20:31:03.287376925 +0000 @@ -0,0 +1,2 @@ +WARNING: file compiler/simplCore/OccurAnal.hs, line 66 + Glomming in Main: [s3k0 :->, s3kc :->, s3kq :->, s3kr :->] \ No newline at end of file *** unexpected failure for integerConstantFolding(normal) }}} Full log https://s3.amazonaws.com/archive.travis- ci.org/jobs/86899099/log.txt -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13130: atomicModifyMutVar# has incorrect type
by GHC 06 Mar '17

06 Mar '17

#13130: atomicModifyMutVar# has incorrect type -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- this ticket specifically, currently we only expose in ghc-prim {{{ atomicModifyMutVar# :: MutVar# s a -> (a -> b) -> State# s -> (# State# s,c #) }}} is the type more like the following? {{{ atomicModifyMutVar# :: MutVar# s a -> (a -> (#a,b #)) -> State# s -> (# State# s,b #) }}} looking at GHC.IOREF {{{ atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b atomicModifyIORef (IORef (STRef r#)) f = IO $ \s -> atomicModifyMutVar# r# f s }}} it seems that either way, something screwy is afoot i'm not sure where the spurious c type variable comes from -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

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

06 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 06 Mar '17

06 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 06 Mar '17

06 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 06 Mar '17

06 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 06 Mar '17

06 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 06 Mar '17

06 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

[GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD
by GHC 06 Mar '17

06 Mar '17

#13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Git HEAD of containers compiles fine with ghc-8.0.1, but when compiling with GHC git HEAD gives core lint errors: {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) *** <no location info>: warning: In the expression: tagToEnum# @ Bool (reallyUnsafePtrEquality# @ (Set a) l'_a4Fk l_a4Fi) This argument does not satisfy the let/app invariant: reallyUnsafePtrEquality# @ (Set a) l'_a4Fk l_a4Fi *** Offending Program *** Rec { $dTypeable_s9vn :: Proxy# Set -> TypeRep }}} This issue can be reproduced using: {{{ (cd libraries/containers ; git checkout master ; git pull) perl boot && ./configure && make clean && make -j }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #13329: Windows CMD.EXE "Quick Edit Mode"
by GHC 05 Mar '17

05 Mar '17

#13329: Windows CMD.EXE "Quick Edit Mode" -------------------------------------+------------------------------------- Reporter: irongremlin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: clipboard, | Operating System: Windows quick edit | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Behavior: When a compiled haskell executable launches into a windows 7 'cmd.exe' terminal session, it does not respect the users 'quick edit mode' setting, and launches with the system default setting instead. I have not replicated this issue on other versions of windows. Details: For a description of the feature behavior, see: https://blogs.msdn.microsoft.com/adioltean/2004/12/27/useful-copypaste- trick-in-cmd-exe/ The registry key entry controlling this setting is: HKEY_CURRENT_USER\Console\QuickEdit (1 == on, 0 ==off) Tiny illustrative program: main :: IO () putStrLn "Try to copy this text" >>=(\_ -> getLine) >>= putStrLn Additional notes: The workaround is pretty simple, launch the program from a .bat script - cmd /K myscript.exe Or from inside an existing cmd.exe session, and the problem goes away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13329> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2