January 2013 - ghc-tickets

Re: [GHC] #7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5
by GHC 15 Jan '13

15 Jan '13

#7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5 ------------------------------------------+--------------------------------- Reporter: PHO | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.7 Resolution: | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Comment(by PHO): I updated my [https://github.com/phonohawk/packages- base/commit/c7b2cc087a1202903e3042e842154d6166edde72 patch] for a temporary workaround but I think it shouldn't be merged as it will (hopefully) be soon unnecessary. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7537#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5
by GHC 15 Jan '13

15 Jan '13

#7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5 ------------------------------------------+--------------------------------- Reporter: PHO | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.7 Resolution: | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Comment(by PHO): You are right. This was indeed an autoconf bug so I sent a patch to the autoconf folks: [http://lists.gnu.org/archive/html/bug- autoconf/2013-01/msg00040.html AC_SYS_LARGEFILE: define _DARWIN_USE_64_BIT_INODE conditionally] -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7537#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7299: threadDelay broken in ghci, Mac OS X
by GHC 15 Jan '13

15 Jan '13

#7299: threadDelay broken in ghci, Mac OS X ---------------------------------+------------------------------------------ Reporter: tmcdonell | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.6.2 Component: GHCi | Version: 7.6.1 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by igloo): Looks like this is related to us having 2 copies of the base library around. The crash happens sometime around a call to `absolute_time` in `libraries/base/cbits/DarwinUtils.c`. This file doesn't exist in 7.4, which explains why it worked then. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7299#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7524: Erroneous repeated kind variable in conflicting type family instance error message
by GHC 15 Jan '13

15 Jan '13

#7524: Erroneous repeated kind variable in conflicting type family instance error message ----------------------------------------------+----------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: #7587 ----------------------------------------------+----------------------------- Changes (by goldfire): * related: => #7587 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7524#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7584: OperationalError: database is locked
by GHC 15 Jan '13

15 Jan '13

#7584: OperationalError: database is locked -----------------------------+---------------------------------------------- Reporter: Heimdell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- ==== How to Reproduce ==== While doing a GET operation on `/report/8`, Trac issued an internal error. I just pressed on the 'ticket' column twice - to sort it descending. Request parameters: {{{ {'USER': u'Heimdell', 'asc': u'0', 'id': u'8', 'sort': u'ticket'} }}} ==== System Information ==== || '''Trac''' || `0.11.6` || || '''Python''' || `2.5.2 (r252:60911, Jan 24 2010, 18:02:01) ` [[br]] `[GCC 4.3.2]` || || '''setuptools''' || `0.6c8` || || '''SQLite''' || `3.5.9` || || '''pysqlite''' || `2.3.2` || || '''Genshi''' || `0.5.1` || || '''mod_python''' || `3.3.1` || || '''Pygments''' || `0.10` || || '''GIT''' || `1.5.6.5` || || '''FullBlog''' || `0.1.1` || || '''RPC''' || `1.0.6` || || '''CustomFieldAdmin''' || `0.2.2` || ==== Python Traceback ==== {{{ Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 450, in _dispatch_request dispatcher.dispatch(req) File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 229, in dispatch req.session.save() File "/usr/lib/python2.5/site-packages/trac/web/session.py", line 100, in save (self.sid,)) File "/usr/lib/python2.5/site-packages/trac/db/util.py", line 64, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 80, in execute PyFormatCursor.execute(self, *args) File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 59, in execute args or []) File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 51, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: database is locked }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7562: Parse error with {-# UNPACK #-} Int
by GHC 15 Jan '13

15 Jan '13

#7562: Parse error with {-# UNPACK #-} Int ---------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: typecheck/should_compile/T7562 | Blockedby: Blocking: | Related: ---------------------------------------------+------------------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed * testcase: => typecheck/should_compile/T7562 Comment: Good idea, thanks. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7562#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7583: IO reordering
by GHC 15 Jan '13

15 Jan '13

#7583: IO reordering ----------------------------------------+----------------------------------- Reporter: Heimdell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.1 | Keywords: IO, invalid evaluation order Os: Linux | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- I have a simple test program: {{{ main = do putStr "> " line <- getLine putStrLn line }}} In ghci, it writes "> " before receiving input: {{{ Prelude Main> main > WHAT WHAT }}} But being compiled by ghc it writes "> " just after receiving input. {{{ maelstrom@ubuntu:~/vault$ ./test WHAT > WHAT }}} That is not the behavior I expect. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7583> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7582: Created thunk gets immediately evaluated
by GHC 15 Jan '13

15 Jan '13

