August 2013 - ghc-tickets

Re: [GHC] #7367: Optimiser / Linker Problem on amd64
by GHC 28 Aug '13

28 Aug '13

#7367: Optimiser / Linker Problem on amd64 --------------------------------------------+------------------------------ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Oh I missed that. `go` is recursive, but it only calls `f` as it exits. This refactoring would make that much clearer (including to the programmer), and GHC might even spot the linearity: {{{ flopS :: Perm -> (Int -> IO a) -> IO a flopS !xs f = do let go !acc = do k <- peekElemOff xs 0 if k == 0 then return acc else flop (fromIntegral k) xs >> go (acc+1) acc <- go 0 f acc }}} However your points about controlling floating remain. It would not be hard to add flags for "only float if the thing will get to top level" or "only float existing bindings, don't create new thunks". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 28 Aug '13

28 Aug '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.8.1 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 simonpj): OK qchen, you have the token. We need this in a week or two for the 7.8 release. Thanks! Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8179: Link error with unboxed tuples on Mac
by GHC 28 Aug '13

28 Aug '13

#8179: Link error with unboxed tuples on Mac ----------------------------------+--------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- If I try to compile {{{ {-# LANGUAGE UnboxedTuples #-} module Main where (# a, _ #) = (# 3, 4 #) main = putStrLn (show a) }}} with HEAD, I get this: {{{ rae:09:11:27 ~/temp> ghc UnboxedLinkBug.hs Linking UnboxedLinkBug ... Undefined symbols for architecture x86_64: "_rGh_info", referenced from: _s4up_info in libHSbase-4.7.0.0.a(Sync__199.o) "_rXE_closure", referenced from: _S1tr_srt in libHSbase-4.7.0.0.a(IO__63.o) "_rXE_info", referenced from: _base_GHCziIO_failIO_info in libHSbase-4.7.0.0.a(IO__63.o) "_r38J_closure", referenced from: _S5Dm_srt in libHSbase-4.7.0.0.a(Exception__229.o) _S5D9_srt in libHSbase-4.7.0.0.a(Exception__228.o) "_r38J_info", referenced from: _base_GHCziIOziException_ioError_info in libHSbase-4.7.0.0.a(Exception__229.o) _base_GHCziIOziException_ioException_info in libHSbase-4.7.0.0.a(Exception__228.o) "_r2ea_closure", referenced from: _S2qR_srt in libHSbase-4.7.0.0.a(FD__3.o) "_r2ea_info", referenced from: _c2qI_info in libHSbase-4.7.0.0.a(FD__3.o) "_r5MD_closure", referenced from: _S8aK_srt in libHSbase-4.7.0.0.a(Internals__76.o) "_r5MD_info", referenced from: _c8ab_info in libHSbase-4.7.0.0.a(Internals__76.o) "_r24R_info", referenced from: _s274_info in libHSbase-4.7.0.0.a(Show__131.o) _s275_info in libHSbase-4.7.0.0.a(Show__131.o) "_r2h7_closure", referenced from: _S2yV_srt in libHSbase-4.7.0.0.a(TopHandler__15.o) "_r2h7_info", referenced from: _s2kp_info in libHSbase-4.7.0.0.a(TopHandler__15.o) "_r2h8_info", referenced from: _s2kK_info in libHSbase-4.7.0.0.a(TopHandler__29.o) _s2kV_info in libHSbase-4.7.0.0.a(TopHandler__29.o) "_r3R1_closure", referenced from: _S5kw_srt in libHSbase-4.7.0.0.a(KQueue__98.o) "_r3R3_closure", referenced from: _S5kw_srt in libHSbase-4.7.0.0.a(KQueue__98.o) "_r3R1_info", referenced from: _s42n_info in libHSbase-4.7.0.0.a(KQueue__98.o) "_r3R3_info", referenced from: _c5ck_info in libHSbase-4.7.0.0.a(KQueue__98.o) _c5cr_info in libHSbase-4.7.0.0.a(KQueue__98.o) "_r6fy_closure", referenced from: _S9W4_srt in libHSbase-4.7.0.0.a(Manager__125.o) "_r6fy_info", referenced from: _c9TQ_info in libHSbase-4.7.0.0.a(Manager__125.o) _c9Uw_info in libHSbase-4.7.0.0.a(Manager__125.o) _c9V8_info in libHSbase-4.7.0.0.a(Manager__125.o) "_r6fB_closure", referenced from: _Sa8b_srt in libHSbase-4.7.0.0.a(Manager__134.o) "_r6fC_info", referenced from: _s6VE_info in libHSbase-4.7.0.0.a(Manager__134.o) _s6W2_info in libHSbase-4.7.0.0.a(Manager__134.o) "_r6fB_info", referenced from: _ca6u_info in libHSbase-4.7.0.0.a(Manager__134.o) _ca6B_info in libHSbase-4.7.0.0.a(Manager__134.o) "_r6f2_closure", referenced from: _S7AI_srt in libHSbase-4.7.0.0.a(Manager__71.o) "_r6f2_info", referenced from: _base_GHCziEventziManager_new3_info in libHSbase-4.7.0.0.a(Manager__71.o) "_rjV_closure", referenced from: _S7TU_srt in libHSbase-4.7.0.0.a(PSQ__35.o) _S7UF_srt in libHSbase-4.7.0.0.a(PSQ__37.o) _S6z6_srt in libHSbase-4.7.0.0.a(PSQ__14.o) _S6zR_srt in libHSbase-4.7.0.0.a(PSQ__16.o) _S88V_srt in libHSbase-4.7.0.0.a(PSQ__40.o) _S89G_srt in libHSbase-4.7.0.0.a(PSQ__42.o) "_rjV_info", referenced from: _base_GHCziEventziPSQ_zdLr4KKlvl18_info in libHSbase-4.7.0.0.a(PSQ__35.o) _base_GHCziEventziPSQ_zdLr4KMlvl20_info in libHSbase-4.7.0.0.a(PSQ__37.o) _base_GHCziEventziPSQ_zdLr4Ktlvl5_info in libHSbase-4.7.0.0.a(PSQ__14.o) _base_GHCziEventziPSQ_zdLr4Kvlvl7_info in libHSbase-4.7.0.0.a(PSQ__16.o) _base_GHCziEventziPSQ_zdLr4KOlvl22_info in libHSbase-4.7.0.0.a(PSQ__40.o) _base_GHCziEventziPSQ_zdLr4KQlvl24_info in libHSbase-4.7.0.0.a(PSQ__42.o) "_r4Kz_closure", referenced from: _S8mr_srt in libHSbase-4.7.0.0.a(PSQ__43.o) _S87q_srt in libHSbase-4.7.0.0.a(PSQ__38.o) "_r4KC_closure", referenced from: _S8mr_srt in libHSbase-4.7.0.0.a(PSQ__43.o) _S87q_srt in libHSbase-4.7.0.0.a(PSQ__38.o) "_r4KF_closure", referenced from: _S8mr_srt in libHSbase-4.7.0.0.a(PSQ__43.o) _S87q_srt in libHSbase-4.7.0.0.a(PSQ__38.o) "_r4KI_closure", referenced from: _S8mr_srt in libHSbase-4.7.0.0.a(PSQ__43.o) _S87q_srt in libHSbase-4.7.0.0.a(PSQ__38.o) "_r4KI_info", referenced from: _c8ec_info in libHSbase-4.7.0.0.a(PSQ__43.o) _c8ef_info in libHSbase-4.7.0.0.a(PSQ__43.o) _c8fh_info in libHSbase-4.7.0.0.a(PSQ__43.o) _c80g_info in libHSbase-4.7.0.0.a(PSQ__38.o) "_r4KF_info", referenced from: _c8eW_info in libHSbase-4.7.0.0.a(PSQ__43.o) _c8eZ_info in libHSbase-4.7.0.0.a(PSQ__43.o) _c8fh_info in libHSbase-4.7.0.0.a(PSQ__43.o) _c80g_info in libHSbase-4.7.0.0.a(PSQ__38.o) "_r4Kz_info", referenced from: _c8fh_info in libHSbase-4.7.0.0.a(PSQ__43.o) _c7Zb_info in libHSbase-4.7.0.0.a(PSQ__38.o) _c7Ze_info in libHSbase-4.7.0.0.a(PSQ__38.o) _c80g_info in libHSbase-4.7.0.0.a(PSQ__38.o) "_r4KC_info", referenced from: _c8fh_info in libHSbase-4.7.0.0.a(PSQ__43.o) _c7ZV_info in libHSbase-4.7.0.0.a(PSQ__38.o) _c7ZY_info in libHSbase-4.7.0.0.a(PSQ__38.o) _c80g_info in libHSbase-4.7.0.0.a(PSQ__38.o) "_r67G_closure", referenced from: _S6Wa_srt in libHSbase-4.7.0.0.a(Thread__19.o) "_r67G_info", referenced from: _base_GHCziEventziThread_ensureIOManagerIsRunning8_info in libHSbase-4.7.0.0.a(Thread__19.o) "_r67H_closure", referenced from: _S6WX_srt in libHSbase-4.7.0.0.a(Thread__22.o) "_r67H_info", referenced from: _base_GHCziEventziThread_getSystemEventManager2_info in libHSbase-4.7.0.0.a(Thread__22.o) "_r67Y_closure", referenced from: _S7D5_srt in libHSbase-4.7.0.0.a(Thread__46.o) "_r67X_closure", referenced from: _S7D5_srt in libHSbase-4.7.0.0.a(Thread__46.o) "_r67Y_info", referenced from: _s6hj_info in libHSbase-4.7.0.0.a(Thread__46.o) "_r67R_info", referenced from: _s6jc_info in libHSbase-4.7.0.0.a(Thread__46.o) "_r67X_info", referenced from: _c7zc_info in libHSbase-4.7.0.0.a(Thread__46.o) "_r689_closure", referenced from: _S7Xt_srt in libHSbase-4.7.0.0.a(Thread__61.o) "_r685_closure", referenced from: _S7Xt_srt in libHSbase-4.7.0.0.a(Thread__61.o) "_r683_closure", referenced from: _S7Xt_srt in libHSbase-4.7.0.0.a(Thread__61.o) "_r689_info", referenced from: _c7MC_info in libHSbase-4.7.0.0.a(Thread__61.o) "_r685_info", referenced from: _c7Qp_info in libHSbase-4.7.0.0.a(Thread__61.o) _c7Wn_info in libHSbase-4.7.0.0.a(Thread__61.o) "_r683_info", referenced from: _c7SP_info in libHSbase-4.7.0.0.a(Thread__61.o) _c7RL_info in libHSbase-4.7.0.0.a(Thread__61.o) "_r68b_closure", referenced from: _S8bF_srt in libHSbase-4.7.0.0.a(Thread__71.o) "_r68b_info", referenced from: _base_GHCziEventziThread_zdwa_info in libHSbase-4.7.0.0.a(Thread__71.o) _c89W_info in libHSbase-4.7.0.0.a(Thread__71.o) "_r68j_closure", referenced from: _S9kU_srt in libHSbase-4.7.0.0.a(Thread__90.o) "_r68h_closure", referenced from: _S9kU_srt in libHSbase-4.7.0.0.a(Thread__90.o) "_r68l_closure", referenced from: _S9kU_srt in libHSbase-4.7.0.0.a(Thread__90.o) "_r68f_closure", referenced from: _S9kU_srt in libHSbase-4.7.0.0.a(Thread__90.o) "_r68j_info", referenced from: _c8OY_info in libHSbase-4.7.0.0.a(Thread__90.o) _c8RR_info in libHSbase-4.7.0.0.a(Thread__90.o) _c8Yh_info in libHSbase-4.7.0.0.a(Thread__90.o) _c94v_info in libHSbase-4.7.0.0.a(Thread__90.o) _c9aS_info in libHSbase-4.7.0.0.a(Thread__90.o) "_r68h_info", referenced from: _s6Ay_info in libHSbase-4.7.0.0.a(Thread__90.o) _c8Tp_info in libHSbase-4.7.0.0.a(Thread__90.o) _s6D2_info in libHSbase-4.7.0.0.a(Thread__90.o) _c8ZP_info in libHSbase-4.7.0.0.a(Thread__90.o) _s6Ft_info in libHSbase-4.7.0.0.a(Thread__90.o) _c963_info in libHSbase-4.7.0.0.a(Thread__90.o) _s6HP_info in libHSbase-4.7.0.0.a(Thread__90.o) ... "_r68l_info", referenced from: _c8Tp_info in libHSbase-4.7.0.0.a(Thread__90.o) _c8ZP_info in libHSbase-4.7.0.0.a(Thread__90.o) _c963_info in libHSbase-4.7.0.0.a(Thread__90.o) _c9cm_info in libHSbase-4.7.0.0.a(Thread__90.o) _c9fM_info in libHSbase-4.7.0.0.a(Thread__90.o) "_r68f_info", referenced from: _c8Kp_info in libHSbase-4.7.0.0.a(Thread__90.o) _c9fM_info in libHSbase-4.7.0.0.a(Thread__90.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} I am on a Mac 10.7.5, with x86_64 architecture, and Xcode 4.3.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7367: Optimiser / Linker Problem on amd64
by GHC 28 Aug '13

