August 2014 - ghc-tickets

[GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!)
by GHC 18 Sep '15

18 Sep '15

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) -------------------------------------------+------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- attached is an example where the type checker isn't "computing" in the closed type families, or at least doing a one step reduction. this makes sense, given that type families only compute when instantiated... But if we could partially evaluate closed type families (or at least do a one step reduction), the attached example code would type check! interestingly, depending on what order the cases for the PSum are written, the type error changes! I guess I want an "eager matching" closed type family, that when partially instantiated will patch on the first pattern it satisfies, to complement ordered type families. attached is a toy example where I otherwise need an unsafeCoerce to make things type check -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9516: unsafeUnmask unmasks even inside uninterruptibleMask
by GHC 18 Sep '15

18 Sep '15

#9516: unsafeUnmask unmasks even inside uninterruptibleMask -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Control.Exception exports {{{#!hs allowInterrupt :: IO () allowInterrupt = unsafeUnmask $ return () }}} with documentation: ''When invoked inside `mask`, this function allows a blocked asynchronous exception to be raised, if one exists. It is equivalent to performing an interruptible operation, but does not involve any actual blocking. When called outside `mask`, or inside `uninterruptibleMask`, this function has no effect.'' However, this is not actually true: `unsafeUnmask` unmasks exceptions even inside `uninterruptibleUnmask`, as the attached test demonstrates (the test uses a foreign call just to have something non-interruptible but still observable; in particular, doing a `print` ''is'' interruptible because it uses an `MVar` under the hood). I think it is possible to define a better `unsafeUnmask` in user-land: {{{#!hs interruptible :: IO a -> IO a interruptible act = do st <- getMaskingState case st of Unmasked -> act MaskedInterruptible -> unsafeUnmask act MaskedUninterruptible -> act }}} but it still seems to be that we should either (i) change the behaviour of unsafeUnmask, or (ii) provide a version of `unsafeUnmask` with the behaviour as described and then change `allowInterrupt` to use that new version of `unsafeUnmask`, or at the very least (iii) change the documentation. (One question with the above definition of `interruptible` is what happens when we ''nest'' `mask` and `uninterruptibleMask`?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8707: Kind inference fails in data instance definition
by GHC 18 Sep '15

18 Sep '15

#8707: Kind inference fails in data instance definition ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Consider the following shenanigans: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, GADTs #-} data family SingDF (a :: (k, k2 -> *)) data Ctor :: k -> * data instance SingDF (a :: (Bool, Bool -> *)) where SFalse :: SingDF '(False, Ctor) }}} HEAD reports (with `-fprint-explicit-kinds`) {{{ Data constructor ‛SFalse’ returns type ‛SingDF Bool k '('False, Ctor k)’ instead of an instance of its parent type ‛SingDF Bool Bool a’ In the definition of data constructor ‛SFalse’ In the data instance declaration for ‛SingDF’ }}} I see two problems here: 1) Kind inference should fix the problem. If I add a kind annotation to `Ctor`, the code works. GHC should be able to infer this kind annotation for me. 2) The error message is not particularly helpful. GHC 7.6.3 had a more verbose, but more helpful message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9235: Simplifier ticks exhausted on recursive class method
by GHC 16 Sep '15

16 Sep '15

#9235: Simplifier ticks exhausted on recursive class method -----------------------------------+--------------------------------------- Reporter: klao | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- GHC 7.8 and HEAD panic on the following code: {{{#!haskell module C where class C a where c :: C a => a -> Int c a = c a {-# INLINE c #-} instance C () x :: Int x = c () }}} Note that it's the coincidence of the 3 conditions that triggers this bug: 1. the `c` method has to be inlined (explicity or implicitly) 2. it has to be recursive (but, it doesn't have to be as dumbly recursive as in the example) 3. it has to have this weird, slightly mistaken type signature: `C a => a -> Int` instead of simply `a -> Int`. But, when this incidentally happens (in my case, both 2. ''and'' 3. were unintentional), the user gets a very hard to debug issue. They don't even get an indication which module is responsible if `c` is used from a different module than the one with the class definition. Also note that this happens even with a non-optimized build. And in this example `c` has to be explicitly marked NOINLINE to prevent it. (In the instance that I caught in the wild simply removing the INLINE annotation was enough.) Finally, on a side note: shouldn't 3. by itself be an error? Or a warning at least? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone"
by GHC 16 Sep '15

16 Sep '15

#8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone" -------------------------------------+------------------------------------- Reporter: sp55aa | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Simplifier, | Operating System: Windows UnfoldingDone, simpl-tick-factor | Type of failure: GHC rejects Architecture: x86 | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- ghc fail to compile this file: ---- begin Y.hs ---- newtype Rec a = Rec { unRec :: Rec a -> a } y :: (a -> a) -> a y = \f -> (\x -> f (unRec x x)) (Rec (\x -> f (unRec x x))) foo :: (a -> a) -> a -> a foo f n = f n main = print $ y foo 4 ---- end Y.hs ---- C:\Users\user\Desktop>ghc Y.lhs [1 of 1] Compiling Main ( Y.lhs, Y.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone a_sqe{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 5601 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8689: confusing comment in compiler/main/SysTools.lhs
by GHC 16 Sep '15

16 Sep '15

#8689: confusing comment in compiler/main/SysTools.lhs ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- on line 341 {{{ -- Hans: this isn't right in general, but you can -- elaborate it in the same way as the others }}} I have NO idea what that comment is referring to -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8552: Rename StgArrWords to StgArrBytes
by GHC 15 Sep '15

15 Sep '15

#8552: Rename StgArrWords to StgArrBytes ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Since #3800, `StgArrWords` contains a certain number of words and not bytes. One can easily forget this and make programming mistakes. For example if you try to store the number of words in the `bytes` field, the garbage collector won't honor your decision. (I learned the hard way :)) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9087: Executables in the 7.8.2 Linux i386 binary tarball are not stripped
by GHC 07 Sep '15

07 Sep '15

#9087: Executables in the 7.8.2 Linux i386 binary tarball are not stripped ----------------------------+-------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+-------------------------- At least on i386 Linux, the executables inside the GHC binary tarball seem to come with debug information. Stripping it noticeably reduces the binary sizes: {{{ $ file /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x6012a4c86cd3f410ca0e59ab4ac872ce740d03c6, not stripped $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc 1,4M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc 1021K /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock 3,2M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock 2,3M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock }}} Do we really need to include the debug info for exes? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9500: Allow GHC defaults to be modified with an environment variable
by GHC 07 Sep '15

07 Sep '15

#9500: Allow GHC defaults to be modified with an environment variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 wanted to do this to turn -fsimple-list-literals on and off for NoFib without editing a million makefiles or recompiling GHC, but I bet there are other reasons. GHC's validate should probably prompt the user to verify they want to continue of the variable is set, and should issue a loud warning at the very end indicating what options were set by the variable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9500> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)"
by GHC 06 Sep '15

06 Sep '15

#8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" ----------------------------+--------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- I have a program (git-annex) which builds successfully on windows, but when I enable any of three optional features which pull in some additional libraries, it fails to link. I will attach the output of cabal build --ghc-options=-v for a failing and a successful build. I hypothesize this is due to a command line length limit. The final failing gcc link command is 43814 characters, vs 30765 in the configuration that succeeds. Right around the 32k boundry. Not sure what I can do to work around this, short of splitting up my program into standalone libraries which will link without referencing every individual module? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12