May 2014 - ghc-tickets

[GHC] #8662: GHC does not inline cheap inner loop when used in two places
by GHC 04 Aug '16

04 Aug '16

#8662: GHC does not inline cheap inner loop when used in two places ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- When I made a Criterion benchmark of Neil Michell's "Tight Inner Loop" blog post (http://neilmitchell.blogspot.co.uk/2014/01/optimising-haskell- for-tight-inner-loop.html), I noticed that GHC 7.6.3 will not inline the performance-critical function when it's called from two different places (inside the same module). {{{ break0_2pleaseinline :: (Char -> Bool) -> ByteString0 -> (ByteString, ByteString0) break0_2pleaseinline f (BS0 bs) = (BS.unsafeTake i bs, BS0 $ BS.unsafeDrop i bs) where i = Internal.inlinePerformIO $ BS.unsafeUseAsCString bs $ \ptr -> do let start = castPtr ptr :: Ptr Word8 let end = go start return $! Ptr end `minusPtr` start go s@(Ptr a) | c == '\0' || f c = a | otherwise = go $ inc s where c = chr s versionInl1 :: ByteString0 -> (ByteString, ByteString0) versionInl1 str = break0_2pleaseinline test str where test x = x <= '$' && (x == ' ' || x == '\r' || x == '\n' || x == '$') versionInl2 :: ByteString0 -> (ByteString, ByteString0) versionInl2 str = break0_2pleaseinline test str where test x = x <= '$' && (x == ' ' || x == '\r' || x == '\n' || x == '$') }}} Full code here: https://github.com/nh2/inner-loop- benchmarks/blob/6715d1e9946d6b5e6d9bb53203982ed3d2ed32ff/Bench.hs#L166. {{{break0_2pleaseinline}}} does not get inlined, which makes {{{versionInl1}}} and {{{versionInl2}}} over 4 times slower than when inlined. The inlining doens't happen, not even with {{{-O2}}} and {{{-O3}}}, only an {{{INLINE}}} pragma will move GHC to do it. If I was a compiler, I would so inline that function! I am surprised that GHC doesn't decide to do so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8814: 7.8 optimizes attoparsec improperly
by GHC 04 Aug '16

04 Aug '16

#8814: 7.8 optimizes attoparsec improperly ------------------------------+-------------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- {{{ #!haskell {-# LANGUAGE OverloadedStrings #-} import Control.Applicative import qualified Data.Attoparsec.Text as A import Data.Text (Text) import qualified Data.Text as T testParser :: Text -> Either String Int testParser f = fmap length . A.parseOnly (many (A.char 'b' <|> A.anyChar)) $ f main :: IO () main = print . testParser $ T.replicate 50000 "a" }}} On GHC 7.6.3 with `-O2`: {{{ real 0m0.062s user 0m0.022s sys 0m0.007s }}} On GHC 7.8 tip with `-O2`: {{{ real 0m12.700s user 0m12.504s sys 0m0.165s }}} On GHC 7.6.3 with `-O0`: {{{ real 0m0.077s user 0m0.025s sys 0m0.007s }}} On GHC 7.8 tip with `-O0`: {{{ real 0m0.055s user 0m0.026s sys 0m0.007s }}} This seems to be related to the use of `<|>`; if I change the program so that the second branch (`A.anyChar`) is never taken, 7.8 behavior is roughly the same as 7.6 under any optimization level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8473: Generate table of cost-centre numbers with source locations
by GHC 01 Aug '16

01 Aug '16

#8473: Generate table of cost-centre numbers with source locations ------------------------------------+------------------------------------- Reporter: lars_e_krueger | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7105 | ------------------------------------+------------------------------------- .prof files contain a cost centre number, which I assume is cc_key from CostCentre.lhs. It would be immensely helpful if the compiler creates a simpe table. This way, one could look up the number in .prof, check the table and the exact source location. It would also help with #7105, I think. Suggestion for the format: {{{ no. file begin end 1 main.hs 127:7 128:14 }}} Meaning: Cost centre 1 is in file main.hs, begins at line 127, character 7 and ends at line 128, character 14. If somebody points me in the right direction, and the whole thing is not too complicated, I can try my hand at implementing it myself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8732: Global big object heap allocator lock causes contention
by GHC 17 Jul '16

17 Jul '16

#8732: Global big object heap allocator lock causes contention ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The lock allocate() takes when allocating big objects hurts scalability of I/O bound application. Network.Socket.ByteString.recv is typically called with a buffer size of 4096, which causes a ByteString of that size to be allocate. The size of this ByteString causes it to be allocated from the big object space, which causes contention of the global lock that guards that space. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8732> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8308: Resurrect ticky code for counting constructor arity
by GHC 12 Jul '16

