July 2016 - ghc-tickets

[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] #12019: Profiling option -hb is not thread safe
by GHC 01 Oct '16

01 Oct '16

#12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11978, #12009 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is a continuation of #11978 and #12009. After fixing a couple of issues in those two tickets I found that the profiling run time is not thread safe. Have a trivial test program (written as one of the tests for #11978): {{{ import Control.Concurrent import Control.Concurrent.MVar import Control.Exception import Control.Monad main :: IO () main = do putStrLn "Start ..." mvar <- newMVar (0 :: Int) let count = 50 forM_ [ 1 .. count ] $ const $ forkIO $ do threadDelay 100 i <- takeMVar mvar putMVar mvar $! i + 1 threadDelay 1000000 end <- takeMVar mvar putStrLn $ "Final result " ++ show end assert (end == count) $ return () }}} Compiling that with a compiler that has bug fixes arising from #11978 and #12009 as: {{{ inplace/bin/ghc-stage2 testsuite/tests/profiling/should_run/T11978b.hs \ -fforce-recomp -rtsopts -fno-warn-tabs -O -prof -static -auto-all \ -threaded -debug -o T11978b }}} and run as: {{{ ./T11978b +RTS -p -hb -N10 }}} crashes in a number of different ways. I've seen at least 3 different assertion failures and numerous segfaults (in different `stg_ap_*` functions). Replace `-hb` with other profiling options like `-hr` etc do not seem to crash. Looking at code, one example of lack of thread safetly is the function `LDV_recordDead` which mutates global variable `censuses` which does not have any locking around it. Only figured this out because the following assert (in `LDV_recordDead`) was being triggered occasionally. {{{ ASSERT(censuses[t].void_total < censuses[t].not_used); }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10740: Ensure that ticky, profiler, and GC allocation numbers agree
by GHC 30 Sep '16

30 Sep '16

#10740: Ensure that ticky, profiler, and GC allocation numbers agree -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | 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 Revisions: | -------------------------------------+------------------------------------- Currently we have several subsystems independently tracking allocations. It is very likely there are discrepancies between them. Ensuring that they agree would be a great way to test each of them (especially ticky, which is almost certainly bitrotted, see #10739). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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] #11461: Allow pattern synonyms to be bundled with type classes?
by GHC 26 Sep '16

26 Sep '16

#11461: Allow pattern synonyms to be bundled with type classes? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- One can very nearly get associated pattern synonyms by defining suitably polymorphic pattern synonyms. However, they are not quite associated as there's no way to bundle them with the class. This isn't as good as "proper" support but it would be an easy thing to implement for now if people think it worthwhile. For a concrete example, `Null` is an associated pattern synonym in this style but the following program doesn't compile because it is disallowed to bundle a pattern synonym with a type class. {{{ {-# LANGUAGE PatternSynonyms #-} module Foo(Nullable(Null)) where import Data.Maybe class Nullable f where null :: f a -> Bool instance Nullable (Maybe a) where null = isNothing pattern Null :: Nullable f => f a pattern Null = (null -> True) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11461> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12231: Eliminate redundant heap allocations/deallocations
by GHC 25 Sep '16

25 Sep '16

#12231: Eliminate redundant heap allocations/deallocations -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The code generated by GHC sometimes places the Heap allocation and deallocation in a common path which has multiple sub-branches inside it. Some of those branches may not need heap at all and it just checks allocates and deallocates it without using. This adds unnecessary overhead and becomes significant when the loop is small and runs very frequently. Instead of putting the heap allocation code at a higher level branch we can move it to more specific branches where it is really needed so that it gets out of the paths which do not need it. I am attaching a specific example of such a case. The code used here is in a public github repository [2]. It should be quite easy to play with it, there are detailed instructions along with the code to reproduce and investigate the issue. The files referenced in the following text are attached with this ticket. They are available in the github repo as well. Look at the CMM trace in `decompose-loop-execution-trace.cmm` and `decompose-loop-full.cmm`, start at label `c4ic` where we allocate space on heap (+48). There are multiple possible paths from this point on, some of those use the heap and some don't. Some interesting paths are: {{{ 1) c4ic (allocate) -> c4mw -> {c4pv} -> ... 2) c4ic (allocate) -> c4mw -> c4pw -> ((c4pr -> ({c4pe} -> ... | c4ph -> ...)) | cp4ps -> ...) }}} I have put those which use the heap inside curly braces, the rest do not use it at all. The paths which actually need the heap are rarely executed in this case. But because of the placement it is always allocated and deallocated in a the fast path which is executed almost all the time. If we can place this allocation at both `c4pv` and `c4pe` instead of the common parent then we can save the fast path from this check. The same thing applies to the allocation at label `c4jd` as well. The whole loop is composed on 51 instructions (ghc-8.0.1) and 8 of them are heap adjustment related, which comes out to almost 16%. If I can get this back then the performance of this loop will get quite close to the gcc compiled code which is currently around 30% faster. This is a CMM level optimization which will benefit all architectures. I also noticed that llvm removed the heap adjustment though not the checks. == References == * [1] mail thread - https://mail.haskell.org/pipermail/ghc- devs/2016-June/012275.html * [2] github repo for code, traces, reproduction details. See the GHC_PERF_ISSUE directory. - https://github.com/harendra-kumar/unicode- transforms/tree/GHC_PERF_ISSUE -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12231> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEV
by GHC 24 Sep '16

