December 2015 - ghc-tickets

Re: [GHC] #7621: Cross-build for QNX ARM smashes stack when using FunPtr wrappers
by GHC 15 Dec '15

15 Dec '15

#7621: Cross-build for QNX ARM smashes stack when using FunPtr wrappers -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: ⊥ Component: Compiler (FFI) | Version: 7.7 Resolution: | Keywords: qnx | unregisterised cross-compile Operating System: QNX | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 7610 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => ⊥ Comment: This seems to have lost momentum. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7621#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9911: Pattern synonyms with no signatures should yield warnings
by GHC 15 Dec '15

15 Dec '15

#9911: Pattern synonyms with no signatures should yield warnings -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: PatternSynonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Unknown | warning at compile-time Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When `-fwarn-missing-signatures` is turned on, GHC should emit warnings for pattern synonyms with no signatures -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9911> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9923: Offer copy-on-GC sliced arrays
by GHC 15 Dec '15

15 Dec '15

#9923: Offer copy-on-GC sliced arrays -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.11 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It's sometimes useful to split an array and send each part on to a different computation. Slicing works very well for this sort of thing, as long as both computations run to completion or become garbage at about the same time. It can work badly, however, if one computation is completed or abandoned and the other is retained—it may only hold a tiny slice, but that's enough to keep the entire array alive. The alternative, currently, is to copy the array to form two new arrays. This gets rid of the retention problem, but introduces a performance problem. One way to solve these problems might be to offer sliced arrays supported by the RTS. On collection, the garbage collector would copy each slice separately, turning it into an independent (and independently collectible) array. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9931: Option to truncate Show output in ghci REPL
by GHC 15 Dec '15

15 Dec '15

#9931: Option to truncate Show output in ghci REPL -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Perhaps a configurable limit, with a :more (or :all) that would give you more if you ask for it. Seems pretty harmless and could help usability a bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9931> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11193: Strict extension does not make monadic bindings strict
by GHC 15 Dec '15

15 Dec '15

#11193: Strict extension does not make monadic bindings strict -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following two programs are not equivalent with respect to the strictness of `readFile`: {{{#!hs {-# LANGUAGE BangPatterns #-} module Main where main = do !contents <- readFile "foo.txt" print contents }}} And: {{{#!hs {-# LANGAUGE Strict #-} module Main where main = do contents <- readFile "foo.txt" print contents }}} Inspecting GHC Core for these two programs suggests that {{{#!hs !contents <- readFile "foo.txt" }}} is not equivalent to (with Strict enabled): {{{#!hs contents <- readFile "foo.txt" }}} Here's core using '''BangPatterns''': {{{ (readFile (unpackCString# "foo.txt"#)) (\ (contents_asg :: String) -> case contents_asg of contents1_Xsk { __DEFAULT -> print @ String $dShow_rYy contents1_Xsk }) }}} Here's core using '''Strict''': {{{ (readFile (unpackCString# "foo.txt"#)) (\ (contents_asg :: String) -> print @ String $dShow_rYv contents_asg) }}} Does this core align with the design of the Strict extension? If it does, are users going to understand that using Strict is going to make let/where bindings strict, but is not going to make `>>=` bindings strict? However, this is likely to just be a bug. At least, Johan Tibell and Adam Sandberg Eriksson, the designers and implementers of the `Strict` extension, believe this to be a bug: > Johan Tibell @ Thu Dec 10 14:34:39 UTC 2015 writes: > > I believe this is just a bug, since the desugaring ought to be strict in the \x. https://mail.haskell.org/pipermail/ghc-devs/2015-December/010747.html > Adam Sandberg Eriksson @ Thu Dec 10 15:26:17 UTC 2015 writes: > > I agree that this seems to be a bug. I have a lot to do currently, but might be able to look at it sometime during next week. https://mail.haskell.org/pipermail/ghc-devs/2015-December/010749.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9974: Allow more general structural recursion without UndecidableInstances
by GHC 15 Dec '15

15 Dec '15

