March 2013 - ghc-tickets

[GHC] #7624: Handling ImplicitParams in Instance Declaration
by GHC 13 Apr '13

13 Apr '13

#7624: Handling ImplicitParams in Instance Declaration ------------------------------+--------------------------------------------- Reporter: philipjf | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.1 | Keywords: ImplicitParams Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- The GHC documentation states that ImplicitParam's may not be used in class or instance declaration constraints. see for example http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/other-type- extensions.html In practice though, at least on the Mac, all recent version of GHC have permitted such instances. At the very least the documentation should make clear that the compiler might permit such instances, but they have undefined behaviour. Ideally, these would simply be permitted. [http://joyoftypes.blogspot.com/2013/01/using-compiler-bugs-for-fun-and- profit.html Why I think the (undocumented) current behavior is correct] -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7623: GHC Arm support
by GHC 13 Apr '13

13 Apr '13

#7623: GHC Arm support -------------------------------+-------------------------------------------- Reporter: dterei | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: arm Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Top level to track some important fixes for proper ARM support of GHC. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7623> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #7619: Make worker-wrapper unbox data families
by GHC 13 Apr '13

13 Apr '13

#7619: Make worker-wrapper unbox data families -----------------------------+---------------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: type family Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I noticed that the worker-wrapper optimization doesn't unbox arguments whose type is a data family instance. For example in this module: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE BangPatterns #-} module Foo where data family Foo a data instance Foo Int = FooInt Int Int foo :: Foo Int -> Int foo (FooInt a b) = loop a b where loop 0 y = length $ replicate y b loop x !y = loop (mod y x) x foo1 :: (Int, Int) -> Int foo1 (a, b) = loop a b where loop 0 y = length $ replicate y b loop x !y = loop (mod y x) x }}} foo and foo1 both get worker-wrapper applied, with worker functions of the following types: {{{ $wfoo :: Foo Int -> Int# $wfoo1 :: Int# -> Int# -> Int# }}} It would be nice if $wfoo could get the same type as $wfoo1. This issue happened in real life with unboxed vectors from the vector package, resulting in a lot of boxing with unboxed vector constructors immediately followed by unboxing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7618: Multiline prompt ignores custom prompt
by GHC 13 Apr '13

13 Apr '13

#7618: Multiline prompt ignores custom prompt -------------------+-------------------------------------------------------- Reporter: dunric | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Other | Blockedby: Blocking: | Related: #5209 -------------------+-------------------------------------------------------- 1. start a ghci session Prelude> 2. set some custom prompt Prelude> :set prompt "GHCi> " GHCi> 3. start a multiline command GHCi> :{ Prelude| Expected "GHCi| " as the custom prompt in multiline command. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7618> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7612: Automatically start the haskell runtime in DllMain on windows -shared
by GHC 13 Apr '13

13 Apr '13

#7612: Automatically start the haskell runtime in DllMain on windows -shared ----------------------------+----------------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: ----------------------------+----------------------------------------------- On Windows DllMain is called when a dll is loaded into a process via LoadLibrary (or even when it's loaded as a regular dependency). Currently a stub, such as this, is required to be linked with all haskell dll compilations on windows that plan to have their functions called from non-haskell origins; {{{ #include <windows.h> #include <Rts.h> EXTFUN(__stginit_Adder); static char* args[] = { "ghcDll", NULL }; /* N.B. argv arrays must end with NULL */ BOOL STDCALL DllMain ( HANDLE hModule , DWORD reason , void* reserved ) { if (reason == DLL_PROCESS_ATTACH) { /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */ startupHaskell(1, args, __stginit_Adder); return TRUE; } return TRUE; } }}} see outdated documentation, but still mostly applicable: http://www.haskell.org/ghc/docs/5.04/html/users_guide/win32-dlls- foreign.html I personally think this is a tad silly and could be easily improved. Ideally, DllMain should automatically detect if the runtime is running, and if not, automatically start it up so that the dll's ordinals can all be called freely. This could be a stub automatically added by ghc when the windows -shared is used. An extension to this would be to add a pragma/flag to allow people to execute code inside DllMain (dllMain, a pragma, maybe?) after the runtime has started. One extremely easy way to do this would be to assume main as being :: Int -> IO Int where the first bound argument is the attach reason when windows -shared is used. This would GREATLY improve how easy it is to call haskell dll's from other languages, even .net origins, etc. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7612> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x))
by GHC 13 Apr '13

13 Apr '13

#7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x)) -----------------------------+---------------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I’m moving the discussion from http://www.haskell.org/pipermail/glasgow-haskell- users/2013-January/023522.html (with reply at http://www.haskell.org/pipermail/glasgow-haskell- users/2013-January/023531.html) here, as a reminder for myself to work on it someday: Short summary: a rule "map (\x -> x) = id" will not match "map id" because the latter has (in Core) an application of a type variable, despite the matcher looking through the definition of id. Doing beta-reduction (of type applications) in the matcher could fix this. I’ll attach a test case. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7610: Cross compilation support for LLVM backend
by GHC 13 Apr '13

13 Apr '13

#7610: Cross compilation support for LLVM backend ------------------------------------+--------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Blockedby: Blocking: | Related: 7608 ------------------------------------+--------------------------------------- Top level bug to track supporting cross compilation in LLVM backend. Mostly this shouldn't be too bad but I haven't tried it and know of at least a few significant issues. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7610> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #7608: Triple not passed to LLVM when cross-compiling
by GHC 13 Apr '13

13 Apr '13

#7608: Triple not passed to LLVM when cross-compiling ------------------------------------+--------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.6.1 | Keywords: cross-compiling llvm Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- First found in http://www.haskell.org/pipermail/cvs- ghc/2012-December/079115.html When cross-compiling to a different architecture, LLVM is not informed what architecture we are building for, and so generates code for the host architecture instead. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #7604: System.Directory.canonicalizePath "" behaviour differs between platforms
by GHC 13 Apr '13

13 Apr '13

#7604: System.Directory.canonicalizePath "" behaviour differs between platforms ------------------------------------+--------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: T4113 Blockedby: | Blocking: Related: | ------------------------------------+--------------------------------------- On Linux, `System.Directory.canonicalizePath ""` gives an exception. On OS X, it returns the current directory. In a `System.Directory` function, we should consistently do one or the other. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7596: Opportunity to improve CSE
by GHC 13 Apr '13

13 Apr '13

#7596: Opportunity to improve CSE ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ In `nofib/spectral/mandel2`, the function `check_perim` calls `point_colour` on various arguments. After inlining `point_colour` there is the opportunity to CSE among the sub-expressions the inlinings create. In GHC 7.6, the join point didn't have a "one-shot" flag, so the full laziness pass floated these sub-expressions out, and they got CSEd. As part of Ilya's new demand analyser changes, we get the "one-shot" flag right, so don't MFE those sub-expressions, so they aren't CSEd. As a result, allocation on `mandel2` increases slightly (4.2%). The solution is, I think, to do something a bit like like `CorePrep` before CSE. At the moment if we have {{{ case f (I# y) of { (a,b) -> case g (I# y) of { (p,q) -> ... }} }}} we stuipdly don't CSE that `(I# y)` even though it is manifestly sharable. Somehow we should. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2