March 2015 - ghc-tickets

[GHC] #9717: More lazy orphan module loading
by GHC 14 Oct '16

14 Oct '16

#9717: More lazy orphan module loading -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: backpack | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, when we import a module, we eagerly load all of the orphan modules transitively reachable from it (TcRnDriver:tcRnImports). This is a bit of bummer: as module import hierarchies get deeper and deeper, we'll collect more and more orphan instances and load more and more modules eagerly. The idea is to try to arrange for an orphan module not to be loaded, unless we think that it might have a relevant instance. Instead of just recording a list of orphan modules transitively reachable from a module, we will also record a digest of what type classes and types the orphan provides instances for. (This will be similar to the data we record for `ifInstTys` in `IfaceClsInst`.) Now, when we do any operation involving instances, we check and see if there are also orphans which could provide relevant instances (based on the digest) and load those. If an instance could never have been used, we avoid loading its interface file entirely. This doesn't appear to help too much for type families, where we have to load all of the instances anyway in order to check for consistency. A choice to make: Should we record just the class, or also the types involved? It would be best if we could quickly conclude that there are no more instances to load, but this may be difficult if matching against types as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9877: ForeignImport coercion evaluated before typechecking
by GHC 09 Oct '16

09 Oct '16

#9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Under Windows 8.1 x64 with Haskell Platform 2014.02 and EclipseFP I got: buildwrapper.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): ForeignImport coercion evaluated before typechecking on the first line of file that has: {{{ #!div style="font-size: 80%" Code highlighting: {{{#!haskell {-# LANGUAGE ForeignFunctionInterface, RankNTypes, OverloadedStrings, ScopedTypeVariables #-} module Persist( persistWrite, persistRead ) where import System.Win32.Types import Graphics.Win32.GDI.Types import Foreign.C.String import Foreign.Marshal.Array import Control.Exception foreign import ccall unsafe "SHGetFolderPathW" cSHGetFolderPathW :: HWND -> INT -> HANDLE -> DWORD -> CWString -> IO LONG }}} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9877> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9547: Empty constraint tuples are mis-kinded
by GHC 06 Oct '16

06 Oct '16

#9547: Empty constraint tuples are mis-kinded -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider {{{ -- If :: forall k. 'Bool -> k -> k -> k type family If cond tru fls where If True tru fls = tru If False tru fls = fls foo :: If True () (Eq a) => a -> a foo = error "urk" }}} This should work fine. But we get {{{ Foo.hs:8:21: The third argument of `If' should have kind `*', but `Eq a' has kind `Constraint' In the type signature for `foo': foo :: If True () (Eq a) => a -> a }}} Reason: GHC is treating the `()` unit tuple as of kind `*`. Reason is that in the `HsTupleTy` case of `tc_hs_type` in `TcHsType`, we see {{{ -- In the [] case, it's not clear what the kind is, so guess * }}} And that guess is plain wrong in this case. Unfortunately I don't see an easy fix, but it's plain wrong as-is. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10163: Export typeRepKinds in Data.Typeable
by GHC 04 Oct '16

04 Oct '16

#10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc3 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that {{{TypeRep}}} has a {{{[KindRep]}}} field internally, {{{Data.Typeable}}} should export {{{typeRepKinds}}} (alongside {{{typeRepTyCon}}} and {{{typeRepArgs}}}, which are currently exported) to allow users to access it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits
by GHC 01 Oct '16

01 Oct '16

#8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ----------------------------+--------------------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- Windows shows a window that says "GHC has stopped working" when compiling a simple hello world. Steps to reproduce 1) Download GHC 7.8 RC2 (http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386 -unknown-mingw32.tar.bz2) 2) Extract the contents of the tar to folder $GHC$ 3) Add $GHC$\bin and $GHC$\mingw\bin folder to the PATH, add env var "LANG=C". 4) Create file test.hs with contents: main = putStrLn "Hello, World!" 5) run "ghc test.hs". Interestingly, the error is not deterministic, ie, after running the command several times the program gets compiled. When that happens, and ff the file test.o is not deleted, further attempts to compile run succesfully. GHCi appears to work normally (when doing simple tests). More details: http://stackoverflow.com/questions/22291739/cant-install-packages-with- cabal-using-ghc-7-8rc2-and-windows-7 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9520: Running an action twice uses much more memory than running it once
by GHC 29 Sep '16

