October 2014 - ghc-tickets

Re: [GHC] #3658: Dynamically link GHCi (and use system linker) on platforms that support it
by GHC 20 Oct '14

20 Oct '14

#3658: Dynamically link GHCi (and use system linker) on platforms that support it -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 6.10.4 Resolution: fixed | Keywords: dynamic link Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 1883, | 3242, 3372, 3654, 4244, 5062, | 5197, 6107, 7072, 7103, 7316, | 7389, 7475, 7687 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 Comment: Moving out of 7.8.4 milestone, since it's not really appropriately 'fixed' here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3658#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9684: Broken build on OS X (incompatible pthread_setname_np API)
by GHC 20 Oct '14

20 Oct '14

#9684: Broken build on OS X (incompatible pthread_setname_np API) -------------------------------------+------------------------------------- Reporter: mlen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: MacOS X pthread_setname_np | Type of failure: Building Architecture: Unknown/Multiple | GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | 674c631ea111233daa929ef63500d75ba0db8858 -------------------------------------+------------------------------------- Build is broken on OS X because it is only possible to set thread name for the current thread and `pthread_setname_np` accepts a single argument. This function appeared in 10.6. If that OS version needs to be supported, the best thing that can be done is conditional compilation. A short summary of inconsistencies between different *nix systems can be found here: http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a -thread-in-pthreads-linux/7989973#7989973 The error log: {{{ rts/posix/OSThreads.c:138:30: error: too many arguments to function call, expected 1, have 2 pthread_setname_np(*pId, name); ~~~~~~~~~~~~~~~~~~ ^~~~ /usr/include/pthread.h:471:1: note: 'pthread_setname_np' declared here __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_2) ^ /usr/include/Availability.h:159:50: note: expanded from macro '__OSX_AVAILABLE_STARTING' #define __OSX_AVAILABLE_STARTING(_osx, _ios) __AVAILABILITY_INTERNAL##_osx ^ <scratch space>:65:1: note: expanded from here __AVAILABILITY_INTERNAL__MAC_10_6 ^ /usr/include/AvailabilityInternal.h:3912:72: note: expanded from macro '__AVAILABILITY_INTERNAL__MAC_10_6' #define __AVAILABILITY_INTERNAL__MAC_10_6 __attribute__((availability(macosx,introduced=10.6))) ^ 1 error generated. }}} I can see two possible solutions for OS X: 1. disable setting thread name by conditional compilation. 2. write some trampoline code to work around the fact that it is only possible to set thread name for the current thread. The latter would look like this: {{{ struct wrapper { char *name; void *param; void *(*cont)(void *); }; void *trampoline(void *ctx) { struct wrapper *params = (struct wrapper *)ctx; void *param = params->param; void *(*cont)(void *) = params->cont; #ifdef MACOSX pthread_setname_np(params->name); #elif pthread_setname_np(pthread_self(), params->name); #endif free(params); return cont(param); } int createOSThread (OSThreadId* pId, char *name, OSThreadProc *startProc, void *param) { struct wrapper *ctx = malloc(sizeof(struct wrapper)); ctx->name = name; ctx->cont = startProc; ctx->param = param; int result = pthread_create(pId, NULL, (void *(*)(void *))trampoline, &ctx); if (!result) { pthread_detach(*pId); } else { free(ctx); } return result; } }}} It looks very hackish and I think it'd be better to go with (1), since the original change was made for debugging purposes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9639: Remove OldTypeable
by GHC 20 Oct '14

20 Oct '14

#9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I think it's safe to remove `Data.OldTypeable` now. It's been deprecated in 7.8, and we said that we'd remove it for 7.10. This ticket is to record that task, and to check that there are no objections to removing it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

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 19 Oct '14

19 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 19 Oct '14

19 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