May 2016 - ghc-tickets

[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] #9798: Frustrating behaviour of the INLINE pragma
by GHC 03 Aug '16

03 Aug '16

#9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- So I have a function "a", which uses another function "b" from another module. * Step 1. I benchmark its performance and get 250ns. * Step 2. I go and put the "INLINE" pragma on the function "b", run the benchmark again and get 500ns. That is twice as long. * Step 3. I go and add an explicit invocation of the [http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC- Exts.html#v:inline inline] function over function "b" in function "a" and finally get the desired optimization: 208ns. You can reproduce the issue by executing {{{cabal bench decoding --benchmark-options=numeric}}} after cloning the trees of the following commits: * [https://github.com/nikita-volkov/postgresql- binary/commit/31e08b4f6887445c28118d25f9da808e7ca9fc86 Step 1] * [https://github.com/nikita-volkov/postgresql- binary/commit/8f29b8daebc3161dc0fa35fbd70d3f3305370a4e Step 2] * [https://github.com/nikita-volkov/postgresql- binary/commit/3d3e4378bcd8ea85cda868d6a4bf07a76a9cad2c Step 3] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10710: More self-explanatory pragmas for inlining phase control
by GHC 03 Aug '16

03 Aug '16

#10710: More self-explanatory pragmas for inlining phase control -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Eventually implement [[Proposal/SelfExplinatoryInlinePragmas]]. And while at it: Extend the docs where they say “You shouldn't ever need to do this, unless you're very cautious about code size.” -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10766: user manual: INLINE's interaction with optimization levels is not clear
by GHC 03 Aug '16

03 Aug '16

#10766: user manual: INLINE's interaction with optimization levels is not clear -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.11 Documentation | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- user manual: INLINE's interaction with optimization levels is not clear From the user manual it's not possible to say how should INLINE and actual inlining behavior should interact with optimization levels. What the user manuals says: - Without INLINE GHC tries to inline depending on size of definitions and current optimization level(user manual says -O is needed, but can we assume that for any inlining to be done we need at least -O? Because I have an example in which inlining is happening even with -O0). - With INLINE GHC tries hard to inline. But it doesn't say which optimization level is needed. I think we should add word or two about this. Does anyone know the answer here? My guess is: Even though INLINE makes sure GHC saves RHS of the definition in .hi files to be able to inline later, optimization levels still have an effect on deciding whether to inline or not. Because some INLINEd RHSs may be too big in which case it may decide not to inline with -O1 but inline with -O2 etc. Furthermore, without -O, GHC doesn't mark definitions as INLINE. But if we have INLINEd definitions and compiling a code with -O0, it may still inline those definitions, because there are two different mechanisms to decide whether to mark as INLINE and whether to inline the RHS, and while without -O GHC doesn't mark anything as INLINE, it can still inline previously marked definitions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200
by GHC 03 Aug '16

03 Aug '16

#11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10527 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is perhaps the same bug as #10527 but I'm not sure, as it goes away with a modest bump to `-fsimpl-tick-factor`. I'm developing a library and am seeing this when I go to compile a small hello-world executable. {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fMonadIdentity_$c>>= To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6642 }}} If I remove the `INLINE` from the exported functions it goes away, but also makes the code much slower (for some reason the way I use the function in my benchmark suite doesn't exhibit the error). It also compiles with `-fsimpl-tick-factor=200`. Previously on 7.10.1 I got the same error in a different part of my code (the test suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of the repo, but it's not a small test case. Even if this is a duplicate, I'd love some guidance on this: Is this actually a ghc bug, or is it my fault that I've got too much inlining in my code (I've never seen anything like this before, and pretty much mark everything INLINE)? Should I pass this off to my users and should it be their responsibility to bump `-fsimpl-tick-factor` to work around regressions in their GHC? If I want to try to work around this in my library, what strategies could I employ (besides disabling inlining of exported functions)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[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] #12121: FlexibleContexts is under specified
by GHC 28 Jul '16

28 Jul '16