#7582: Created thunk gets immediately evaluated -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following function, taken from the unordered-containers package, is obviously strict in `go`: {{{ lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v lookup k0 = go h0 k0 0 where h0 = hash k0 go !_ !_ !_ Empty = Nothing go h k _ (Leaf hx (L kx x)) | h == hx && k == kx = Just x -- TODO: Split test in two | otherwise = Nothing go h k s (BitmapIndexed b v) | b .&. m == 0 = Nothing | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m)) where m = mask h s go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) go h k _ (Collision hx v) | h == hx = lookupInArray k v | otherwise = Nothing {-# INLINABLE lookup #-} }}} Here's a small test program that uses `lookup`: {{{ module Test (test) where import qualified Data.HashMap.Strict as HM test :: Int -> HM.HashMap Int Int -> Maybe Int test k m = HM.lookup k m }}} And here's part of the Core: {{{ $slookup :: forall v_aBR. Int -> HashMap Int v_aBR -> Maybe v_aBR $slookup = \ (@ v_XBT) (k0_aBU :: Int) -> let { w_sM9 :: Hash w_sM9 = case defaultSalt of _ { I# x#_aJq -> case k0_aBU of _ { I# i_aJv -> case {__pkg_ccall hashable-1.2.0.5 hashable_wang_64 Word# -> State# RealWorld -> (# State# RealWorld, Word# #)}_aJu (xor# (int2Word# x#_aJq) (int2Word# i_aJv)) realWorld# of _ { (# _, ds1_aJA #) -> W# ds1_aJA } } } } in \ (w1_sMl :: HashMap Int v_XBT) -> case w_sM9 of _ { W# ww_sMb -> case k0_aBU of _ { I# ww1_sMf -> $wpoly_go @ v_XBT ww_sMb ww1_sMf 0 w1_sMl } } test :: Int -> HashMap Int Int -> Maybe Int test = \ (k_asN :: Int) (m_asO :: HashMap Int Int) -> $slookup @ Int k_asN m_asO }}} Note how `w_sM9`, corresponding to `h0` in the source program, has wedged itself in-between two lambdas, causing unnecessary allocation. If we put a bang on `h0` in the definition of `lookup`, we get this much better looking Core: {{{ $w$slookup :: forall v_aBQ. Int# -> HashMap Int v_aBQ -> Maybe v_aBQ $w$slookup = \ (@ v_aBQ) (ww_sMt :: Int#) -> case defaultSalt of _ { I# x#_aJt -> case {__pkg_ccall hashable-1.2.0.5 hashable_wang_64 Word# -> State# RealWorld -> (# State# RealWorld, Word# #)}_aJx (xor# (int2Word# x#_aJt) (int2Word# ww_sMt)) realWorld# of _ { (# _, ds1_aJD #) -> \ (w_sMo :: HashMap Int v_aBQ) -> $wpoly_go @ v_aBQ ds1_aJD ww_sMt 0 w_sMo } } $slookup :: forall v_aBQ. Int -> HashMap Int v_aBQ -> Maybe v_aBQ $slookup = \ (@ v_aBQ) (w_sMr :: Int) -> case w_sMr of _ { I# ww_sMt -> $w$slookup @ v_aBQ ww_sMt } test :: Int -> HashMap Int Int -> Maybe Int test = \ (k_asM :: Int) (m_asN :: HashMap Int Int) -> case k_asM of _ { I# ww_sMt -> $w$slookup @ Int ww_sMt m_asN } }}} This bothers me. `h0` gets immediately passed to `go`, which is strict. Why does it get boxed? Why does the extra bang make a difference? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7581: ghc crashed on trying compiling a file generated by Alex
by GHC 15 Jan '13

15 Jan '13

#7581: ghc crashed on trying compiling a file generated by Alex -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- C:\Documents and Settings\bcyrille\My Documents\Hskl>ghc M90.hs [1 of 1] Compiling Main ( M90.hs, M90.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.2 for i386-unknown-mingw32): nameModule show{tv aqY} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Alex version is 3.0.2 ghc version is 7.4.2 (haskell platform 2012.4.0.0) Can't give much details, first time using Alex... attaching the files -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7299: threadDelay broken in ghci, Mac OS X
by GHC 15 Jan '13

15 Jan '13

#7299: threadDelay broken in ghci, Mac OS X ---------------------------------+------------------------------------------ Reporter: tmcdonell | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.6.2 Component: GHCi | Version: 7.6.1 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by lerkok): * cc: erkokl@… (added) Comment: I can reproduce this on Snow Leopard with GHC 7.6.1. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7299#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0