February 2013 - ghc-tickets

[GHC] #7667: Template Haskell fails to recognize type operator/function +
by GHC 13 Apr '13

13 Apr '13

#7667: Template Haskell fails to recognize type operator/function + --------------------------------------+------------------------------------- Reporter: andygill | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- The following message is issued for a valid TH program. {{{ Main.hs:7:1: Illegal type constructor or class name: `+' When splicing a TH declaration: type instance GHC.TypeLits.+ 1 2 = 3 Failed, modules loaded: Test1. }}} Code attached. The program is attempting to capture the name +, as used by Nat at the type level. The problem appears to be in Convert.hs {{{ -- Convert.hs okOcc :: OccName.NameSpace -> String -> Bool okOcc _ [] = False okOcc ns str@(c:_) | OccName.isVarNameSpace ns = startsVarId c || startsVarSym c | otherwise = startsConId c || startsConSym c || str == "[]" }}} + is rejected, by okOcc, even though it is acceptable, the symbol neither starts with upper-case, or ':'. I have tried using reify to extract the *actual* name from other sources (rather than use mkNameG_tc), and it fails in the same way. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs
by GHC 13 Apr '13

13 Apr '13

#7666: excessive space and time usage for rendering (somewhat) deeply nested Docs -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Component: libraries/pretty Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I was running into serious performance problems when printing moderately sized Doc and Xml data (HaXml goes via Doc). Since pretty is shipped with ghc, this is potentially dangerous. Users will just assume that these core components are tried and tested, and working efficiently. More info: http://article.gmane.org/gmane.comp.lang.haskell.cafe/103210 See also: http://stackoverflow.com/questions/9761507/which-pretty-print-library Test case (builds an Xml tree with HaXml and renders it via the pretty library): https://github.com/jwaldmann/haskell-tpdb/blob/master/test/speed.hs -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7665: dynamicToo001 fails on Windows
by GHC 13 Apr '13

13 Apr '13

#7665: dynamicToo001 fails on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ `dynamicToo001` fails on Windows: {{{ =====> dynamicToo001(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory dynamicToo001 </dev/null >dynamicToo001.run.stdout 2>dynamicToo001.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Makefile:12: recipe for target `dynamicToo001' failed Stderr: A001.dyn_o:fake:(.text+0x2e): undefined reference to `__imp_stg_CAF_BLACKHOLE_info' A001.dyn_o:fake:(.text+0x5f): undefined reference to `__imp_newCAF' A001.dyn_o:fake:(.text+0x72): undefined reference to `__imp_stg_bh_upd_frame_info' A001.dyn_o:fake:(.text+0x87): undefined reference to `__imp_ghczmprim_GHCziTypes_Czh_con_info' c:/ghc64/git/cygwin/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: A001.dyn_o: bad reloc address 0x0 in section `.data' c:/ghc64/git/cygwin/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Invalid operation collect2: ld returned 1 exit status make[2]: *** [dynamicToo001] Error 1 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7659: Add some latency nofib benchmarks
by GHC 13 Apr '13

13 Apr '13

#7659: Add some latency nofib benchmarks -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Component: NoFib benchmark suite Version: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- At the moment, GHC is heavily throughput oriented (e.g. scheduler choices, etc). However, applications like Cloud Haskell often would like to reduce latency, even if it is at the cost of some throughput. However, we have no good way of measuring when changes to the RTS improve latency. We should add some benchmark programs along these lines. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7659> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7655: 7.4.2 Segmentation Fault/Bus Error in large exponentation
by GHC 13 Apr '13

13 Apr '13

#7655: 7.4.2 Segmentation Fault/Bus Error in large exponentation -----------------------+---------------------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.4.2 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------+---------------------------------------------------- Mac OS X 10.8.2. Haskell Platform 2012.4, 64-bit. GHCI 7.4.2. Large exponentations cause bus errors or segmentation faults. Examples: {{{ ~/src/haskell$ ghci GHCi, version 7.4.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. Prelude> 12345678901234567890 ^ 12345 Bus error: 10 ~/src/haskell$ ghci GHCi, version 7.4.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. Prelude> 2384729837498237^23455 Segmentation fault: 11 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7655> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7714: The type of the second argument of poll() in GHC/Event/Poll.hsc is invalid
by GHC 12 Apr '13

12 Apr '13

