January 2014 - ghc-tickets

Re: [GHC] #2283: WIndows: loading objects that refer to DLL symbols
by GHC 28 Jan '14

28 Jan '14

#2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"25821cc9793c15e9860b3dcddf50aebf0eb718f7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="25821cc9793c15e9860b3dcddf50aebf0eb718f7" Win64 linker: fix loading foreign imports (#2283) Signed-off-by: Austin Seipp <austin(a)well-typed.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 28 Jan '14

28 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: fixed | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * blockedby: 3658 => Comment: Thank you Kyrill! Merged. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 28 Jan '14

28 Jan '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"28b031c506122e28e0230a562a4f6fd3d0256d0c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="28b031c506122e28e0230a562a4f6fd3d0256d0c" Refactor GCTDecl.h, and mitigate #7602 a bit This basically cleans a lot of GCTDecl up - I found it quite hard to read and a bit confusing. The changes are mostly cosmetic: better delineation between the alternative cases and light touchups, and tries to make every branch as consistent as possible. However, this patch does have one significant effect: it will ensure that any LLVM-based compilers will use __thread if they support it. Before, they would simply always use pthread_getspecific and pthread_setspecific, which are almost surely even *more* inefficient. The details are a bit too long and boring to go into here; see #7602. After talking with Simon, we decided to play it safe - __thread can at least be optimized by future clang releases even further on OS X if they choose, and it's safer until we can investigate the pthread implementation further on Mavericks. For Linux, the story isn't so bleak if you use Clang (for whatever reason) - Linux directly writes to `%fs` for __thread slots (while OS X will perform a load followed by an indirect call.) So it should still be fairly competitive, speed-wise. Signed-off-by: Austin Seipp <austin(a)well-typed.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7478: setSessionDynFlags does not always work
by GHC 28 Jan '14

28 Jan '14

#7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T7478 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I expect there's a mismatch between modules compiled with `-dynamic` and without, or something like that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7478#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5296: Add explicit type applications
by GHC 28 Jan '14

