January 2018 - ghc-tickets

[GHC] #12935: Object code produced by GHC is non-deterministic
by GHC 05 Mar '18

05 Mar '18

#12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: -------------------------------------+------------------------------------- This is a continuation of #4012, which made interface files deterministic. Now someone needs to make object code deterministic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #14701: Investigate the performance impact of code alignment
by GHC 03 Mar '18

03 Mar '18

#14701: Investigate the performance impact of code alignment -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (CodeGen) | 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: -------------------------------------+------------------------------------- Maybe ghc's performance also varies due to reasons like that: https://dendibakh.github.io/blog/2018/01/18/Code_alignment_issues The gist of the article is that tight loops can have significantly different performance depending on whether the location of the assembly instructions themselves cross a cache line. I would not have expected this to make double-digit percentage differences. From `#ghc`: {{{ bgamari: nh2[m], there are nofib tests where this is very likely the cause of a good portion of the variant angerman: nh2[m]: that linked LLVM talk from 2016 makes me not want to have to deal with that... AndreasK: nh2[m]: It's a real issue. But atm I think ghc at least in the native codegen make no real attempt to optimize for this thoughtpolice: GHC does not carry knowledge of alignment or anything, no. I’m not sure how difficult this is to suss out, but at least making sure every branch target does not cross a cache line is probably a good start thoughtpolice: Well, far jump, e.g. a call to a function. not sure how TNTC fits into this story, tbqh }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy
by GHC 02 Mar '18

02 Mar '18

#11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE PolyKinds, TypeOperators, DataKinds, TypeFamilies, GADTs #-} module Bug where data family Sing (a :: k) data Schema = Sch [Bool] data instance Sing (x :: Schema) where SSch :: Sing x -> Sing ('Sch x) data instance Sing (x :: [k]) where SNil :: Sing '[] SCons :: Sing a -> Sing b -> Sing (a ': b) data G a where GCons :: G ('Sch (a ': b)) eval :: G s -> Sing s -> () eval GCons s = case s of -- SSch SNil -> undefined SSch (SCons _ _) -> undefined }}} Upon seeing this, GHC says {{{ Bug.hs:21:9: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: (SSch SNil) }}} So I uncomment the second-to-last line, inducing GHC to say {{{ Bug.hs:22:16: error: • Couldn't match type ‘a : b’ with ‘'[]’ Inaccessible code in a pattern with constructor: SNil :: forall k. Sing '[], in a case alternative • In the pattern: SNil In the pattern: SSch SNil In a case alternative: SSch SNil -> undefined }}} Thankfully, this pattern is much rarer than it once was, but it's a bit sad that it's still possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11984> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14098: Incorrect pattern match warning on nested GADTs
by GHC 02 Mar '18

02 Mar '18

#14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language GADTs #-} data App f a where App :: f a -> App f (Maybe a) data Ty a where TBool :: Ty Bool TInt :: Ty Int data T f a where C :: T Ty (Maybe Bool) -- Warning f :: T f a -> App f a -> () f C (App TBool) = () -- No warning g :: T f a -> App f a -> () g C (App x) = case x of TBool -> () }}} When compiling, with `-Wincomplete-patterns`: {{{ Foo.hs:15:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘f’: Patterns not matched: C (App TInt) | 15 | f C (App TBool) = () | ^^^^^^^^^^^^^^^^^^^^ }}} I'm sorry for such a complicated example, but I wasn't able to reduce it any further than this. The gist of the problem is that this code gives a pattern matching non- exhaustiveness warning when matching a nested pattern, when pulling out a value then matching on it produces no warning (correctly). It also seems to have to do with using a type constructor (`Maybe`) within the constructor definition of `App`, as changing it to {{{#!hs data App f a where App :: f a -> App f a ... data T f a where C :: T Ty Bool }}} does not give a warning, even when `App` is modified further to force it to be a proper GADT. This might be a known limitation of the checker, but given that it works fine when the nesting is removed, I would think it would be more of a bug. Thanks to Iavor for helping me minimize the test case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14544: doCorePass has at least one missing case
by GHC 02 Mar '18

02 Mar '18

#14544: doCorePass has at least one missing case -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- There is a catch all at the end of `doCorePass` which hides the fact that `doCorePass` should be total. In particular `doCorePass` is not implemented for `CoreOccurAnal` and so either `CoreOccurAnal` should be removed from `CoreToDo` or implemented properly in `doCorePass`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14544> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12706: Collecting type info is slow
by GHC 02 Mar '18

