- ghc-tickets - Haskell.org

[GHC] #14414: Profiled program runs 2.5x faster than non-profiled
by GHC 23 Jul '18

23 Jul '18

#14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I was looking at benchmarks game (attached as fasta.ghc-2.hs). I have found that with the flags give there, this program on GHC 8.2.1 runs in about a second with `-prof -fprof-auto` and 2.5 seconds without! To run without profiling: {{{ ghc --make -Wall -fforce-recomp -fllvm -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -s -RTS 250000 > /dev/null }}} Same program with profiling {{{ ghc --make -fforce-recomp -fllvm -prof -fprof-auto -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -p -s -RTS 250000 > /dev/null }}} I also attach Core outputs for both profiled and unprofiled version. To me this seems very strange: profiled version is somehow faster. Perhaps what's worse is that this means that there's some optimisation GHC is performing when profiling is not on that makes the program a lot slower than it could be! This program is not minimised. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12714: T9405 fails on Windows
by GHC 22 Jul '18

22 Jul '18

#12714: T9405 fails on Windows --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The `T9405` testcase currently fails on Windows, {{{ }}} Contrary to what was suggested in ticket:12004#comment:3 it looks like the problem is that an empty `.ticky` file is produced. Even increasing the `sleep` time to 10 seconds (after bumping the sleep in `T9405.hs` accordingly) doesn't change this, so I suspect there is a runtime system bug here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9599: app runs 10 times faster when compiled with profilling information than without it
by GHC 21 Jul '18

21 Jul '18

#9599: app runs 10 times faster when compiled with profilling information than without it -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Solaris Architecture: x86 | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello, I've found interesting application code which when compiled with {{{ -O2 -threaded --make }}} runs 10 times slower than the same code compiled with {{{ -O2 -threaded --make -prof -auto-all -caf-all -fforce-recomp }}} the application is compiled by GHC 7.8.2 on i386-solaris2 platform. The profiling application is then run as normal application, i.e. without +RTS -p. The application itself is my crude beginner Haskell code which takes Wikipedia dump (XML file) and tries wiki pages from there import into XWiki using REST API. It uses Data.Text package for lazy load of Wikipedia data, whole logic of selection of page/title/content is done on Data.Text and later saved into XPage which is using ByteString. The application also uses Simon Marlow's Async/async/wait code which is copied from Simon Marlow's Parallel and Concurrent Programming in Haskell http://chimera.labs.oreilly.com/books/1230000000929 App attached. My question is, what to do with it to help finding the issue? E.g. I assume it's issue when profiling app is that much faster than common optimized app. For your information, optimized app takes 9m50s to upload 1000 pages while profiled optimized app takes only 50s to upload the same amount of pages on my equipped with E5-2620 (2 GHz 6 core/12 threads xeon) Also the difference in time is that big that it's not caused by a noise in import of pages on XWiki side. I've tested several times of course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9599> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15429: The docs for Unsafe.Coerce should recommend using Data.Coerce instead
by GHC 21 Jul '18

21 Jul '18

#15429: The docs for Unsafe.Coerce should recommend using Data.Coerce instead -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 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: -------------------------------------+------------------------------------- Currently there's no reference from `Unsafe.Coerce` to `Data.Coerce` at all. Unsuspecting people might use `unsafeCoerce` where `coerce` would also work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14242: Ticks and join points don't play well
by GHC 21 Jul '18

21 Jul '18

#14242: Ticks and join points don't play well -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Currently the presence of ticks appear to inhibit our ability to discover join points as described by this comment in `OccurAnal.occAnal`, {{{#!hs usage_lam = markAllNonTailCalled (markAllInsideLam usage) -- TODO There may be ways to make ticks and join points play -- nicer together, but right now there are problems: -- let j x = ... in tick<t> (j 1) -- Making j a join point may cause the simplifier to drop t -- (if the tick is put into the continuation). So we don't -- count j 1 as a tail call. }}} This causes spurious warnings when compiling with a `DEBUG` compiler and `-g` or profiling enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15409: Quantified constraints half-work with equality constraints
by GHC 21 Jul '18

21 Jul '18

