June 2014 - ghc-tickets

[GHC] #8939: Should check the return value of clock_gettime
by GHC 08 Jun '14

08 Jun '14

#8939: Should check the return value of clock_gettime -------------------------------------------+------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In `ghc-7.6.3/rts/posix/GetTime.c`, function `StgWord64 getMonotonicNSec(void)`: The return value of `clock_gettime` should be checked, and if the value is not 0 (success), it should fall back to `gettimeofday`. The following patch demonstrates a possible fix: {{{ --- pre/rts/posix/GetTime.c 2013-04-18 17:22:47.000000000 -0400 +++ ghc-7.6.3/rts/posix/GetTime.c 2014-03-28 09:52:08.537125998 -0400 @@ -84,19 +82,22 @@ #ifdef HAVE_CLOCK_GETTIME struct timespec ts; + int res= clock_gettime(CLOCK_ID, &ts); + if(res==0) return (StgWord64)ts.tv_sec * 1000000000 + (StgWord64)ts.tv_nsec; #elif defined(darwin_HOST_OS) uint64_t time = mach_absolute_time(); return (time * timer_scaling_factor_numer) / timer_scaling_factor_denom; -#else +#endif + { //fallback struct timeval tv; gettimeofday(&tv, (struct timezone *) NULL); return (StgWord64)tv.tv_sec * 1000000000 + (StgWord64)tv.tv_usec * 1000; -#endif + } } Time getProcessElapsedTime(void) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS
by GHC 08 Jun '14

08 Jun '14

#4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by hvr): * milestone: ⊥ => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4934#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #95: GHCi :edit command should jump to the the last error
by GHC 08 Jun '14

08 Jun '14

#95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: martijnislief | Status: patch Type: feature | Milestone: ⊥ request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by lortabac): * cc: hvr (added) * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/95#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS
by GHC 08 Jun '14

08 Jun '14

#4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonmar): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4934#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8973: Fewer CPSZ: lines with -dshow-passes
by GHC 08 Jun '14

08 Jun '14

#8973: Fewer CPSZ: lines with -dshow-passes ------------------------------------+------------------------------------- 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: | ------------------------------------+------------------------------------- `-dshow-passes` generates {{{ *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** Assembler: }}} All those CPSZ things are not helping! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS
by GHC 08 Jun '14

08 Jun '14

#4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Marlow <marlowsd@…>): In [changeset:"9fd507e5758f4141ac2619f0db57136bcab035c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9fd507e5758f4141ac2619f0db57136bcab035c6" Raise exceptions when blocked in bad FDs (fixes Trac #4934) Before the patch any call to 'select()' with 'bad_fd' led to: - unblocking of all threads - hiding exception for 'threadWaitRead bad_fd' The patch fixes both cases in this way: after 'select()' failure we iterate over each blocked descriptor and poll individually to see it's actual status, which is: - READY (move to run queue) - BLOCKED (leave in blocked queue) - INVALID (send an IOErrror exception) Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4934#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure
by GHC 08 Jun '14

08 Jun '14

#8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure -------------------------------------------+------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In GHC 7.6, `rts/posix/GetTime.c, Time getProcessCPUTime(void)`: if the result of `clock_gettime` is not zero (success), then the function should fall back to getrusage below instead of aborting with {{{ sysErrorBelch("clock_gettime"); stg_exit(EXIT_FAILURE); }}} The following patch demonstrates a possible fix: {{{ --- pre/rts/posix/GetTime.c 2013-04-18 17:22:47.000000000 -0400 +++ ghc-7.6.3/rts/posix/GetTime.c 2014-03-28 09:52:08.537125998 -0400 @@ -64,10 +64,8 @@ res = clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts); if (res == 0) { return SecondsToTime(ts.tv_sec) + NSToTime(ts.tv_nsec); - } else { - sysErrorBelch("clock_gettime"); - stg_exit(EXIT_FAILURE); } + // else fallback } #endif }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8942: Duplicate symbol error when loading an archive twice
by GHC 08 Jun '14

08 Jun '14