#9974: Allow more general structural recursion without UndecidableInstances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I bet this is a duplicate, but I couldn't find it. A simple example from the `HList` package: {{{#!hs type family HRevApp (l1 :: [k]) (l2 :: [k]) :: [k] type instance HRevApp '[] l = l type instance HRevApp (e ': l) l' = HRevApp l (e ': l') }}} GHC 7.8.3 and 7.11 both complain about the second instance if `UndecidableInstances` is turned off, because the application is no smaller than the index head. Moreover, the same error occurs when the type family is closed. However, GHC already knows how to separate term-level definitions into recursive groups; applying this same analysis to the type family above would reveal that `HRevApp` is structurally recursive, and therefore decidable. It is key, in this case, that the instance for `[]` is visible from the instance declaration for `e ': l`, so such an analysis could only be done in module dependency order for open type families. Side note: there is a (nasty) workaround available for the problem in this case: {{{#!hs type family HRevApp' (l1 :: [k]) (l1' :: [k]) (l2 :: [k]) :: [k] type instance HRevApp' t '[] l = l type instance HRevApp' (e ': l) (e' ': l') l'' = HRevApp' l l' (e ': l'') type HRevApp l1 l2 = HRevApp' l1 l1 l2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9981: Potential typechecker regression in GHC 7.10.1RC
by GHC 15 Dec '15

15 Dec '15

#9981: Potential typechecker regression in GHC 7.10.1RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following snippet (extracted from hackage:index-core) is accepted by GHCs prior to GHC 7.10: {{{#!hs {-# LANGUAGE Rank2Types, TypeOperators #-} module Foo where type a :-> b = forall i . a i -> b i class IFunctor f where fmapI :: (a :-> b) -> (f a :-> f b) class (IFunctor m) => IMonad m where returnI :: a :-> m a bindI :: (a :-> m b) -> (m a :-> m b) (?>=) :: (IMonad m) => m a i -> (a :-> m b) -> m b i (?>=) = flip bindI }}} {{{ $ ghci-7.8.4 -Wall Foo.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Control.IMonad.Core ( Foo.hs, interpreted ) Ok, modules loaded: Control.IMonad.Core. λ:2> :browse type (:->) (a :: * -> *) (b :: * -> *) = forall i. a i -> b i class IFunctor (f :: (* -> *) -> * -> *) where fmapI :: (a :-> b) -> f a :-> f b class IFunctor m => IMonad (m :: (* -> *) -> * -> *) where returnI :: a i -> m a i bindI :: (a :-> m b) -> m a :-> m b (?>=) :: IMonad m => m a i -> (a :-> m b) -> m b i }}} vs. {{{ $ ghci-7.10.0.20141227 -Wall Foo.hs GHCi, version 7.10.0.20141227: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Control.IMonad.Core ( Foo.hs, interpreted ) Foo.hs:15:14: Couldn't match type ‘a i0 -> m b i0’ with ‘forall i1. a i1 -> m b i1’ Expected type: (a i0 -> m b i0) -> m a i -> m b i Actual type: a :-> m b -> m a i -> m b i Relevant bindings include (?>=) :: m a i -> a :-> m b -> m b i (bound at Foo.hs:15:1) In the first argument of ‘flip’, namely ‘bindI’ In the expression: flip bindI Failed, modules loaded: none. λ:2> }}} I'm not sure though whether that module was valid to begin with... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9996: Support symbols in GHCi tab completion
by GHC 15 Dec '15

15 Dec '15

#9996: Support symbols in GHCi tab completion -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Right now, when typing e.g. `>` followed by two tabs, GHCi shows every name in scope rather than just names beginning with `>`. It even lists operators as possible completions, but ignores it when you type the beginning of an operator's name. It would be better if it could actually complete every option it shows as a possible completion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11154: Problems using GHC-API on MacOS X
by GHC 15 Dec '15

15 Dec '15