02 Mar '18

#12706: Collecting type info is slow -------------------------------------+------------------------------------- Reporter: vshabanov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- With `:set +c` option in GHCi, I'm waiting for 10-15 seconds for {{{ Collecting type info for 34 module(s) ... }}} after both first load and subsequent reloads, even if only top-level module was modified. And GHCi uses about 1.5-2x more memory than it uses without `:set +c`. My app has about 30k lines of code. Is it expected behavior and some performance improvements are planned or it's a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later
by GHC 02 Mar '18

02 Mar '18

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As observed [https://github.com/ekmett/lens/issues/781#issuecomment-357841481 here], any attempt to run [https://hackage.haskell.org/package/doctest-0.13.0 doctest] on a module that contains an `ANN` will result in a segfault—but only under certain settings! To explain better what I mean, let's look at a stripped-down version of `doctest`: {{{#!hs -- Bug.hs module Main (main) where import Control.Applicative ((<|>)) import Control.Monad.IO.Class (liftIO) import Data.Char (isSpace) import Data.List (dropWhileEnd) import Digraph (flattenSCCs) import GHC (depanal, getSessionDynFlags, guessTarget, loadModule, noLoc, parseDynamicFlags, parseModule, runGhc, setSessionDynFlags, setTargets, topSortModuleGraph, typecheckModule) import System.Directory (findExecutable) import System.Process (readProcess) getLibDir :: IO FilePath getLibDir = do Just ghcPath <- findExecutable "ghc" <|> findExecutable "ghc-stage2" dropWhileEnd isSpace <$> readProcess ghcPath ["--print-libdir"] "" main :: IO () main = do libdir <- getLibDir putStrLn libdir runGhc (Just libdir) $ do (dynflags, _, _) <- getSessionDynFlags >>= flip parseDynamicFlags (map noLoc ["-package base"]) _ <- setSessionDynFlags dynflags mapM (`guessTarget` Nothing) ["Foo.hs"] >>= setTargets mods <- depanal [] False let sortedMods = flattenSCCs (topSortModuleGraph False mods Nothing) let f theMod = do liftIO $ putStrLn "Before parseModule" m1 <- parseModule theMod liftIO $ putStrLn "Before typecheckModule" m2 <- typecheckModule m1 liftIO $ putStrLn "Before loadModule" m3 <- loadModule m2 liftIO $ putStrLn "After loadModule" return m3 mods' <- mapM f sortedMods mods' `seq` return () }}} As well as a module with an `ANN`: {{{#!hs module Foo where {-# ANN module "I'm an annotation" #-} }}} If you attempt to compile and run `Bug.hs` with GHC 8.2.2, everything is fine and dandy: {{{ $ PATH=/opt/ghc/8.2.2/bin:$PATH ghc -fforce-recomp Bug.hs -package ghc [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ PATH=/opt/ghc/8.2.2/bin:$PATH ./Bug /opt/ghc/8.2.2/lib/ghc-8.2.2 Before parseModule Before typecheckModule Before loadModule After loadModule }}} But if these two criteria are met: * You're using GHC 8.4.1-alpha * You're using Ubuntu 16.04 or later Then this will result in a segfault! {{{ $ PATH=/opt/ghc/8.4.1/bin:$PATH ghc -fforce-recomp Bug.hs -package ghc [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ PATH=/opt/ghc/8.4.1/bin:$PATH ./Bug /opt/ghc/8.4.1/lib/ghc-8.4.0.20171222 Before parseModule Before typecheckModule Segmentation fault (core dumped) $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 17.04 Release: 17.04 Codename: zesty }}} The second criteria about Ubuntu version is the most baffling part, but the segfault does not appear to occur when I try it on, for instance, an Ubuntu 14.04 machine: {{{ $ PATH=/opt/ghc/8.4.1/bin:$PATH ghc -fforce-recomp Bug.hs -package ghc [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ PATH=/opt/ghc/8.4.1/bin:$PATH ./Bug /opt/ghc/8.4.1/lib/ghc-8.4.0.20171222 Before parseModule Before typecheckModule Before loadModule After loadModule $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins
by GHC 02 Mar '18

02 Mar '18

#12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building lambdabot-haskell-plugins, Lambdabot.Plugin.Haskell.Pl.Parser compiles without incident on the non- profiling run, but cripples the build machine on the profiling run. An excerpt of -v3 output is below to show the number of terms skyrocketing. *** Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Common sub-expression = {terms: 39,049, types: 30,851, coercions: 990} !!! Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 72.00 milliseconds, allocated 44.536 megabytes *** Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Float inwards = {terms: 39,049, types: 30,851, coercions: 990} !!! Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 68.00 milliseconds, allocated 60.337 megabytes *** Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Simplifier iteration=1 = {terms: 977,045, types: 299,334, coercions: 1,058} Result size of Simplifier iteration=2 = {terms: 926,036, types: 263,306, coercions: 932} Result size of Simplifier = {terms: 922,724, types: 262,202, coercions: 932} !!! Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 15480.00 milliseconds, allocated 9384.823 megabytes *** CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Tidy Core = {terms: 922,623, types: 261,789, coercions: 865} !!! CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 2060.00 milliseconds, allocated 613.585 megabytes writeBinIface: 95 Names writeBinIface: 259 dict entries *** CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of CorePrep = {terms: 1,128,145, types: 347,063, coercions: 865} !!! CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 3468.00 milliseconds, allocated 1718.453 megabytes *** Stg2Stg: *** CodeGen [Lambdabot.Plugin.Haskell.Pl.Parser]: -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array#
by GHC 28 Feb '18

28 Feb '18

#14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Just to be clear, there currently is nothing named `UnliftedArray#`. I would like to propose that such a thing possibly be added, with the long- term goal of deprecating and removing `ArrayArray#`. The interface for it would look like this: {{{#!hs data UnliftedArray# (a :: TYPE 'UnliftedRep) data MutableUnliftedArray# s (a :: TYPE 'UnliftedRep) indexUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). UnliftedArray# a -> Int# -> a writeUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). MutableUnliftedArray# s a -> Int# -> a -> State# s -> State# s readUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). MutableUnliftedArray# s a -> Int# -> State# s -> (# State# s, a #) unsafeFreezeUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). MutableUnliftedArray# s a -> State# s -> (#State# s, UnliftedArray# a#) newUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). Int# -> a -> State# s -> (# State# s, MutableUnliftedArray# s a #) }}} You would also have a few other things like `sameMutableUnliftedArray#`, `sizeofMutableArray#`, `unsafeThawUnliftedArray#`, `copyUnliftedArray#`, etc. The main difficulty that I see in doing this is that I'm not sure if you can tell a primop that it takes a polymorphic argument whose kind is something other than `TYPE LiftedRep`. The bodies of all of the functions I listed above could simply be copied from the `ArrayArray#` functions. There are a few alternatives I've heard discussed. One is to make `Array#` accepted both boxed or unboxed types. There is a brief discussion of this in the UnliftedDataTypes proposal [#point0 (0)]. Indeed, it appears that some have managed to smuggle unlifted data into `Array#` already, with the caveats one would expect [#point1 (1)]. This interface would look like: {{{#!hs data Array# (a :: TYPE k) data MutableArray# s (a :: TYPE k) indexArray# :: Array# a -> Int -> a -- same as before indexUnliftedArray# :: forall (a :: TYPE UnliftedRep). Array# a -> Int -> a }}} So instead of having `Array#` and `UnliftedArray#` as separate data types, we could have `Array#` handle both cases, but we would need to make a duplicate of every function that operates on `Array#`. This follows all of the appropriate rules for when levity polymorphism is allowed, and it should be backwards-compatible with the previous non-levity-polymorphic definition of `Array#`. I'm not sure how many things in the GHC runtime assume that the values inside an array are lifted, so this might cause a bunch of problems. If it is possible, this approach would be kind of neat because then `SmallArray#` could be similarly adapted. Anyway, I just wanted to get this out there. I would be happy to try implementing the first proposal (involving `UnliftedArray#`) at some point in the next six months. Any feedback on the idea would be appreciated. Also, any comments on how appropriate this is for someone new to contributing to GHC would be appreciated as well. Thanks. * [=#point0 (0)] https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Parametricity * [=#point0 (1)] https://www.reddit.com/r/haskell/comments/6v9rmg/an_unified_array_interface… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13075: Top-level bang pattern accepted
by GHC 27 Feb '18

27 Feb '18

#13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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: -------------------------------------+------------------------------------- When I compile/link {{{#!hs {-# LANGUAGE BangPatterns #-} module Main where !(Just x) = Nothing main = putStrLn "hi there!" }}} I get {{{ rae:09:50:49 ~/temp> ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... ld: can't open output file for writing: Bug, errno=21 for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) }}} This bogus code should be rejected more gracefully (and earlier). It actually also loads into GHCi, but shouldn't. Will fix while I'm in the area. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15