24 Sep '16

#11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEV ----------------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 4820 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- on my 4 core macbook pro i can reliably get a sigsev when running the shake test suite with profiling enabled and the RTS flags +RTS -hb -N10 steps to reproduce (with either ghc 7.10.3 or an 8.0 RC4 build) {{{ cabal get --source shake cd shake # shake master was commit f0c0ce8d4c2c017b9a26b5d4258e07d881f4cde1 as of time of testing # but problem should happen with eg 0.15.6 too cabal install # this is so that the shake test suite can fine the right template file cabal install --only-dep --enable-tests --enable-profiling ./dist/build/shake-test/shake-test +RTS -hb -N10 }}} this last command yields the error {{{ ****************************************************************** ** Running shake test suite, run with '--help' to see arguments ** ****************************************************************** fish: './dist/build/shake-test/shake-t…' terminated by signal SIGSEGV (Address boundary error) }}} i can also trigger the bug reported in #4820 by running the test suite with the -hr flag rather than -hb I'm marking this as HIGHEST so it can be discussed, because the profiiling build of the shake test suite only seems to crash *if* the test suite is run with -hb or -hr flags, which seems like a pretty nasty bug (which colleagues have it in other code) nb: `./dist/build/shake-test/shake-test +RTS -N10 ` runs into a not enough stack space error before the shake test suite completes, but `./dist/build/shake-test/shake-test +RTS -K1G -N10 ` seems to work fine, though the crashes happen super early in the gargantuan test suite the analogous output for reproducing #4820 is : {{{ ./dist/build/shake-test/shake-test +RTS -hr -N10 ****************************************************************** ** Running shake test suite, run with '--help' to see arguments ** ****************************************************************** Longest file modification time lag was 1005ms ## BUILD tar test ## TESTING tar ## BUILD tar --abbrev=output=$OUT -j3 Writing report to $OUT/tar/report.html Build completed in 0:01m ## BUILD tar --no-build --report=- Warning: No want/action statements, nothing to do Writing report to output/tar/report.html Writing report to - * This database has tracked 1 runs. * There are 4 rules (4 rebuilt in the last run). * Building required 1 traced commands (1 in the last run). * The total (unparallelised) time is 0.01s of which 0.01s is traced commands. * The longest rule takes 0.01s (output/tar/result.tar), and the longest traced command takes 0.01s (tar). * Last run gave an average parallelism of 0.44 times over 0.01s. Build completed in 0:01m ## BUILD tar Writing report to output/tar/report.html Build completed in 0:01m ## FINISHED TESTING tar ## BUILD self test ## TESTING self ## BUILD self --abbrev=output=$OUT -j3 Writing report to $OUT/self/report.html Build completed in 0:01m ## BUILD self --no-build --report=- Warning: No want/action statements, nothing to do Writing report to output/self/report.html Writing report to - * This database has tracked 2 runs. * There are 460 rules (2 rebuilt in the last run). * Building required 56 traced commands (1 in the last run). * The total (unparallelised) time is 22.73s of which 22.33s is traced commands. * The longest rule takes 1.11s (output/self/Development/Shake/Types.o output/self/Development/Shake/Types.hi), and the longest traced command takes 1.11s (ghc). * Last run gave an average parallelism of 0.78 times over 0.05s. Build completed in 0:01m ## BUILD self shake-test: internal error: Invalid object in isRetainer(): 39 (GHC version 8.0.0.20160421 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[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