28 Aug '13

#7367: Optimiser / Linker Problem on amd64 --------------------------------------------+------------------------------ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by rwbarton): Replying to [comment:8 simonpj]: > I don't think `flopS` uses its continuation linearly! > {{{ > flopS :: Perm -> (Int -> IO a) -> IO a > flopS !xs f = do > let go !acc = do > k <- peekElemOff xs 0 > if k == 0 then f acc else flop (fromIntegral k) xs >> go (acc+1) > go 0 > }}} Doesn't it though? `flopS` is just a single call to `go`, so it uses `f` linearly if `go` does. `go` performs an action unrelated to `f`, and then either it finishes by calling `f`, or it performs another action unrelated to `f` and then calls itself. So any run of `go` calls `f` exactly once, as a tail call (or it loops forever). Ah, perhaps you've misparsed `if k == 0 then f acc else flop (fromIntegral k) xs >> go (acc+1)` as `(if k == 0 then f acc else flop (fromIntegral k) xs) >> go (acc+1)`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 28 Aug '13

28 Aug '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -------------------------------------+------------------------------------ Reporter: edsko | Owner: edsko Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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 edsko): * version: 7.4.2 => 7.7 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 28 Aug '13

28 Aug '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -------------------------------------+------------------------------------ Reporter: edsko | Owner: edsko Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 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 edsko): * owner: => edsko -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 28 Aug '13