12 Jul '16

#8308: Resurrect ticky code for counting constructor arity ----------------------------------------------+---------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: ----------------------------------------------+---------------------------- There is a dead piece of ticky profiling code that computes histograms of data constructor arities (including tuples) and size of vector returns. The function responsible is `bumpHistogram` in [[GhcFile(compiler/codeGen/StgCmmTicky.hs)]], which masks the commented out function `bumpHistogramE`. We can improve ticky profiling by resurrecting this dead code. There are following things that need to be done: 1. Replace current no-op `bumpHistogram` with `bumpHistogramE`. Note that current implementation of `bumpHistogramE` computes constructor arity at runtime. This is unnecessary because we know arity at compile time so we can avoid runtime check by doing sth like this: {{{ bumpHistogram lbl n = do let offset = n `min` 8 emit (addToMem cLong (cmmIndexExpr cLongWidth (CmmLit (CmmLabel (mkRtsDataLabel lbl))) (CmmReg (CmmInt (fromIntegral offset) cLongWidth))) 1) }}} Note that `mkRtsDataLabel` function does not exist anymore but we should be able to replace that call with `mkCmmDataLabel rtsPackageId lbl` (speculation). 2. We need to declare arrays that will store histogram values. Declarations of variables used for storing ticky statistics are in [[GhcFile(includes/stg/Ticky.h)]]. We also need to initialize the declared array to contain only zeros. 3. Having declared the arrays we need to fix printing of computed arities. This is done in [[GhcFile(rts/Ticky.c)]]. Note that there is a lot of code that is commented out (`/* krc: comment out some of this stuff temporarily */`) or disabled with `#if FALSE` pragma. We need to resurect *some* of it. There is a `PR_HST` macro for printing one histogram entry. This seems bad. We should probably rework the part of code responsible for printing out results of historgams. 4. Current code counts arities from 0 to 8. Everything above 8 is put into the same bin as 8. This magical 8 is spread all over the code. We should declare a constant that is visible both in Haskell sources (see `bumpHistogram` in 1.) and RTS files and have all code behave properly depending on that constant - we should have loops instead of statically printing 9 elements of histogram array. 5. Some ticky functions that count arity histograms are not used. For example `tickyReturnNewCon` should probably be called by `cgConApp` like this: {{{ ; emit =<< fcode_init ; tickyReturnNewCon ; emitReturn [idInfoToAmode idinfo] } }}} The above is a an outline, which should be fairly accurate, but unexpected things may show up along the way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9078: Segfault with makeStableName
by GHC 28 Jun '16

28 Jun '16

#9078: Segfault with makeStableName ------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Calling `makeStableName` on the same object many times causes a segfault. The following triggers this behaviour on both OSX and Linux-x86_64, provided it is compiled (it doesn't seem to occur if the call to `makeStableName` is interpreted). {{{ module Main where import Control.Monad import System.Mem.StableName main :: IO () main = replicateM_ 100000 (makeStableName foo) foo :: Int foo = 1 }}} It seems to happen largely at random. The 100000 calls to `makeStableName` in the above example essentially guarantee its occurrence, but I have observed it happen with far fewer. The reason this bug was discovered is it is causing frequent failures in Accelerate on 7.8.2. See [https://github.com/AccelerateHS/accelerate/issues/162] In that case it seems to be causing more `strange closure type` errors than segfaults, but I assume it is the same root cause. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #8713: libdl, libpthread may be unwanted too
by GHC 21 Jun '16

21 Jun '16

#8713: libdl, libpthread may be unwanted too -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: Other Architecture: x86_64 (amd64) | Type of failure: GHC doesn't work Difficulty: Moderate (less | at all than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I have GHC on an unusual system [1] libdl.so.1, librt.so.1 and some others are "filter libraries": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linking is successful, libFOO.so.1 is not linked in :-) Unfortunately, runtime linker (ld.so.1) does not understand GNU ld linker scripts. And I get errors like this: {{{ # ghci -package unix GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package unix-2.7.0.0 ... <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so (ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc- solaris2.11/4.7/../../../x86_64-illumos/libdl.so: unknown file type) }}} The unix package v2.6 had the same issue with librt.so too, in version 2.7 libdl.so remains. I use the attached patch for GHC 7.6.3 to fix this issue. In general I suggest to use AC_SEARCH_LIBS instead of AC_CHECK_LIB [1] http://osdyson.org -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8825: ghc can't determine gcc version on ru_RU locale
by GHC 14 Jun '16

14 Jun '16

