- ghc-tickets - Haskell.org

Re: [GHC] #7942: aarch64 support in ghc
by GHC 20 Oct '14

20 Oct '14

#7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): the main patch seem to be https://github.com/lukexi/llvm/commit/dfe74bb48eb05ce7847fa262f6e563d20d0b1… and https://github.com/lukexi/ghc/commit/a80f4aa45d03caf72289d759c80c6490b20e70… I'll try to have a read through when I have some time -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 20 Oct '14

20 Oct '14

#7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * cc: petersen@… (removed) * cc: petersen (added) Comment: Thanks lukexi! That sounds great! Anyway I reported the current problems with building ghc-7.8.3 on aarch64 earlier in #9673. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate
by GHC 20 Oct '14

20 Oct '14

#3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4139 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by vlopez): * cc: victor@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3927#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7170: Foreign.Concurrent finalizer called twice in some cases
by GHC 20 Oct '14

20 Oct '14

#7170: Foreign.Concurrent finalizer called twice in some cases -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | ffi/should_run/7170 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by arybczak): * cc: hvr, ekmett (added) * owner: simonmar => * status: closed => new * resolution: fixed => * version: 7.4.2 => 7.8.3 Comment: This is still happening, albeit is much harder to reproduce (I wasn't able to write simple testcase for that). Steps to reproduce (hopefully): 1. git clone https://github.com/scrive/hpqtypes.git 2. git checkout 8b4d57876dc573759c2935064306806b793844c5 (this is the last commit before the workaround I applied to solve the issue) 3. git apply custom_finalizer.diff (to be sure it's haskell that tries to free the same memory twice) 4. Change tests/Main.hs to the following code: {{{ module Main where import Control.Applicative import Control.Concurrent import Control.Exception import Control.Monad import Debug.Trace import System.Environment import qualified Data.ByteString.Char8 as BS import Database.PostgreSQL.PQTypes mkConnSource :: String -> ConnectionSource mkConnSource ci = defaultSource $ defaultSettings { csConnInfo = BS.pack ci } main :: IO () main = do cs <- mkConnSource . head <$> getArgs let dts = defaultTransactionSettings flip finally (runDBT cs dts $ return ()) $ do void . forkIO $ do forM_ [1..100000::Int] $ \n -> trace (show n) $ return () return () threadDelay 1000000 }}} 4. cabal sandbox init 5. cabal install --dependencies-only 6. cabal configure -ftests --ghc-options="-O0" 7. cabal build 8. cd dist/build/tests 9. valgrind ./tests user=postgres The last step must be repeated a couple of times to get the error we are interested in. I attach the output of running it on my machine (valgrind- output.txt). If you look at the output file, at line 1112 I pressed Ctrl-C to interrupt the program, then the finalizer was called for the first time at line 1880 and then for the second time at line 2255, which results in tons of output from valgrind about invalid reads of already freed memory. Relevant file: https://github.com/scrive/hpqtypes/blob/8b4d57876dc573759c2935064306806b793… runDBT calls withConnection of the defaultSource (line 89), which is a simple wrapper for {{{bracket connect disconnect}}}. In disconnect (line 152) the destruction of the database connection is forced by calling finalizeForeignPtr. When finalizeForeignPtr is removed, the bug disappears. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7170#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9309: Regression when building the 'sizes' application
by GHC 19 Oct '14

19 Oct '14

#9309: Regression when building the 'sizes' application ----------------------------+---------------------------------------------- Reporter: | Owner: JohnWiegley | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 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: | ----------------------------+---------------------------------------------- I have a package on Hackage called `sizes`. It builds fine with GHC 7.8.2, but when building with 7.8.3 I get: ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): make_exp (App _ (Coercion _)) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #3543: -fext-core doesn't force recompilation when .hcr file doesn't exist
by GHC 19 Oct '14

19 Oct '14