#11154: Problems using GHC-API on MacOS X -------------------------------------+------------------------------------- Reporter: svenk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I followed the instructions on the Haskell wiki "GHC/As a library" to compile a Haskell file: '''Main.hs''' {{{#!hs import GHC import GHC.Paths ( libdir ) import DynFlags main = defaultErrorHandler defaultFatalMessager defaultFlushOut $ do runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags dflags target <- guessTarget "test.hs" Nothing setTargets [target] load LoadAllTargets }}} '''test.hs''' {{{#!hs main = putStrLn "hello" }}} I compile with ghc -package ghc -package ghc-paths --make Main.hs. When I execute ./Main, I get the following linking error: {{{ ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in _szZ_info from test.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie final section layout: __TEXT/__text addr=0x100000D40, size=0x00000206, fileOffset=0x00000D40, type=1 __TEXT/__stubs addr=0x100000F46, size=0x0000001E, fileOffset=0x00000F46, type=28 __TEXT/__stub_helper addr=0x100000F64, size=0x00000042, fileOffset=0x00000F64, type=32 __TEXT/__const addr=0x100000FA8, size=0x0000000C, fileOffset=0x00000FA8, type=0 __TEXT/__eh_frame addr=0x100000FB8, size=0x00000040, fileOffset=0x00000FB8, type=19 __DATA/__program_vars addr=0x100001000, size=0x00000028, fileOffset=0x00001000, type=30 __DATA/__got addr=0x100001028, size=0x00000010, fileOffset=0x00001028, type=29 __DATA/__nl_symbol_ptr addr=0x100001038, size=0x00000010, fileOffset=0x00001038, type=29 __DATA/__la_symbol_ptr addr=0x100001048, size=0x00000028, fileOffset=0x00001048, type=27 __DATA/__const addr=0x100001070, size=0x00000028, fileOffset=0x00001070, type=0 __DATA/__data addr=0x100001098, size=0x00000060, fileOffset=0x00001098, type=0 __DATA/__common addr=0x1000010F8, size=0x00000020, fileOffset=0x00000000, type=25 ld: 32-bit RIP relative reference out of range (-4294970840 max is +/-4GB): from _szZ_info (0x100000D98) to _ghczmprim_GHCziCString_unpackCStringzh_closure@0x0004A460 (0x00000000) in '_szZ_info' from test.o for architecture x86_64 clang-3.6: error: linker command failed with exit code 1 (use -v to see invocation) }}} I'm running the Nix package manager on MacOS X. Here are the compiler and linker commands for the GHC-API case. {{{ *** Assembler: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_2.s -o test.o Upsweep completely successful. *** Deleting temp files: Deleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_3.c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_2.s /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_1.s Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_3.c Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_1.s link: linkables are ... LinkableM (2015-12-02 09:23:41 UTC) Main [DotO test.o] Linking test ... *** C Compiler: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_4.c -o /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_5.o -I/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/include -fno-common -U__PIC__ -D__PIC__ *** Linker: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -o test -Wl,-no_compact_unwind test.o -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -L/nix/store /vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -Wl,-rpath -Wl,/nix/store/vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/nix/store /aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -Wl,-rpath -Wl,/nix/store /aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/rts /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_5.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_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_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_runHandlersPtr_closure -Wl,-search_paths_first -lHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw-ghc7.10.2 -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS-ghc7.10.2 -lHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.2 -lHSrts-ghc7.10.2 -lffi -liconv -lgmp -lm -ldl }}} And here is the compilation command for vanilla GHC: {{{ *** Assembler: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_2.s -o test.o Upsweep completely successful. *** Deleting temp files: Deleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_3.c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_2.s /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_1.s Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_3.c Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_1.s link: linkables are ... LinkableM (2015-12-02 09:21:48 UTC) Main [DotO test.o] Linking test ... *** C Compiler: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_4.c -o /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_5.o -I/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/include -fno-common -U__PIC__ -D__PIC__ *** Linker: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -o test -Wl,-no_compact_unwind test.o -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -L/nix/store /vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/nix/store /aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_5.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_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_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_runHandlersPtr_closure -Wl,-search_paths_first -lHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lCffi -liconv -lgmp -lm -ldl }}} I noticed the following differences: Some of the linked libraries in the API case contain a -ghc7.10.2 suffix, e.g. -lHSrts-ghc7.10.2. When I execute the linking command without the suffix everything works fine. So I looked into the directories of the referenced libraries. The rts directory contains the following content: {{{ libCffi.a libCffi_debug.a libCffi_l.a libCffi_p.a libCffi_thr.a libCffi_thr_debug.a libCffi_thr_l.a libCffi_thr_p.a libHSrts-ghc7.10.2.dylib libHSrts.a libHSrts_debug-ghc7.10.2.dylib libHSrts_debug.a libHSrts_l-ghc7.10.2.dylib libHSrts_l.a libHSrts_p.a libHSrts_thr-ghc7.10.2.dylib libHSrts_thr.a libHSrts_thr_debug-ghc7.10.2.dylib libHSrts_thr_debug.a libHSrts_thr_l-ghc7.10.2.dylib libHSrts_thr_l.a libHSrts_thr_p.a libffi.dylib }}} It seams that only the library with the .dylib extension also have the `-ghc7.10.2` suffix in the file name. So, is this an issue with ghc, MacOS X or Nix? Best, Sven -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11226: Performance regression (involving sum, map, enumFromThenTo)
by GHC 15 Dec '15

15 Dec '15

#11226: Performance regression (involving sum, map, enumFromThenTo) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program's performance suffers when compiled with 7.10, compared to 7.8: {{{ main = print $ sum $ map bitcount [0, 4 .. 2^24-1 ] bitcount :: Int -> Int bitcount x = if x > 0 then let (d,m) = divMod x 2 in bitcount d + m else 0 }}} See discussion in this thread: https://mail.haskell.org/pipermail/haskell- cafe/2015-December/122485.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6