#15409: Quantified constraints half-work with equality constraints -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Windows QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 15359 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Experimenting from the comments in ticket:15359 ... This is using 8.6.0.alpha2 20180714 {{{ {-# LANGUAGE QuantifiedConstraints #-} -- plus the usual suspects -- And over type-level Booleans class ((c ~ 'True) => (a ~ 'True), -- Surprise 1 (c ~ 'True) => (b ~ 'True)) => And' (a :: Bool) (b :: Bool) (c :: Bool) | a b -> c instance () -- Surprise 2 => And' 'True b b instance (('False ~ 'True) => (b ~ 'True)) -- Surprise 3 => And' 'False b 'False y :: (And' a b 'True) => () -- Surprise 4 y = () }}} 1. Those superclass constraints are accepted, with equalities in the implications. 2. The `And 'True b b` instance is accepted without needing further constraints. ?So GHC can figure the implications hold from looking at the instance head. 3. For the `And' 'False b 'False` instance, GHC can't figure the `(c ~ 'True) => (b ~ 'True)` superclass constraint holds. Just substituting into the implication from the instance head seems to satisfy it. So now we have a never-satisfiable antecedent. Rejection message if instance constraints omitted is {{{ * Could not deduce: b ~ 'True arising from the superclasses of an instance declaration from the context: 'False ~ 'True bound by a quantified context at ... }}} 4. The signature for `y` is rejected `Could not deduce (And' a0 b0 'True)`. (The message suggests `AllowAmbiguousTypes`, but that just postpones the error.) I was hoping the superclass constraints would spot that `c ~ 'True` and improve `a, b` from the implications. 5. No surprise that replacing all the `(~)` with `Coercible` produces the same rejections. 6. I did try putting the whole `And` logic in a class without FunDeps. This was accepted: {{{ class (( a ~ 'True) => (b ~ c), ( a ~ 'False) => (c ~ 'False), ( c ~ 'True) => (a ~ 'True), ( c ~ 'True) => (b ~ 'True) ) => And3 (a :: Bool) (b :: Bool) (c :: Bool) -- no FunDep }}} But attempts to write instances and or/use the class evinced only a torrent of obscure messages, including {{{ * Overlapping instances for b ~ 'True arising from the superclasses of an instance declaration Matching givens (or their superclasses): c ~ 'True bound by a quantified context at ... Matching instances: instance [incoherent] forall k (a :: k) (b :: k). (a ~ b) => a ~ b -- Defined in `Data.Type.Equality' }}} So GHC is creating instances for `(~)` on the fly? (I can supply more details if that would help.) Chiefly I'm thinking that if allowing `(~)` in `QuantifiedConstraints` is only teasing and never effective, there should be a clear rejection message. ''pace'' Simon's comments, I don't see any of those `(~)` implications for `And` as "useless" or "redundant". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14388: GHC Panic
by GHC 20 Jul '18

20 Jul '18

#14388: GHC Panic -------------------------------------+------------------------------------- Reporter: aferrandi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: IfaceTyLit | Operating System: Linux panic | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building the project exmap I,ve got: Information:stack: Building 'exmap' ... Information:stack: /usr/bin/stack build . --stack-yaml /home/andrea/prj/exmap/server/stack.yaml "--ghc-options=-Wall -Werror" exmap-0.1.0.0: configure (exe) Configuring exmap-0.1.0.0... exmap-0.1.0.0: build (exe) Preprocessing executable 'exmap' for exmap-0.1.0.0... ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): get IfaceTyLit 255 Information:stack: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Information:stack: -- While building package exmap-0.1.0.0 using: /home/andrea/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build exe:exmap --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Information:25.10.17 16:19 - Compilation completed with 1 error and 0 warnings in 1s 946ms Error:stack: Stack build failed with nonzero exit status -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15425: GHC does not warn when two conflicting packages with same name are given via a dependent package and -package-db
by GHC 20 Jul '18

20 Jul '18

