August 2017 - ghc-tickets

[GHC] #9885: ghc-pkg parser eats too much memory
by GHC 21 Jan '18

21 Jan '18

#9885: ghc-pkg parser eats too much memory -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Moderate (less | performance bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Parsing of spec files in ghc-pkg scales very poorly. The following script demonstrates memory consumption growth as a function of the number of tokens in ld-options (16K leads to ~6G) #!/bin/bash # Demonstrates memory consumption behavior of ghc-pkg as a function of # the number of ld-options arguments. for i in {10..14}; do size=$((1 << $i)) echo $size rm -fr a.packages /usr/bin/ghc-pkg init a.packages cat > a.spec <<EOF name: project id: project license: AllRightsReserved version: 1.0 EOF echo -n ld-options: >> a.spec for i in $(seq 1 $size); do echo -n "x "; done >> a.spec /usr/bin/time /usr/bin/ghc-pkg --global-package-db a.packages register --force a.spec done exit 0 # This was collected with ghc-7.6.3. 7.8.3 fares as badly. % bash a.sh 1024 Reading package info from "a.spec" ... done. 0.03user 0.00system 0:00.03elapsed 97%CPU (0avgtext+0avgdata 17848maxresident)k 0inputs+32outputs (0major+4973minor)pagefaults 0swaps 2048 Reading package info from "a.spec" ... done. 0.09user 0.01system 0:00.10elapsed 99%CPU (0avgtext+0avgdata 60872maxresident)k 0inputs+56outputs (0major+15723minor)pagefaults 0swaps 4096 Reading package info from "a.spec" ... done. 0.41user 0.07system 0:00.49elapsed 99%CPU (0avgtext+0avgdata 294340maxresident)k 0inputs+104outputs (0major+74090minor)pagefaults 0swaps 8192 Reading package info from "a.spec" ... done. 1.72user 0.30system 0:02.04elapsed 99%CPU (0avgtext+0avgdata 1168836maxresident)k 0inputs+192outputs (0major+292716minor)pagefaults 0swaps 16384 Reading package info from "a.spec" ... done. 9.11user 1.38system 0:10.51elapsed 99%CPU (0avgtext+0avgdata 5396932maxresident)k 0inputs+376outputs (0major+1349736minor)pagefaults 0swaps -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11645: Heap profiling - hp2ps: samples out of sequence
by GHC 21 Jan '18

21 Jan '18

#11645: Heap profiling - hp2ps: samples out of sequence -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #664 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `make TEST=hpc_fork WAY=prof` is failing, but it has nothing to do with `hpc`. {{{ hp2ps: hpc_fork.hp, line 9, samples out of sequence hp2ps error when processing heap profile for hpc_fork }}} hpc_fork.hs: {{{ module main where import system.posix.process import control.concurrent main = do pid1 <- forkprocess $ do threaddelay 100000 pid2 <- forkprocess $ do threaddelay 100000 print () }}} To reproduce: {{{ $ ghc-8.0.1 hpc_fork.hs -fforce-recomp -prof $ ./hpc_fork +RTS -hc $ hp2ps hpc_fork.hp }}} Example hpc_fork.hp: {{{ JOB "hpc_fork +RTS -hc" DATE "Thu Feb 25 22:37 2016" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.000000 END_SAMPLE 0.000000 BEGIN_SAMPLE 0.005672 END_SAMPLE 0.005672 BEGIN_SAMPLE 0.003167 END_SAMPLE 0.003167 BEGIN_SAMPLE 0.003311 END_SAMPLE 0.003311 }}} This is a regression from 7.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14056: Figure out what to do about libffi
by GHC 21 Jan '18

21 Jan '18

#14056: Figure out what to do about libffi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.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: -------------------------------------+------------------------------------- For some platform GHC depends upon `libffi` for foreign call support in the bytecode interpreter. Unfortunately `libffi`'s upstream seems to be unresponsive and there has not been a release in nearly three years. This means that there is currently no release which has, e.g., support for AArch64 and iOS's compact debug information. While we obviously want to avoid shipping our own patched libffi, at this point we are starting to run out of options. Consider options for resolving this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14122: Core lint error while compiling GHC.IO.Handle
by GHC 21 Jan '18

21 Jan '18

#14122: Core lint error while compiling GHC.IO.Handle -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- While compiling `GHC.IO.Handle` with `-g3 -dcore-lint -O` I encountered the following, {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of w1_s8qY :: Addr#] Recursive or top-level binder has strict demand info: w1_s8qY Binder's demand info: <L,U> }}} The binding in question is, {{{#!hs w1_s8qY :: Addr# [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] w1_s8qY = src<libraries/base/GHC/IO/Handle.hs:745:37-50> src<libraries/base/GHC/IO/Handle.hs:739:9-10> "}"# }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14006: Heap profiling ghc gives hp2ps error
by GHC 21 Jan '18

21 Jan '18