#7714: The type of the second argument of poll() in GHC/Event/Poll.hsc is invalid -----------------------------+---------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- poll() is used in GHC/Event/Poll.hsc. The type of its second argument is nfds_t. nfds_t is defined unsigned long on Linux and unsigned int on Mac/FreeBSD. FFI in Poll.hsc uses CULong instead of (#type nfds_t). So, this may cause a problem on Mac/FreeBSD. Actually, a web server compiled by GHC head on FreeBSD sometime causes the following error: {{{ mighty-head: c_poll: invalid argument (Invalid argument) mighty-head: sendWakeup: invalid argument (Bad file descriptor) mighty-head: sendWakeup: invalid argument (Bad file descriptor) mighty-head: sendWakeup: invalid argument (Bad file descriptor) }}} poll() on FreeBSD returns EINVAL when the specified time limit is negative. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7693: Flush .hp file at the end of each sample
by GHC 12 Apr '13

12 Apr '13

#7693: Flush .hp file at the end of each sample -----------------------------+---------------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Tools like hp2any-graph reads a .hp file as it's being written to. However writing to .hp files is currently block-buffered, causing a delay until the latest sample can be read. The attached patch adds a call to fflush every time a complete sample is written. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7727: Nonsense evaluation: sequence [] = []
by GHC 12 Apr '13

12 Apr '13

#7727: Nonsense evaluation: sequence [] = [] -----------------------------+---------------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ $ ghci-7.6.2 GHCi, version 7.6.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. >>> sequence [] [] >>> :t it it :: [()] >>> sequence [] :: [()] <interactive>:4:1: Couldn't match type `[a0]' with `()' Expected type: [()] Actual type: [[a0]] In the return type of a call of `sequence' In the expression: sequence [] :: [()] In an equation for `it': it = sequence [] :: [()] }}} Wat. Where on earth did ghci get the idea that {{{ sequence [] = [] }}}? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD)
by GHC 12 Apr '13

12 Apr '13

#7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) --------------------------------+------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Building GHC with parallel IO manager on Mac freezes when compiling the dph libraries in the phase 2. * This happens only if we specify "-j" to "make". Note that "make" closes stdin of sub-processes if "-j" is specified. * Even if we specify "-j" to "make", the problem disappears with stdout/stderr redirection. That is, "make -jN >& LOG &" works. * The "-d" option of "make" does not make any effects. * Programs compiled with built GHC (with our patches) work well. For test, I compiled a daemon HTTP server which closes stdin/stdout/stderr. It worked well. An IO manager is polling a kqueue fd. Another Haskell thread on another native thread registers an event through the same kqueue fd. In many cases, this works on Mac. In a certain situation, MacOS does not deliver an event to the IO manager. If the IO manager gets up and polls the kqueue fd, the event is delivered. This bug only appears when building GHC on Mac. I cannot find a simple way to reproduce it. Even if we find a way to reproduce it, I guess that we will probably reach a conclusion that this is a bug of kqueue of Mac. I have some evidences that kqueue of Mac is buggy: * http://comments.gmane.org/gmane.comp.lib.ev/1871 * http://lists.apple.com/archives/darwin-dev/2011/Jun/msg00016.html -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7651> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #7644: Hackage docs for base library contain broken links
by GHC 12 Apr '13

12 Apr '13

#7644: Hackage docs for base library contain broken links -----------------------------+---------------------------------------------- Reporter: JulesBean | 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: -----------------------------+---------------------------------------------- http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/GHC- IOArray.html Is a 404, presumably because it's {{{ {-# HADDOCK_OPTIONS hide #-} }}} so the haddocks don't get documented? However it is linked to from the master index http://hackage.haskell.org/package/base-4.6.0.0 ...which as far as I can see has links to all modules irrespective of whether they are hidden or not. A different example relates to source links: If you look at the Prelude docs here: http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Prelude.h… Then some of the source links point to URLs like http://hackage.haskell.org/packages/archive/%01/%02/doc/html/src/GHC- Classes.html#Ord ...which looks like some substitution operation has failed (%01 -> package name, %02 -> version, I presume). An attempt to manually fix the package name and version still leads to a 404. Some other source links from the Prelude are fine, though, for example: http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/src/GHC- Enum.html#Enum This is a regression but I don't know how recently; I certainly used to be able to follow links like that back in the 7.0 era, but I don't when it started failing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7644> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1