#15425: GHC does not warn when two conflicting packages with same name are given via a dependent package and -package-db -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.4.3 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: -------------------------------------+------------------------------------- So I'm compiling a Setup.hs of `mypackage`, directly with `ghc` and without use of `Cabal`. It has a custom build type and imports `Distribution.Extra.Doctest` from `cabal-doctest`. For compiling `mypackage`'s Setup.hs I give a `-package-db` that contains a custom `Cabal` package. But when I compiled `doctest`, I did not give that custom `Cabal` package. I compile with {{{ ghc -package-db=/tmp/nix-build-hsyslog-5.0.1.drv-0/setup-package.conf.d -package Cabal -j4 -threaded --make -o Setup -odir $TMPDIR -hidir $TMPDIR $i -fforce-recomp -keep-tmp-files -v5 }}} The given package db looks like this: {{{ % ls -lah /tmp/nix-build-hsyslog-5.0.1.drv-0/setup-package.conf.d total 56K drwxr-xr-x 2 niklas niklas 4.0K Jul 20 03:14 ./ drwxr-xr-x 12 niklas niklas 4.0K Jul 20 03:49 ../ -r--r--r-- 1 niklas niklas 11K Jul 20 02:30 Cabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI.conf -r--r--r-- 1 niklas niklas 2.3K Jul 20 02:30 cabal- doctest-1.0.6-E57gwmEN5fa2uY0bq8bb44.conf -rw-rw-r-- 1 niklas niklas 31K Jul 20 03:14 package.cache -rw-r--r-- 1 niklas niklas 0 Jul 20 02:30 package.cache.lock }}} Full [https://pastebin.com/raw/HpVLbe4A ghc-pkg dump -f /tmp/nix-build- hsyslog-5.0.1.drv-0/setup-package.conf.d output] This results in the linker flags: {{{ -L/nix/store/hfi080vzqqzfip6bd6x4cxc2jgj56xn3-ghc-8.4.3/lib/ghc-8.4.3/Cabal-2.2.0.1 -L/nix/store/6x9r3kqn8h961ilaw2nj474jrfyg28lp- Cabal-2.2.0.1/ghc-8.4.3/Cabal-2.2.0.1 ... -lHSCabal-2.2.0.1 -lHSCabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI }}} When this happens, GHC will always prefer the `Cabal` version from the global package db, and not the one I have given with `-package`. This results in my compiled `Setup` file to not use the Cabal version I desire. I would expect GHC to warn me when two Cabal versions are at play, or entirely refuse to compile, instead of picking the one that I have NOT explicitly specified. See full `-v5` ghc output here: https://pastebin.com/raw/jGbLPjxF -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15425> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15424: There should be a flag for GHCi that tells it to load as many modules as possible
by GHC 20 Jul '18

20 Jul '18

#15424: There should be a flag for GHCi that tells it to load as many modules as possible -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- Right now if GHCi runs into a module that contains an error, it stop loading altogether, AFAIU. It'd be good if it attempted to load as many modules as possible instead. For example, if I have modules A, B, and C and C contains an error, then as long as A and B do not depend on C, I should end up with them in scope no matter in which order I specify the modules in load script (the `--ghci-script` thing). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15417: Memory leaks because of too conservative isAlive check in the GC
by GHC 20 Jul '18

20 Jul '18

#15417: Memory leaks because of too conservative isAlive check in the GC -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Runtime | Version: 8.5 System | 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: -------------------------------------+------------------------------------- (See also the mailing list [https://mail.haskell.org/pipermail/ghc- devs/2018-July/016027.html thread]) Static objects with no SRTs and pointer fields are currently ignored by `evacuate()`. This is efficient but causes trouble when checking alive- ness of static objects in `isAlive()`, which is used for (among other things) checking whether a weak's key has died. This causes leaks as value of a weak with static key will always be kept alive. Here's a demonstration: {{{#!haskell module Main where import System.Mem.Weak (mkWeak, deRefWeak) import System.Mem (performMajorGC) mkKey :: IO String mkKey = readFile "/dev/random" -- mkKey :: IO Int -- mkKey = return 1 main :: IO () main = do w <- mkKey >>= \k -> mkWeak k () Nothing performMajorGC performMajorGC performMajorGC deRefWeak w >>= print }}} The idea is that the first `mkKey` function returns a non-static string and this program prints `Nothing`. If I enable the second `mkKey` function the key is now a static object and the program prints `Just ()`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15417> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2