28 Aug '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 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 edsko): * status: infoneeded => new -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7367: Optimiser / Linker Problem on amd64
by GHC 28 Aug '13

28 Aug '13

#7367: Optimiser / Linker Problem on amd64 --------------------------------------------+------------------------------ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): I don't think `flopS` uses its continuation linearly! {{{ flopS :: Perm -> (Int -> IO a) -> IO a flopS !xs f = do let go !acc = do k <- peekElemOff xs 0 if k == 0 then f acc else flop (fromIntegral k) xs >> go (acc+1) go 0 }}} One call to `flopS` will give many calls to its argument `f`. Actually the new cardinality analyser does spot (and exploit) this kind of linearity. I'd be happy to hear more ideas as you get more familiar with GHC. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8186: Parallel comprehensions not allowed in Template Haskell quotes
by GHC 27 Aug '13

27 Aug '13

#8186: Parallel comprehensions not allowed in Template Haskell quotes ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When my code contains {{{ [| [ (x,y) | x <- [0..10] | y <- [0,5..50] ] |] }}} I get {{{ Exotic statement not (yet) handled by Template Haskell [x <- [0 .. 10] | y <- [0, 5 .. 50], (x, y)] }}} Interestingly, the node to handle parallel comprehensions (`ParS`) already exists in Template Haskell, but the code in !DsMeta is missing. I will submit a patch shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4219: sequence is not tail recursive, doesn't work with large inputs in strict monads
by GHC 27 Aug '13

27 Aug '13

#4219: sequence is not tail recursive, doesn't work with large inputs in strict monads -------------------------------+------------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Compiler | Version: 6.12.3 Resolution: wontfix | Keywords: sequence tail recursive Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nh2): * difficulty: => Unknown Comment: Another way to treat this is to make the stack size unbounded by default. As far as understand, this is now more feasible than it was when this bug was opened. This way, the user would not have problems with the operational semantics as originally asked for. (By the way, while in this bug the problem is seen as something hard to optimize, you could also understand using the stack for lists as an optimization that breaks things.) I opened http://ghc.haskell.org/trac/ghc/ticket/8189 to discuss the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4219#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0