November 2014 - ghc-tickets

Re: [GHC] #2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg.
by GHC 19 Nov '14

19 Nov '14

#2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg. -------------------------------------+--------------------------------- Reporter: cjs | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: -------------------------------------+--------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"6fc78fdfa1482a31ed7b586f20c9d7cb592ea944/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6fc78fdfa1482a31ed7b586f20c9d7cb592ea944" Refactor: use System.FilePath.splitSearchPath Summary: To address #2521 ("Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg"), we were using a custom version of splitSearchPath (e4f46f5de). This solution however caused issue #9698 ("GHC_PACKAGE_PATH should be more lenient for empty paths"). This patch reverts back to System.FilePath.splitSearchPath (fixes #9698) and adresses (#2521) by testing for a trailing search path separators explicitly (instead of implicitly using empty search path elements). Empty paths are now allowed (ignored on Windows, interpreted as current directory on Posix systems), and trailing path separator still tack on the user and system package databases. Also update submodule filepath, which has a version of splitSearchPath which handles quotes in the same way as our custom version did. Test Plan: $ GHC_PACKAGE_PATH=/::/home: ./ghc-pkg list ... db stack: ["/",".","/home","<userdb>","<systemdb>"] ... Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D414 GHC Trac Issues: #2521, #9698 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2521#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8310: Can we change the semantics of `Trustworthy`?
by GHC 19 Nov '14

19 Nov '14

#8310: Can we change the semantics of `Trustworthy`? ------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- I would like to propose that if I put `{-# LANGUAGE Trustworthy #-}` on a module and it infers as Safe, then the module should get marked `Safe` instead of `Trustworthy`. Putting `Trustworthy` in right now has the semantics "it is at most `Trustworthy`". It would be far more useful to have the semantics "it is at least `Trustworthy`". The current situation is actually a maintenance nightmare. Currently, if I incur a dependency on a package has some `Safe` versions and some non-Safe versions, but I know I'm not using any unsafe componentry of it, I have to either a.) Mark my package Trustworthy unnecessarily enlarging the trusted code base a lot. b.) Track ALL of the dependencies of my dependencies to know when it will be Safe rather than Trustworthy, then insert brittle CPP pragmas that often fail. Consider that `hashable` 1.2.1.0 recently became flagged `Trustworthy`, but was previously not. Now, if I want to properly infer as `Safe`, I have to track the exact version of `hashable` I depend on _and_ whether or not my `Typeable` instance is being rolled manually and make an enormous composite `#ifdef` at the top of the module. Worse, we got the patch in about a month ago, so to future proof my code I'd have had to be psychic. Now consider that I have 50 other packages to maintain in this same manner. I wind up shotgunning `Trustworthy`, do deal with the fact that I deigned to provide instances for `vector`. If `vector` ever refactored to support Safe Haskell, I'd have to go fix up 50 very arcane CPP pragmas to match the internal details of an external package. Then I wind up checking them by round tripping through cabal installs and checking my haddocks. This is further complicated by the fact that some things are just becoming Safe "for free" as they go, due to the fact that they no longer need or can supply hand-rolled `Typeable` instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances
by GHC 19 Nov '14

19 Nov '14

#2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: D488 => Phab:D488 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2182#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim
by GHC 19 Nov '14

19 Nov '14

#8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | 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: | -------------------------------------+------------------------------------- Self-explanatory. Eq already has INLINE on (==) and (/=), and it'd be nice to have it on Ord so that SPECIALIZE pragmas on its methods in user code can fire. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8354> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64)
by GHC 19 Nov '14

19 Nov '14

#8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This appears to be the x86 assembly for a specialization for `even :: Int -> Bool` that's produced by a SPECIALISE pragma for `(^) :: Int -> Int -> Int` in GHC.Real. The relevant bit is offsets `0x2c` through `0x3b`. {{{ 0000000c <base_GHCziReal_evenzuzdseven1_info>: c: 8b 45 00 mov 0x0(%ebp),%eax f: c7 45 00 2c 00 00 00 movl $0x2c,0x0(%ebp) 12: R_386_32 .text 16: 89 c6 mov %eax,%esi 18: f7 c6 03 00 00 00 test $0x3,%esi 1e: 75 0c jne 2c <c8gO_info> 20: ff 26 jmp *(%esi) 22: 66 90 xchg %ax,%ax 24: 00 00 add %al,(%eax) 26: 00 00 add %al,(%eax) 28: 20 00 and %al,(%eax) ... 0000002c <c8gO_info>: 2c: b8 02 00 00 00 mov $0x2,%eax 31: 89 c1 mov %eax,%ecx 33: 8b 46 03 mov 0x3(%esi),%eax 36: 99 cltd 37: f7 f9 idiv %ecx 39: 85 d2 test %edx,%edx 3b: 75 0b jne 48 <c8gO_info+0x1c> 3d: be 02 00 00 00 mov $0x2,%esi 3e: R_386_32 ghczmprim_GHCziTypes_True_closure 42: 83 c5 04 add $0x4,%ebp 45: ff 65 00 jmp *0x0(%ebp) 48: be 01 00 00 00 mov $0x1,%esi 49: R_386_32 ghczmprim_GHCziTypes_False_closure 4d: 83 c5 04 add $0x4,%ebp 50: ff 65 00 jmp *0x0(%ebp) }}} It would be much better to do a simple `testb $0x1,0x3(%esi)` in place of the first six instructions of `c8gO_info`. The NCG generates similar code on x86_64. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8311> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8313: Poor performance of higher-order functions with unboxing
by GHC 19 Nov '14

19 Nov '14