#12121: FlexibleContexts is under specified -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: #12010 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been reading the documentation on `FlexibleContexts`. It's pretty confusing. === Structure The documentation is scattered around 3 different sections: * 9.8.1.2. The superclasses of a class declaration (this is where the [http://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.… #ghc-flag--XFlexibleContexts link] from the flag reference takes you). * 9.8.3.3. Relaxed rules for instance contexts * 9.15.2. The context of a type signature Maybe it's ok to separate it like this, but it took me a while to figure out that there //are// actually three different sections. A simple solution would be to mention that there are 3 different sections, in each section (it already does so in the last section). === Specification > The -XFlexibleContexts flag lifts the Haskell 98 restriction that the type-class constraints in a type signature must have the form `(class type-variable)` or `(class (type-variable type1 type2 ... typen))`. That's all fine and well, but hardly teaches me anything. I would like to know which type-class constraints //are// allowed with `FlexibleContexts`. Or in other words: what is a definition of a "type- class constraint" with `FlexibleContexts`? This is the old grammar: {{{ context → class | ( class1 , … , classn ) (n ≥ 0) class → qtycls tyvar | qtycls ( tyvar atype1 … atypen ) (n ≥ 1) }}} What is the new one? === Examples * These are the example mentioned in the section on the context of a class declaration (9.8.1.2): {{{ class Functor (m k) => FiniteMap m k where class (Monad m, Monad (t m)) => Transform t m where lift :: m a -> (t m) a }}} Problem is, they neither require `FlexibleContexts`, nor do they compile with `FlexibleContexts`! Those examples require `MultiParamTypeClasses`. `MultiParamTypeClasses` doesn't enable `FlexibleContexts` automatically. * The section on instance contexts doesn't have any examples. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12123: GHC crashes when calling typeRep on a promoted tuple
by GHC 24 Jul '16

24 Jul '16

#12123: GHC crashes when calling typeRep on a promoted tuple -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- The following code (asking for the typeRep of a promoted tuple) causes GHC to crash. {{{ import Data.Typeable import Data.Proxy x = typeRep (Proxy::Proxy '(Int,Int)) }}} The error message is: {{{ [1 of 1] Compiling Main ( ../Bug.hs, interpreted ) GHC error in desugarer lookup in Main: Can't find interface-file declaration for variable $tc'(,) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160518 for x86_64-unknown-linux): initDs IOEnv failure }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux
by GHC 22 Jul '16

22 Jul '16

#10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux -------------------------------------+------------------------------------- Reporter: aslpavel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we remove current executable or update it with a new one, getExecutablePath returns path with added " (deleted)" suffix. I think it is incorrect behavior , for example if you updated binary and want to exec a new one, the obvious way to go is to call getExecutablePath and use it. Moreover it is inconsistent between platforms. Problem stems from the fact the getExecutablePath is implemented as readlink on /proc/self/exe and it contains gibberish once file has been deleted. Example: {{{#!hs module Main (main) where import System.Environment (getExecutablePath) import System.Directory (removeFile) main :: IO () main = do before <- getExecutablePath putStrLn $ "Before: " ++ before removeFile before after <- getExecutablePath putStrLn $ "After: " ++ after }}} Output: {{{ $ ./getExecutablePath Before: /mnt/data/Maggot/getExecutablePath After: /mnt/data/Maggot/getExecutablePath (deleted) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10957> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12095: GHC and LLVM don't agree on what to do with byteSwap16#
by GHC 21 Jul '16

21 Jul '16