29 Sep '16

#9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This started as a [http://www.haskell.org/pipermail/haskell- cafe/2014-August/115751.html Haskell cafe discussion] about conduit. This may be related to #7206, but I can't be certain. It's possible that GHC is not doing anything wrong here, but I can't see a way that the code in question is misbehaving to trigger this memory usage. Consider the following code, which depends on conduit-1.1.7 and conduit- extra: {{{#!hs import Data.Conduit ( Sink, (=$), ($$), await ) import qualified Data.Conduit.Binary as CB import System.IO (withBinaryFile, IOMode (ReadMode)) main :: IO () main = do action "random.gz" --action "random.gz" action :: FilePath -> IO () action filePath = withBinaryFile filePath ReadMode $ \h -> do _ <- CB.sourceHandle h $$ CB.lines =$ sink2 1 return () sink2 :: (Monad m) => Int -> Sink a m Int sink2 state = do maybeToken <- await case maybeToken of Nothing -> return state Just _ -> sink2 $! state + 1 }}} The code should open up the file "random.gz" (I simply `gzip`ed about 10MB of data from /dev/urandom), break it into chunks at each newline character, and then count the number of lines. When I run it as-is, it uses 53KB of memory, which seems reasonable. However, if I uncomment the second call to `action` in `main`, maximum residency shoots up to 45MB (this seems to be linear in the size of the input file. I additionally tried copying `random.gz` into two files, `random1.gz` and `random2.gz`, and changed the two calls to `action` to use different file names. It still resulted in large memory usage. I'm going to continue working to make this a smaller reproducing test case, but I wanted to start with what I had so far. I'll also attach the core generated by both the low-memory and high-memory versions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9349: excessive inlining with -fpre-inlining
by GHC 29 Sep '16

29 Sep '16

#9349: excessive inlining with -fpre-inlining --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ The program at https://gist.github.com/jorendorff/a3005968adc8f054baf7 runs very slowly when compiled with `-O` or higher. It seems that `arr` and/or `rangeMap` is being inlined into the do block on lines 89-91 and recomputed for each iteration of the loop. The program runs nearly instantly when compiled with `-O0` or with `-O -fno-pre-inlining`. (Of course, this does not mean `-fpre-inlining` is necessary the culprit; it could be enabling some subsequent misoptimization.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8774: Transitivity of Auto-Specialization
by GHC 28 Sep '16

28 Sep '16