28 Jan '14

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (Type | Version: 7.0.3 checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Project (more Type of failure: GHC rejects | than a week) valid program | Blocked By: 1897 Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4466: Add extension for type application
by GHC 28 Jan '14

28 Jan '14

#4466: Add extension for type application -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4466#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7478: setSessionDynFlags does not always work
by GHC 28 Jan '14

28 Jan '14

#7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T7478 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: simonmar (added) * version: 7.6.1 => 7.7 * milestone: 7.6.2 => 7.8.1 Comment: On my 32bit linux machine (but not 64bit), I see the following test failure in a regular `./validate` run. It fails rather unhelpfully by just saying "phase 'Linker' failed (exitcode = 1)", but after patching the test to use `-v3` verbosity, I get this output: {{{ ... wired-in package ghc-prim mapped to ghc-prim-0.3.1.0-inplace wired-in package integer-gmp mapped to integer-gmp-0.5.1.0-inplace wired-in package base mapped to base-4.7.0.0-inplace wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-inplace wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *C.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2014-01-21 15:09:29.865159778 UTC ms_mod = main:Main, ms_textual_imps = [import (implicit) Prelude] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file C.hs *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 7, types: 7, coercions: 0} *** Simplifier: Result size of Simplifier = {terms: 7, types: 7, coercions: 0} *** Tidy Core: Result size of Tidy Core = {terms: 7, types: 7, coercions: 0} writeBinIface: 1 Names writeBinIface: 12 dict entries *** CorePrep: Result size of CorePrep = {terms: 7, types: 7, coercions: 0} *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** Assembler: /usr/bin/gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -x assembler-with-cpp -c /tmp/ghc7616_0/ghc7616_7.s -o C.o Upsweep completely successful. *** Deleting temp files: Deleting: /tmp/ghc7616_0/ghc7616_8.c /tmp/ghc7616_0/ghc7616_7.s /tmp/ghc7616_0/ghc7616_6.s Warning: deleting non-existent /tmp/ghc7616_0/ghc7616_8.c Warning: deleting non-existent /tmp/ghc7616_0/ghc7616_6.s link: linkables are ... LinkableM (2014-01-26 02:04:53.320777465 UTC) main:Main [DotO C.o] *** C Compiler: /usr/bin/gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc7616_0/ghc7616_9.c -o /tmp/ghc7616_0/ghc7616_10.o -I/home/a/ghc/rts/dist/build -I/home/a/ghc/includes -I/home/a/ghc/includes /dist-derivedconstants/header *** C Compiler: /usr/bin/gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc7616_0/ghc7616_11.s -o /tmp/ghc7616_0/ghc7616_12.o -I/home/a/ghc/rts/dist/build -I/home/a/ghc/includes -I/home/a/ghc/includes /dist-derivedconstants/header *** Linker: /usr/bin/gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -o A C.o -L/home/a/ghc/libraries/base/dist-install/build -Wl,-rpath-link -Wl,/home/a/ghc/libraries/base/dist-install/build -Wl,-rpath -Wl,/home/a/ghc/libraries/base/dist-install/build -L/home/a/ghc/libraries /integer-gmp/dist-install/build -Wl,-rpath-link -Wl,/home/a/ghc/libraries /integer-gmp/dist-install/build -Wl,-rpath -Wl,/home/a/ghc/libraries /integer-gmp/dist-install/build -L/home/a/ghc/libraries/ghc-prim/dist- install/build -Wl,-rpath-link -Wl,/home/a/ghc/libraries/ghc-prim/dist- install/build -Wl,-rpath -Wl,/home/a/ghc/libraries/ghc-prim/dist- install/build -L/home/a/ghc/rts/dist/build -Wl,-rpath-link -Wl,/home/a/ghc/rts/dist/build -Wl,-rpath -Wl,/home/a/ghc/rts/dist/build /tmp/ghc7616_0/ghc7616_10.o /tmp/ghc7616_0/ghc7616_12.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlers_closure -lHSbase-4.7.0.0-ghc7.7.20140122 -lHSinteger-gmp-0.5.1.0-ghc7.7.20140122 -lHSghc-prim-0.3.1.0-ghc7.7.20140122 -lHSrts-ghc7.7.20140122 -lffi -lgmp -lm -lrt -ldl '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads /usr/bin/ld: dynamic variable `base_GHCziBase_zdfMonadIO_closure' is zero size /usr/bin/ld: dynamic variable `ghczmprim_GHCziTuple_Z0T_closure' is zero size /usr/bin/ld: dynamic variable `base_GHCziTopHandler_runMainIO_closure' is zero size /usr/bin/ld: C.o(.text+0x3b): unresolvable R_386_32 relocation against symbol `base_GHCziBase_zdfMonadIO_closure' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status T7478: T7478: phase `Linker' failed (exitcode = 1) make[1]: *** [T7478] Error 1 }}} I haven't taken the time to fully track this down yet unfortunately. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7478#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8453: segfault/assertion failure with multi-threaded profiling
by GHC 27 Jan '14

27 Jan '14

#8453: segfault/assertion failure with multi-threaded profiling ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Steps to reproduce: {{{ ghc-stage2 selector_thunks.hs -rtsopts -fforce-recomp -prof -threaded -debug -O2 ./selector_thunk +RTS -N4 }}} In a few seconds, it either segfaults or dies with the following error message: {{{ selector_thunks: internal error: ASSERTION FAILED: file rts/dist/build/sm/Evac_thr.c, line 778 (GHC version 7.7.20131002 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} selector_thunks.hs: {{{ import Control.Monad import Control.Concurrent import Data.IORef main = do gref <- newIORef [return ()] forM_ [0::Int ..10] $ \_ -> forkIO $ do ref <- newIORef [return ()] forever $ do list <- readIORef gref writeIORef ref $! reverse list acts <- readIORef ref last acts forM_ [1..100000099] $ \i -> writeIORef gref $! reverse $ concatMap (replicate 10) $ mapfst $ foldr (\x y -> seq x (x : y)) [] $ map f [1..10+ (div i 1000000)] mapfst :: [(a, b)] -> [a] mapfst [] = [] mapfst (x:xs) = (case x of (a, _) -> a) : mapfst xs f :: Int -> (IO (), Int) f x = (x `seq` return (), x) }}} I only tested the code with a recent HEAD, but I have seen a similar assertion failure with GHC 7.6.3, in a non-contrived application program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 27 Jan '14

27 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"8f8bd88ce654828fef44378c3a4732d6941b9596/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f8bd88ce654828fef44378c3a4732d6941b9596" Fix the Win64 RTS linker & disable .ctors This fixes #7134 Signed-off-by: Austin Seipp <austin(a)well-typed.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7994: Make foldl into a good consumer
by GHC 27 Jan '14

27 Jan '14

#7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Heh, in the previous numbers, I passed the arguments to `nofib-analyze` in the wrong order. So please swap signs. I now made sure that the `oneShot` makes it into the unfolding for `foldl`, which is a clear win. Now, relative to `master` again, I get this very nice result: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem bernouilli -0.1% +1.5% 0.14 0.14 +0.0% cryptarithm2 -0.0% -0.5% 0.01 0.01 +0.0% fem -0.0% -2.8% 0.02 0.02 +0.0% fft2 -0.1% -55.9% 0.04 0.04 +0.0% gen_regexps -0.0% -33.6% 0.00 0.00 +0.0% integrate -0.1% -59.4% 0.13 0.13 -1.0% minimax -0.0% -15.6% 0.00 0.00 +0.0% nucleic2 +0.9% +1.7% 0.05 0.05 +0.0% scs -0.0% -0.9% +1.0% +0.5% +0.0% simple -0.1% -9.4% 0.14 0.14 +0.0% x2n1 -0.1% -74.5% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min -0.2% -74.5% -3.0% -3.0% -50.0% Max +0.9% +1.7% +4.0% +3.4% +10.4% Geometric Mean -0.0% -3.7% -0.2% -0.3% -0.6% }}} So it seems to be well worth turning `foldl` into a good consumer, even if the resulting code is not perfect for complicated cases like `foldl .. .. $ concat $ ..`. The increase for `bernouilli` comes from this code line: {{{ sum $ zipWith (*) powers (tail $ tail combs) }}} where originally, because `sum` is not a good consumer, no list fusion happens and a `sum` specialized to `Integer` is used, while after the change, `sum` is fused with `zipWith`, but not further, so now we have {{{ foldr2 (\x y r eta -> r (eta + (x * y))) id powers (tail $ tail combs) 0. }}} This means that we are have elimiated one intermediate list, but we are allocating PAP ’s on each iteration, which is more expensive (three arguments instead of two!). This is verified by looking at ticky numbers. Maybe foldr2 should have been inlined here. Or we just live with it. Is this (explicit `oneShot`ness-annotations using a magic function) a path we want to go? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7994#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0