#12095: GHC and LLVM don't agree on what to do with byteSwap16# -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: codegen, llvm | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this test case (taken from [https://github.com/well-typed/binary- serialise-cbor/issues/67 here] and lightly modified to work on big/little endian machines): {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE CPP #-} module Main ( main -- :: IO () ) where #include "ghcconfig.h" import GHC.Prim import GHC.Word data T = T !Addr# t :: T #ifndef WORDS_BIGENDIAN t = T "\xcf\xb1"# #else t = T "\xb1\xcf"# #endif grabWord16 :: T -> Word64 grabWord16 (T addr#) = W64# (byteSwap16# (indexWord16OffAddr# addr# 0#)) trip :: Int trip = fromIntegral (grabWord16 t) main :: IO () main = print trip }}} With GHC 7.10.3 using the NCG, the results given are correct: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ ghc -Wall -fforce-recomp -O2 Issue67.hs && ./Issue67 [1 of 1] Compiling Main ( Issue67.hs, Issue67.o ) Linking Issue67 ... 53169 }}} This also is the same on GHC 8.0.1 using the NCG, on both PowerPC and AMD64 as well. This answer is correct: `53169` is `0xCFB1` in hex, so the `byteSwap16#` primitive correctly works to decode the swapped-endian number. However, the story is not the same with GHC 7.10.3+LLVM 3.5, or GHC 8.0.1+LLVM 3.7: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ llc --version | head -2 LLVM (http://llvm.org/) LLVM version 3.5.2 $ ghc -Wall -fforce-recomp -O2 Issue67.hs -fllvm && ./Issue67 [1 of 1] Compiling Main ( Issue67.hs, Issue67.o ) Linking Issue67 ... -12367 }}} Note: {{{#!hs -12367 == (fromIntegral (53169 :: Word16) :: Int16) }}} The relevant snippet looks like this at the CMM level (GHC 7.10.3): {{{ ==================== Output Cmm ==================== [section "data" { Main.main2_closure: const Main.main2_info; const 0; const 0; const 0; }, section "readonly" { c3rq_str: I8[] [207,177] }, section "readonly" { c3rr_str: I8[] [207,177] }, Main.main2_entry() // [R1] { info_tbl: [(c3ru, label: Main.main2_info rep:HeapRep static { Thunk }), (c3rD, label: block_c3rD_info rep:StackRep [])] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c3ru: ... c3ro: I64[Sp - 16] = stg_bh_upd_frame_info; I64[Sp - 8] = _c3rn::I64; (_c3rw::I64) = call MO_BSwap W16(%MO_UU_Conv_W16_W64(I16[c3rr_str])); I64[Sp - 24] = c3rD; R4 = GHC.Types.[]_closure+1; R3 = _c3rw::I64; R2 = 0; Sp = Sp - 24; call GHC.Show.$wshowSignedInt_info(R4, R3, R2) returns to c3rD, args: 8, res: 8, upd: 24; ... }}} Pre-optimized LLVM basic block: {{{ c3rB: %ln3sc = ptrtoint i8* @stg_bh_upd_frame_info to i64 %ln3sb = load i64** %Sp_Var %ln3sd = getelementptr inbounds i64* %ln3sb, i32 -2 store i64 %ln3sc, i64* %ln3sd, !tbaa !1 %ln3sf = load i64* %lc3rA %ln3se = load i64** %Sp_Var %ln3sg = getelementptr inbounds i64* %ln3se, i32 -1 store i64 %ln3sf, i64* %ln3sg, !tbaa !1 %ln3sh = ptrtoint %c3rE_str_struct* @c3rE_str$def to i64 %ln3si = inttoptr i64 %ln3sh to i16* %ln3sj = load i16* %ln3si, !tbaa !5 %ln3sk = zext i16 %ln3sj to i64 %ln3sl = trunc i64 %ln3sk to i16 %ln3sm = call ccc i16 (i16)* @llvm.bswap.i16( i16 %ln3sl ) %ln3sn = sext i16 %ln3sm to i64 store i64 %ln3sn, i64* %lc3rJ %ln3sp = ptrtoint void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @c3rQ_info$def to i64 %ln3so = load i64** %Sp_Var %ln3sq = getelementptr inbounds i64* %ln3so, i32 -3 store i64 %ln3sp, i64* %ln3sq, !tbaa !1 %ln3sr = ptrtoint i8* @ghczmprim_GHCziTypes_ZMZN_closure to i64 %ln3ss = add i64 %ln3sr, 1 store i64 %ln3ss, i64* %R4_Var %ln3st = load i64* %lc3rJ store i64 %ln3st, i64* %R3_Var store i64 0, i64* %R2_Var %ln3su = load i64** %Sp_Var %ln3sv = getelementptr inbounds i64* %ln3su, i32 -3 %ln3sw = ptrtoint i64* %ln3sv to i64 %ln3sx = inttoptr i64 %ln3sw to i64* store i64* %ln3sx, i64** %Sp_Var %ln3sy = bitcast i8* @base_GHCziShow_zdwshowSignedInt_info to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* }}} Post-optimized block (`opt --enable-tbaa=true -O2 out-llvm-orig.ll -o out- llvm.bc`): {{{ c3rB: ; preds = %c3rU %ln3s8 = ptrtoint i8* %ln3s7 to i64 %ln3sd = getelementptr inbounds i64* %Sp_Arg, i64 -2 store i64 ptrtoint (i8* @stg_bh_upd_frame_info to i64), i64* %ln3sd, align 8, !tbaa !5 %ln3sg = getelementptr inbounds i64* %Sp_Arg, i64 -1 store i64 %ln3s8, i64* %ln3sg, align 8, !tbaa !5 store i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @"c3rQ_info$def" to i64), i64* %ln3rZ, align 8, !tbaa !5 tail call cc10 void bitcast (i8* @base_GHCziShow_zdwshowSignedInt_info to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)*)(i64* %Base_Arg, i64* %ln3rZ, i64* %Hp_Arg, i64 %R1_Arg, i64 0, i64 -12367, i64 add (i64 ptrtoint (i8* @ghczmprim_GHCziTypes_ZMZN_closure to i64), i64 1), i64 undef, i64 undef, i64 %SpLim_Arg) #0 ret void }}} Folds it right into a constant! I haven't spent time diagnosing this much further, yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3