#14006: Heap profiling ghc gives hp2ps error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime | Version: 8.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running GHC with heap profiling and then running `hp2ps` on the result gives {{{ hp2ps: ghc-stage2.hp, line 17405, samples out of sequence }}} Reproduction (GHC commit 4700baaf8f9bf3c44a53a595d840c7c14cfd6f98) {{{ cabal unpack skylighting-0.1.1.5 cd skylighting-0.1.1.5 cabal configure --with-ghc=$HOME/src/ghc-clean-july12/inplace/bin/ghc- stage2 \ --enable-profiling -fexecutable cabal build touch src/Skylighting/Syntax/Php.hs /home/dfeuer/src/ghc-clean-july12/inplace/bin/ghc-stage2 --make -i \ -isrc -idist/build -O -prof -fprof-auto-exported -osuf p_o -hisuf \ p_hi -optPdist/build/autogen/cabal_macros.h -hide-all-packages \ -package-db dist/package.conf.inplace -package-id aeson-1.2.1.0 \ -package base-4.10.0.0 -package blaze-html-0.9.0.1 -package \ bytestring-0.10.8.2 -package case-insensitive-1.2.0.10 -package \ containers-0.5.10.2 -package directory-1.3.0.2 -package \ filepath-1.4.1.2 -package hxt-9.3.1.16 -package mtl-2.2.1 -package \ regex-pcre-builtin-0.94.4.8.8.35 -package safe-0.3.15 -package \ text-1.2.2.2 -package utf8-string-1.0.1.1 -XHaskell2010 \ Skylighting.Types Skylighting.Regex \ Skylighting.Tokenizer Skylighting.Syntax.Php -j1 +RTS \ -s -h -N1 hp2ps ghc-stage2.hp }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12825: ghc panic on ppc64el, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI
by GHC 21 Jan '18

21 Jan '18

#12825: ghc panic on ppc64el, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI ---------------------------------+--------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+--------------------------------- {{{ [331 of 332] Compiling Agda.Interaction.EmacsTop ( src/full/Agda/Interaction/EmacsTop.hs, dist- ghc/build/Agda/Interaction/EmacsTop.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for powerpc64le-unknown-linux): applyTypeToArgs Expression: $w$cgmapQl2 stdin LineBuffering s_aJ4 Type: forall r_a2gyr r'_a2gys. (r_a2gyr -> r'_a2gys -> r_a2gyr) -> r_a2gyr -> (forall d_a2gyt. Data d_a2gyt => d_a2gyt -> r'_a2gys) -> [ModulePragma] -> ModuleName -> r_a2gyr Args: [stdin, LineBuffering, s_aJ4] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11359: Consider removing RelaxedLayout and friends
by GHC 21 Jan '18

21 Jan '18

#11359: Consider removing RelaxedLayout and friends -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These three parsing-related language extensions were [[https://ghc.haskell.org/trac/ghc/wiki/LanguagePragmaHistory|introduced]] some time ago yet are likely not used in the wild as they still are not registered in Cabal's language extension list (which Hackage uploads are checked against, see #8176), * `RelaxedLayout` (introduced in 7.2, prompted by #1060) * `AlternativeLayoutRule` (introduced in 7.0, reason unknown) * `AlternativeLayoutRuleTransitional` (introduced in 7.0, reason unknown) As far as [[https://mail.haskell.org/pipermail/ghc- devs/2013-September/002267.html|I can]] [[https://ghc.haskell.org/trac/ghc/ticket/8176#comment:10|tell]] no one knows the status of these, nor are they listed in the users guide. We should ask the community whether they would mind seeing these extensions vanish and remove them if not. If so then we should see to it that they are registered properly with Cabal so they can be used on Hackage. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11091: Fix MonadFail warnings
by GHC 21 Jan '18

21 Jan '18

#11091: Fix MonadFail warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: task | Status: new Priority: low | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- #10751 implements the MonadFail warning mechanism. Using `-fwarn-missing-monadfail-instance`, GHC's internal warnings created by the patch can be shown and fixed. A second pass with `-XMonadFailDesugaring` then provides a hard check on whether any issues remain, by switching on the new desugaring mechanism properly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function
by GHC 17 Jan '18

17 Jan '18

#13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | 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: #13014 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #specialize-inline The user's guide] for `SPECIALIZE INLINE` states it will do a "type-based unrolling" of a recursive function over GADTs. It gives an example, which I've munged a bit to simplify and listed here. {{{#!hs {-# Language GADTs #-} module C where data Arr e where ArrInt :: !Int -> Arr Int ArrPair :: Arr e1 -> Arr e2 -> Arr (e1, e2) (!:) :: Arr e -> Int -> e {-# SPECIALISE INLINE (!:) :: Arr Int -> Int -> Int #-} {-# SPECIALISE INLINE (!:) :: Arr (a, b) -> Int -> (a, b) #-} (ArrInt ba) !: i = ba * i (ArrPair a1 a2) !: i = (a1 !: i, a2 !: i) }}} {{{#!hs module D where import C example = ArrPair (ArrInt 2) (ArrInt 3) !: 5 }}} The specialize rule for pairs fires, but it does not get inlined. This is because the specialization for pairs is marked as a loopbreaker. This behavior contradicts the text from the users guide, emphasis mine: Here, `(!:)` is a recursive function that indexes arrays of type `Arr e`. Consider a call to `(!:)` at type `(Int,Int)`. The second specialisation will fire, ''and the specialised function will be inlined''. It has two calls to `(!:)`, both at type `Int`. Both these calls fire the first specialisation, whose body is also inlined. The result is a type-based unrolling of the indexing function. If I move the `SPECIALIZE INLINE` pragma to the downstream module, then it is not marked as a loopbreaker and we see the expected type-based unrolling. Two possible ways to resolve this ticket: * `SPECIALIZE INLINE` should always achieve supercompilation even if declared in the defining module; the specialization should not be marked as a loopbreaker. * The docs should be updated to say the pragma must be declared in a separate module. I suggest the former. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13683: Use epoll rather than poll where appropriate
by GHC 16 Jan '18

16 Jan '18

#13683: Use epoll rather than poll where appropriate ----------------------------------------+--------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Linux supports an `epoll` system call that's supposed to scale better to large numbers of watched file descriptors than `poll`. We should probably use it when available and appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4