#8825: ghc can't determine gcc version on ru_RU locale ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Current ghc spits warnings time to time: {{{ <no location info>: Warning: Couldn't figure out linker information! Make sure you're using GNU gcc, or clang }}} It's because my default locale is '''LANG=ru_RU.UTF-8''' [1] {{{ ... gcc версия 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} versus '''LANG=C''' {{{ ... gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} [1]: {{{ $ gcc -v Используются внутренние спецификации. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper Целевая архитектура: x86_64-pc-linux-gnu Параметры конфигурации: /subvolumes/var_tmp/portage/sys- devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux- gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux- gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx- include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with- python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable- languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable- werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with- pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable- libstdcxx-time --enable-shared --enable-threads=posix --enable- __cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib- list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog Модель многопоточности: posix gcc версия 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} [2]: While LANG=C output: {{{ $ LANG=C gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /subvolumes/var_tmp/portage/sys- devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux- gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux- gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx- include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with- python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable- languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable- werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with- pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable- libstdcxx-time --enable-shared --enable-threads=posix --enable- __cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib- list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog Thread model: posix gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8510: Clear up what extensions are needed at a Template Haskell splice site
by GHC 09 Jun '16

09 Jun '16

#8510: Clear up what extensions are needed at a Template Haskell splice site ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Suppose you write {{{ module M where data T = ... $(cleverThFunction ''T) }}} where `cleverThFunction` is some Template Haskell code in a library somewhere. Question: * '''If `cleverThFunction` generates code that uses `GADTs`, or `ConstraintKinds`, or `TypeFamilies` or whatnot, do those language extension flags have to be in force in module M, or only at the definition of `cleverThFunction`?''' Currently the situation is anarchic; see below. It should be made tidy. My personal preference is to say that the extensions must be in force in the definition of `cleverThFunction`, but '''not''' at the splice site. Reason: the client doesn't know or care how `cleverThFunction` works. This decision would be compatible with the handling of overlapping instances. Gergely writes: There are a lot of extensions that simply can't be used with TH: {{{ - n+k, - RecursiveDo, - TransformListComp, - Arrows, - ImplicitParams, - TupleSections, - Monadcomprehensions. }}} The rest can be grouped into two parts. The following extensions still work when spliced in without the corresponding language pragma: {{{ - UnicodeSyntax, - LambdaCase, - NamedFieldPuns, - RecordWildCards, - DataTypeContexts (and you get rid of the deprecation warning generation this way :)), - ConstraintKind, - MagicHash (note that UnboxedTuples is in the other part), - TraditionalRecordSyntax, - MultiWayIf, - GADTs (extra nice example at the end of this message). }}} The following needs the pragma at the place of splicing: {{{ - PostfixOperators, - ScopedTypeVariables, - Rank2, RankN, - deriving typeable and data, - UnboxedTuples, - ViewPatterns, - ParallelListComp, - ExistentialQuantification, - EmptyDataDecls, - TypeFamilies, - MultiParamTypeClasses, - FunctionalDependencies. }}} I don't see any trivial distinction, like based on Reader vs Typechecker, or anything like that. In particular * Note `ViewPatterns` vs `LambdaCase`. * Note `GADTs` vs `Rank2`. A very interesting example is `ExplicitForAll`. The AST for polymorphic functions always have explicit foralls in TH.Syntax; so there is no way to require the user at the point of splicing to enable the language extension. GADTs are cool too: {{{ {-# LANGUAGE TemplateHaskell #-} -- No need for GADTs at all! -- {-# LANGUAGE GADTs #-} $([d| data Foo where Foo1 :: Int -> Foo Foo2 :: String -> Foo f1 :: Foo f1 = Foo1 5 f :: Foo -> Either Int String f (Foo1 n) = Left n f (Foo2 s) = Right s |]) main = print (f f1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9034: GHCi panics when given C++ object file on GNU/Linux
by GHC 08 Jun '16

08 Jun '16

#9034: GHCi panics when given C++ object file on GNU/Linux ------------------------------------------+------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: panic, dynamic linking | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------------+------------------------------- When given a C++ object file, GHCi panics saying that it can't find standard C++ symbols the object file relies on. If foo.cc contains {{{#!C++ #include <iostream> extern "C" void foo () { std::cout << "bar"; } }}} and is compiled with {{{ g++ -fPIC -c -o foo.o foo.cc }}} then {{{ ghci foo.o -lstdc++ }}} fails with {{{ GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) foo.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14109_0/ghc14109_1.so: undefined symbol: _ZSt4cout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It makes no difference to add -L<C++ library paths> which was, IIRC, necessary in older versions of GHC. This applies to only GHCi with C++ -- GHC can link C++ object files just fine, while GHCi has no trouble loading C object files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7