#8774: Transitivity of Auto-Specialization -------------------------+------------------------------------------------- Reporter: | Owner: crockeea | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Linux Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: 5928, | 8668, 8099 | -------------------------+------------------------------------------------- From [http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/pragmas.html#idp4986… the docs]: [Y]ou often don't even need the SPECIALIZE pragma in the first place. When compiling a module M, GHC's optimiser (with -O) automatically considers each top-level overloaded function declared in M, and specialises it for the different types at which it is called in M. The optimiser also considers each imported INLINABLE overloaded function, and specialises it for the different types at which it is called in M. ... Moreover, given a SPECIALIZE pragma for a function f, GHC will automatically create specialisations for any type-class-overloaded functions called by f, if they are in the same module as the SPECIALIZE pragma, or if they are INLINABLE; and so on, transitively. So GHC should automatically specialize some/most/all(?) functions marked `INLINABLE` ''without'' a pragma, and if I use an explicit pragma, the specialization is transitive. My question is: is the ''auto''-specialization transitive? Either way, I'd like to see the docs updated to answer this question. Specifically, the attached files demonstrate a bug if auto-specialization ''should'' be transitive. Main.hs: {{{ #!haskell import Data.Vector.Unboxed as U import Foo main = let y = Bar $ Qux $ U.replicate 11221184 0 :: Foo (Qux Int) (Bar (Qux ans)) = iterate (plus y) y !! 100 in putStr $ show $ foldl1' (*) ans }}} Foo.hs: {{{ #!haskell module Foo (Qux(..), Foo(..), plus) where import Data.Vector.Unboxed as U newtype Qux r = Qux (Vector r) -- GHC inlines `plus` if I remove the bangs or the Baz constructor data Foo t = Bar !t | Baz !t instance (Num r, Unbox r) => Num (Qux r) where {-# INLINABLE (+) #-} (Qux x) + (Qux y) = Qux $ U.zipWith (+) x y {-# INLINABLE plus #-} plus :: (Num t) => (Foo t) -> (Foo t) -> (Foo t) plus (Bar v1) (Bar v2) = Bar $ v1 + v2 }}} GHC specializes the call to `plus`, but does *not* specialize `(+)` in the `Qux` `Num` instance. (In the attached core excerpt: `main6` calls `iterate main8`. `main8` is just `plus`, specialized for `Int`. So far so good. However, `splus` calls the *polymorphic* `c+`. If auto- specialization is transitive, I expect `c+` to be specialized to `Int`.) This kills performance: an explicit pragma `{-# SPECIALIZE plus :: Foo (Qux Int) -> Foo (Qux Int) -> Foo (Qux Int) #-}` results in ''transitive'' specialization as the docs indicate, so `(+)` is specialized and the code is 30x faster. Is this expected behavior? Should I only expect `(+)` to be specialized transitively with an explicit pragma? Note: this question is different from #5928 for two reasons: 1. I believe that no inlining is occuring, and hence I don't think inlining is interfering with specialization 2. I have `INLINABLE` pragmas on all relevant functions. Note: this question is different from #8668 because I am asking about ''auto''-specialization. This question was originally posted on [http://stackoverflow.com/questions/21502335/transitivity-of-auto- specialization-in-ghc StackOverflow]. As mentioned in the comments of that question, I am intentionally ''not'' fully applying the call to `plus` in Main, contrary to the suggestions in #8099. I'd love to see why I'm getting that behavior as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8523: blowup in space/time for type checking and object size for high arity tuples
by GHC 24 Sep '16

24 Sep '16

#8523: blowup in space/time for type checking and object size for high arity tuples -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Eric Mertens found a compilation performance issue in how GHC handles type class instance methods with many equality constraints and large arity tuples. basically using equality constraints to force 62 variables equal, instead of using the same variable for all the tuple slots, make the type checking time go from 0.9 seconds and very little memory to ~20 seconds and ~ 700mb of ram, along with going from ~ 7,000 coercions to 700,000-400,000 coercions, and object file size of 143kb to an object file size of 2.8mb-3.1mb I'm attaching 2 variants Tuple.hs and NeighborTuple.hs that exhibit the blowup behavior, and MonoTuple.hs (better named PolyTuple.hs but thats a side detail) that doesn't exhibit the blow up behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9421: magic number mismatch when installing 32bit on 64bit machine
by GHC 18 Sep '16

18 Sep '16

#9421: magic number mismatch when installing 32bit on 64bit machine -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Installing Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is basically the same problem as reported here: https://www.mail-archive.com/ghc-devs@haskell.org/msg04439.html I have empty .cabal and .ghc, no ghc in paths and I have old Ubuntu LTS (12.04.4) so I was able to install ia32-libs and a few other libs I've downloaded http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-i386-unknown-linux- deb7.tar.xz configured, and make install says: {{{ Installing library in /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell98-2.0.0.3 "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/haskell2010 dist-install "strip" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' 'v p dyn' Installing library in /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell2010-1.1.2.0 "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" --force --global-package-db "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21