#8313: Poor performance of higher-order functions with unboxing -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: slow unboxed | Operating System: Unknown/Multiple higher order | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- I was testing out some code to see how GHC handled some unboxed higher- order functions, and was suprised by the results I found. Here is some sample code: {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE MagicHash #-} import GHC.Exts import System.Environment rel# :: Int# -> Int# -> Int# -> Bool rel# i# j# k# = (i# +# j# +# k#) ># 100000000# rel :: Int -> Int -> Int -> Bool rel (I# i#) (I# j#) (I# k#) = rel# i# j# k# manual :: (Int# -> Int# -> Int# -> Bool) -> (Int, Int, Int) manual r# = go 0# 0# 0# where go i# j# k# | r# i# j# k# = (I# i#, I# j#, I# k#) | otherwise = go j# k# (i# +# 1#) {-# NOINLINE manual #-} auto :: (Int -> Int -> Int -> Bool) -> (Int, Int, Int) auto r = go 0 0 0 where go !i !j !k | r i j k = (i, j, k) | otherwise = go j k (i+1) {-# NOINLINE auto #-} main = getArgs >>= \case "manual" : _ -> print $ manual rel# -- This case is significantly slower. "auto" : _ -> print $ auto rel -- Why? }}} A loop that has to box its loop parameters to call a predicate turns out to be significantly faster than one that uses a predicate that takes unboxed values directly. The answer turns out to be (I believe) in ghc/utils/genapply/GenApply.hs. applyTypes has an entry [P,P,P], but only [N]. This means that the manual loop has to use a slower calling convention than the boxed loop. I'm not sure whether this should be 'fixed,' as my encounter with it was experimental in nature, and I don't have a real use case. The comment on applyTypes says its cases cover 99% of uses, and mine is not a real use. This ticket may serve as documentation at least, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8313> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8318: GHC does not infer type of `tagToEnum#` expression
by GHC 19 Nov '14

19 Nov '14

#8318: GHC does not infer type of `tagToEnum#` expression ----------------------------+---------------------------------------------- Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Compiling this program: {{{ {-# LANGUAGE MagicHash #-} module TTE where import GHC.Prim f = case tagToEnum# 1# of True -> "True" False -> "False" }}} gives a compilation error: {{{ [1 of 1] Compiling TTE ( tte.hs, tte.o ) tte.hs:6:10: tagToEnum# must appear applied to one argument In the expression: tagToEnum# 1# In the expression: case tagToEnum# 1# of { True -> "True" False -> "False" } In an equation for ‛f’: f = case tagToEnum# 1# of { True -> "True" False -> "False" } }}} To make it work one needs to supply type annotation for `tagToEnum#`: `case tagToEnum# 1# :: Bool of`. I would expect however that type will be inferred from type of patterns in the branches. Although I can imagine that things might get complicated for an ill-typed program: {{{ f = case tagToEnum# 1# of True -> "True" 3 -> "What now?" }}} If it is not possible to infer type of scrutinee based on patterns then I would expect to get more informative error message. Current one - `tagToEnum# must appear applied to one argument` - is very misleading. When I saw it for the first time it took me about 15 minutes to actually figure out what GHC expects me to do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8318> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8319: Simplifier ticks exhausted (need -fsimpl-tick-factor=955)
by GHC 19 Nov '14

19 Nov '14

#8319: Simplifier ticks exhausted (need -fsimpl-tick-factor=955) -----------------------------------+--------------------------------------- Reporter: ruudkoot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Attached file needs a rather high simpl-tick-factor (955) in order to compile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8324: ghci failed on startup
by GHC 19 Nov '14

19 Nov '14

#8324: ghci failed on startup ------------------------------------+------------------------------- Reporter: dabraham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- fred:~ danielabraham$ ghci 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. ghc: internal error: evacuate: strange closure type 0 (GHC version 7.6.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap fred:~ danielabraham$ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8336: Sinking pass does not
by GHC 19 Nov '14

19 Nov '14

#8336: Sinking pass does not ------------------------------+-------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Compiling this program: {{{ {-# LANGUAGE BangPatterns, MagicHash, CPP #-} {-# OPTIONS_GHC -O2 -funbox-strict-fields #-} module HashStr where import Foreign.C import GHC.Exts import Data.Word #define hASH_TBL_SIZE 4091 hashStr :: Ptr Word8 -> Int -> Int -- use the Addr to produce a hash value between 0 & m (inclusive) hashStr (Ptr a#) (I# len#) = loop 0# 0# where loop h n | n GHC.Exts.==# len# = I# h | otherwise = loop h2 (n GHC.Exts.+# 1#) where !c = ord# (indexCharOffAddr# a# n) !h2 = (c GHC.Exts.+# (h GHC.Exts.*# 128#)) `remInt#` hASH_TBL_SIZE# }}} produces following Cmm code for `hashStr` function: {{{ {offset cut: goto cux; cux: _stC::I64 = R3; _stB::I64 = R2; _stF::I64 = 0; _stE::I64 = 0; goto stD; stD: if (_stF::I64 == _stC::I64) goto cuH; else goto cuI; cuH: R1 = _stE::I64; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cuI: _stM::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091); _stF::I64 = _stF::I64 + 1; _stE::I64 = _stM::I64; goto stD; } }}} The problem here is that three last assignments: {{{ _stM::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091); _stF::I64 = _stF::I64 + 1; _stE::I64 = _stM::I64; }}} could be optimized as: {{{ _stE::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091); _stF::I64 = _stF::I64 + 1; }}} We should improve sinking pass so that it can optimize such cases. See Note [dependent assignments] in CmmSink. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2