#3543: -fext-core doesn't force recompilation when .hcr file doesn't exist -------------------------------------+------------------------------------- Reporter: tim | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Driver | Version: 6.10.4 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => wontfix Comment: External Core was removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3543#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8752: System.FilePath.Windows.combine does not really check isAbsolute
by GHC 19 Oct '14

19 Oct '14

#8752: System.FilePath.Windows.combine does not really check isAbsolute -------------------------------------+--------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Keywords: filepath | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- "Combine two paths, if the second path isAbsolute, then it returns the second.¨ But, the implementation of combine checks if the first character of a path is a path separator, which on Windows is not the same as checking if isAbsolute. This can have counterintuitive results. For example: {{{ import System.FilePath.Windows prop_windows_is_sane :: Bool prop_windows_is_sane = isAbsolute p || ("C:\\STUFF" </> p /= p) where p = "\\foo\\bar" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #670: External Core is broken
by GHC 19 Oct '14

19 Oct '14

#670: External Core is broken -------------------------------------+------------------------------------- Reporter: | Owner: tim KirstenChevalier | Status: closed Type: bug | Milestone: ⊥ Priority: normal | Version: 6.8.2 Component: External | Keywords: Core | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => wontfix Comment: External Core was removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/670#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_
by GHC 19 Oct '14

19 Oct '14

#9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D99 -------------------------------------+------------------------------------- During normal course of action in `real_main` a process is terminated with a call to {{{#!hs shutdownHaskellAndExit(exit_status, 0 /* !fastExit */); }}} which is defined as {{{#!hs void shutdownHaskellAndExit(int n, int fastExit) { if (!fastExit) { // even if hs_init_count > 1, we still want to shut down the RTS // and exit immediately (see #5402) hs_init_count = 1; // we're about to exit(), no need to wait for foreign calls to return. hs_exit_(rtsFalse); } stg_exit(n); } }}} However, when we call `forkProcess`, the child process does ''not'' terminate in this manner, but instead calls {{{#!hs hs_exit(); // clean up and exit stg_exit(EXIT_SUCCESS); }}} instead, where `hs_exit` is defined as {{{#!hs void hs_exit(void) { hs_exit_(rtsTrue); // be safe; this might be a DLL } }}} Crucially, this means that, unlike the parent, the child process ''does'' wait for foreign calls to be terminated (it calls `hs_exit_` with `rtsTrue` instead of `rtsFalse`). I don't see a reason why the child process should terminate in a different manner to the parent, so I propose to change this so that `forkProcess` calls `shutdownHaskellAndExit`, just like `real_main` does. Incidentally, this is the immediate cause for https://ghc.haskell.org/trac/ghc/ticket/9284 , although the patch proposed in this ticket is not sufficient to solve the problems with termination of the I/O manager in the general case (but I will let Andreas explain that in more detail :). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9340: Implement new `clz` inline primop
by GHC 18 Oct '14

18 Oct '14

#9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (CodeGen) | Differential Revisions: Keywords: primop clz | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- From a draft for #9281, I had to use a C FFI and using a gcc/clang `__builtin` to get access to the [http://en.wikipedia.org/wiki/Find_first_set CLZ instruction]: {{{#!hs -- | Compute base-2 log of 'Word#' -- -- This is internally implemented as count-leading-zeros machine instruction. foreign import ccall unsafe "integer_gmp_word_log2" wordLog2# :: Word# -> Int# }}} {{{#!c HsWord integer_gmp_word_log2(HsWord x) { #if (SIZEOF_HSWORD) == (SIZEOF_INT) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clz(x) : -1; #elif (SIZEOF_HSWORD) == (SIZEOF_LONG) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzl(x) : -1; #elif (SIZEOF_HSWORD) == (SIZEOF_LONG_LONG) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzll(x) : -1; #else # error unsupported SIZEOF_HSWORD #endif } }}} Since a `clz`-like operation should be available on most cpus GHC should expose that as a primop ({{{clz# :: Word# -> Int#}}}). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11