#8942: Duplicate symbol error when loading an archive twice ------------------------------------+------------------------------- Reporter: gelisam | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | ------------------------------------+------------------------------- ghci can load packages from object files (*.o) and from archive files (*.a). When an object file is loaded twice, the second attempt is silently ignored. When an archive file is loaded twice, ghci aborts with the message "fatal error: I found a duplicate definition for symbol ''s''", for the first symbol ''s'' in the archive. === Patch The attached patch changes {{{rts/Linker.c}}} so that loading an archive file twice silently ignores the second attempt, just like it does with object files. === Repro steps Install a package using Cabal 1.18.*, as that version only produces archives and not objects. Then, force ghci to load that package twice. One way to do this is to use hint inside ghci to load a value from the package. {{{ $ ghci > import Hello > import Language.Haskell.Interpreter > r <- runInterpreter $ setImports ["Hello"] >> interpret "Hello" (as :: Hello) Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package filepath-1.3.0.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package unix-2.6.0.1 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package old-time-1.1.0.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package process-1.1.0.2 ... linking ... done. Loading package Cabal-1.16.0 ... linking ... done. Loading package binary-0.5.1.1 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.9.0.0 ... linking ... done. Loading package hpc-0.6.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package ghc-7.6.3 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package hello-0.1.0.0 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package exceptions-0.3.3.1 ... linking ... done. Loading package extensible-exceptions-0.1.1.4 ... linking ... done. Loading package ghc-mtl-1.1.0.0 ... linking ... done. Loading package ghc-paths-0.1.0.9 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package hint-0.4.0.0 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol ___stginit_hellozm0zi1zi0zi0_Hello whilst processing object file /Users/gelisam/.cabal/lib/x86_64-osx- ghc-7.6.3/hello-0.1.0.0/libHShello-0.1.0.0.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} A minimal definition for the hello package is attached, but doesn't contain anything relevant to the issue. It's just a dummy datatype: {{{#!haskell {-# LANGUAGE DeriveDataTypeable #-} module Hello where import Data.Typeable data Hello = Hello deriving Typeable }}} === Workaround Use Cabal 1.16, which (also) installs object files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8942> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4836: literate markdown not handled correctly by unlit
by GHC 08 Jun '14

08 Jun '14

#4836: literate markdown not handled correctly by unlit ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7120 ----------------------------------------------+---------------------------- Comment (by dominic): With your patches for markdown and a .md file {{{ ### Ok so lets try this again. ### A page that loads and compiles: ``` module Main where myfact 0 = 1 myfact n = n * n-1 main = putStrLn (show (myfact 5)) ``` Lets see if it works! [ghci] :!which ghc myfact 5 }}} this compiles so hurrah! But BlogLiteraly does '''not''' a) do syntax highlighting b) evaluate "myfact 5" {{{ ~/ghc $ BlogLiteratelyD --ghci TheLitTest.md <h3 id="ok-so-lets-try-this-again.">Ok so lets try this again.</h3> <h3 id="a-page-that-loads-and-compiles">A page that loads and compiles:</h3> <pre><code>module Main where myfact 0 = 1 myfact n = n * n-1 main = putStrLn (show (myfact 5))</code></pre> Lets see if it works! <pre><code>ghci> :!which ghc /usr/local/bin/ghc ghci> myfact 5</code></pre> <div class="references"> </div> }}} On the other hand with a .lhs file {{{ ### Ok so lets try this again. ### A page that loads and compiles: module Main where > myfact 0 = 1 > myfact n = n * n-1 > main = putStrLn (show (myfact 5)) Lets see if it works! [ghci] :!which ghc myfact 5 }}} This does not compile {{{ ~/ghc $ ./inplace/bin/ghc-stage2 TheLitTest.lhs TheLitTest.lhs:1:2: lexical error at character '#' }}} But BlogLiterately produces code which is syntax highlighted and evaluates "myfact 5". {{{ ~/ghc $ BlogLiteratelyD --ghci TheLitTest.lhs <h3 id="ok-so-lets-try-this-again.">Ok so lets try this again.</h3> <h3 id="a-page-that-loads-and-compiles">A page that loads and compiles:</h3> module Main where <pre class="sourceCode haskell"><code class="sourceCode haskell">> myfact 0 = 1 > myfact n = n * n-1 </code></pre> <pre class="sourceCode haskell"><code class="sourceCode haskell">> main = putStrLn (show (myfact 5)) </code></pre> Lets see if it works! <pre><code>ghci> :!which ghc /usr/local/bin/ghc ghci> myfact 5 24 </code></pre> <div class="references"> </div> }}} I've discussed this ticket (not BlogLiterately) with Simon Marlow and we concluded that we should try changing the order of unlit and cpp. There may be literate programs which have e.g. #ifdef in their literate (non- code / not in chevrons) block and these will now fail but we concluded that this is the correct behaviour (I hope I am not misquoting Simon here). If this works then I think supporting .md files becomes more straightforward and BlogLiterately will work (and I will remove the workaround that Brent put in to make it handle # correctly when it calls ghci). Does that make sense? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4836#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #368: Provide a Java Backend
by GHC 08 Jun '14

08 Jun '14

#368: Provide a Java Backend ----------------------------+---------------------------------------------- Reporter: | Owner: rainbowang | Status: closed Type: feature | Milestone: ⊥ request | Version: None Priority: lowest | Keywords: Component: | Architecture: Unknown/Multiple Compiler | Difficulty: Project (more than a week) Resolution: wontfix | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: None => wontfix Comment: Tickets like this don't really serve a useful purpose, closing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/368#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0