June 2015 - ghc-tickets

[GHC] #8335: Create more specialized entries to GC
by GHC 06 Oct '15

06 Oct '15

#8335: Create more specialized entries to GC ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | 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 this Cmm code (taken from #8326): {{{ {offset cFd: // stack check if ((Sp + -16) < SpLim) goto cFr; else goto cFs; cFr: // not enough place on the stack, call GC R2 = R2; R1 = A.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; cFs: // scrutinize (x ># 0#) _sEU::I64 = R2; _sEV::I64 = %MO_S_Gt_W64(R2, 0); if (_sEV::I64 != 1) goto cFg; else goto cFo; cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cFo: // True branch Hp = Hp + 16; if (Hp > HpLim) goto cFv; else goto cFu; cFv: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFn; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8; cFn: // re-do the True branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFo; cFu: // RHS of True branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = _sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }}} We perform two different calls to garbage collection here. Calling GC after making initial stack check obviously can't use any stack, so we pass parameter to GC in regsiters: {{{ R2 = R2; R1 = A.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; }}} But in the calls that are made later on inside the function we do put some parameters on the stack, thus increasing stack usage: {{{ cFv: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFn; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8; }}} If we had more specialized entries to GC that would allow us to pass parameters in registers (or in some fixed memory location associated with TCO?) then this function would not require any stack at all. Note that there is a separate issue here - `_sEV` variable is in fact dead and should be eliminated (see #8327). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10516: PolyKinds results in incorrect reporting of type synonym parameter count
by GHC 06 Oct '15

06 Oct '15

#10516: PolyKinds results in incorrect reporting of type synonym parameter count -------------------------------------+------------------------------------- Reporter: | Owner: benjamin.hodgson | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: None/Unknown Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program is invalid because the declaration of `f` doesn't fully apply `App` to all of its arguments. {{{#!hs {-# LANGUAGE PolyKinds #-} type App f a = f a newtype X f a = X (f a) f :: f a -> X (App f) a f = X }}} However, with the `PolyKinds` extension, the error reporting is quite weird: {{{ Type synonym ‘App’ should have 4 arguments, but has been given 3 In the type signature for ‘f’: f :: f a -> X (App f) a }}} `App` has ''two'' arguments, and I gave it ''one''! I'm guessing that `PolyKinds` makes GHC supply some implicit parameters during expansion of type synonyms, and that's what gets reported in the error message. The behaviour is correct without `PolyKinds`. I've tested this on GHC 7.8.3 (the Haskell Platform version). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8920: Alternative GADT syntax
by GHC 05 Oct '15

05 Oct '15

#8920: Alternative GADT syntax ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Parser) | Version: Keywords: gadts | 7.8.1-rc2 Architecture: Unknown/Multiple | Operating System: Difficulty: Moderate (less than a day) | Unknown/Multiple Blocked By: | Type of failure: Other Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- An alternative syntax for GADTs Instead of {{{ data Term x where K :: Term (a -> b -> a) S :: Term ((a -> b -> c) -> (a -> b) -> a -> c) Const :: a -> Term a (:@) :: Term (a -> b) -> (Term a) -> Term b }}} You can write {{{ data Term x = K :: Term (a -> b -> a) | S :: Term ((a -> b -> c) -> (a -> b) -> a -> c) | Const a :: Term a | (:@) (Term (a -> b)) (Term a) :: Term b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10071: Implement warnings for class-method overriding
by GHC 04 Oct '15

04 Oct '15

#10071: Implement warnings for class-method overriding -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: AMP | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #8004, #4384 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This would aid long-term transitions like phasing out `Monad(return)` (in the spirit of #4834): With the AMP, `Monad(return)` being a class method becomes an historic artifact. The ideal long-term situation would rather be to have `return` become a top-level definition (i.e. outside the `Monad`-class), generalised to `Applicative` just aliasing `Applicative(pure)`, i.e. {{{#!hs return :: Applicative f => a -> f a return = pure }}} This may be beneficial for things like ApplicativeDo which otherwise would require a `return` to be handled is if it was `pure` in order to weaken the type-constraint in an `do`-expression like e.g. {{{#!hs do { x <- f; return (fst x) } }}} Right now, we can attach a `DEPRECATE`-pragma to the `return`-class- method. That however would trigger warnings on ''all'' uses of `return`, rather than only when using `return` in a context that requires it to be a class-method (like overriding `return` in instance definitions, or importing/exporting it via the explicit `Monad(return)`-syntax) Instead we need a way to warn about such uses of `return` which assume it to be a class-method, in order to phase out such uses. NB: This will probably require additional discussions, but we shouldn't wait too long, if we want to integrate the AMP into a future Haskell Report (for which we should try to clean up historic warts such as `Monad(return)` if feasable). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10071> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows
by GHC 03 Oct '15

03 Oct '15

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows ----------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- I work on a Haskell library interfacing with foreign C++ library. While trying to use it in GHCi on Windows 8.1 64bit, I encountered an error message that said: {{{ <loading other libraries> Loading package library-0.1.0.0 ... <interactive>: Unknown PEi386 section name ` .text$_ZNSt6vectorIcSaIcEED1Ev' (while processing: c:\path\to\file.o) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-mingw32): loadObj "C:\\path\\to\\file.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've prepared a minimal example triggering this bug and attached it to this bug report. On Linux (Arch 64bit), after cabal build and cabal repl it behaves as intended: {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) dist/build/cbits/ex.o ... done final link ... done [1 of 1] Compiling Example ( Example.hs, interpreted ) Ok, modules loaded: Example. λ: foo Test }}} However, on Windows 8.1 it crashes while loading object file: {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) dist\build\cbits\ex.o ... ghc.exe: Unknown PEi386 sectio n name `.text$printf' (while processing: dist\build\cbits\ex.o) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-mingw32): loadObj "dist\\build\\cbits\\ex.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Crashing in GHCi means that I cannot use it with programs that contain TH splices, what is important for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom
by GHC 03 Oct '15

03 Oct '15

#10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom -----------------------------------------+--------------------------------- Reporter: tejon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- {{{ [ 4 of 11] Compiling Reflex.Dom.Internal ( src\Reflex\Dom\Internal.hs, dist\build\Reflex\Dom\Internal.o ) ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 00000000184b3978 (GHC version 7.10.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This happens with unmodified reflex-dom.cabal (which specifies -funbox- strict-fields and -O2) and also with all ghc-options: flags removed and -O or -O0. When compiling with the bundled mingw it also pops up a GUI error window: {{{ ghc.exe - Entry Point Not Found The procedure entry point pthread_cond_timedwait_relative_np could not be located in the dynamic link library libwinpthread-1.dll. }}} I also tried using a fully-updated mingw64 from MSYS2, which has solved -pthread issues for me in the past, but that simply crashes with no additional message. Verbose cabal output attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10563> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10342: Convert User Guide from DocBook to AsciiDoc
by GHC 03 Oct '15

03 Oct '15

#10342: Convert User Guide from DocBook to AsciiDoc -------------------------------------+------------------------------------- Reporter: dmbergey | Owner: dmbergey Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See initial proposal and discussion on the mailing list: https://mail.haskell.org/pipermail/ghc-devs/2014-October/006599.html and the more recent call for volunteers: https://ghc.haskell.org/trac/ghc/blog/weekly20150414 Quoting the latter: the idea [is] that it will A) make life easier for people who frequently modify the users guide, and B) make life easier for people who add things irregularly, as a lower barrier to entry. I expect that asciidoc & DocBook can coexist while I work on this. After the initial changes to the build system, the docbook-to-HTML phase should read both the asciidoc-generated XML and the not-yet-converted XML files. This ticket will track progress on the task, as I plan to submit multiple patches, perhaps as many as one per file converted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9238: Negative zero broken
by GHC 03 Oct '15

03 Oct '15

#9238: Negative zero broken --------------------------+------------------------------------------------ Reporter: | Owner: augustss | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Operating System: Windows Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Try the following program {{{ compareDouble :: Double -> Double -> Ordering compareDouble x y = case (isNaN x, isNaN y) of (True, True) -> EQ (True, False) -> LT (False, True) -> GT (False, False) -> -- Make -0 less than 0 case (x == 0, y == 0, isNegativeZero x, isNegativeZero y) of (True, True, True, False) -> LT (True, True, False, True) -> GT _ -> x `compare` y main = do let l = [-0, 0] print [ (x, y, compareDouble x y) | x <- l, y <- l ] }}} Compile and run with -O0 {{{ $ ghc -O0 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,EQ),(-0.0,0.0,LT),(0.0,-0.0,GT),(0.0,0.0,EQ)] }}} This is the correct output. Compile and run with -O1 {{{ $ ghc -O1 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,LT),(-0.0,0.0,LT),(0.0,-0.0,EQ),(0.0,0.0,EQ)] }}} This is wrong. Put a NOINLINE pragma on compareDouble: {{{ $ ghc -O1 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,EQ),(-0.0,0.0,EQ),(0.0,-0.0,EQ),(0.0,0.0,EQ)] }}} This is wrong in a different way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10475: detabify User's Guide
by GHC 02 Oct '15

02 Oct '15

#10475: detabify User's Guide -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | Status: new Priority: low | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The User's Guide .xml files use a fairly random-looking mix of tabs and spaces for indentation. Let's get rid of the tabs and then enforce their absence with git hooks. Why do this? See #10425; apparently tabs within programlisting elements are rendered as some number of spaces other than 8 in the PDF version (only!) I briefly tried to find other instances of the same issue, but there are thousands of tab characters in the User's Guide and I'm too lazy to try to find only the ones within programlisting elements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10215: Optimizer has bugs regarding handling of -0.0
by GHC 02 Oct '15

02 Oct '15

#10215: Optimizer has bugs regarding handling of -0.0 -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #9238 Differential Revisions: | -------------------------------------+------------------------------------- This is most likely related to https://ghc.haskell.org/trac/ghc/ticket/9238 Perhaps it can be merged into that if it is indeed the case, though it'd be good for an expert to take a look and make sure first that the culprit is indeed the same. In any case, the program in this ticket can at least serve as a test-case. I observed this on 7.8.3; though I suspect the same holds in the just released 7.10.1 as well. For the following program: {{{#!hs testF :: Float -> Bool testF x = x == 0 && not (isNegativeZero x) testD :: Double -> Bool testD x = x == 0 && not (isNegativeZero x) main :: IO () main = do print $ testF (-0.0) print $ testD (-0.0) }}} If I compile with no optimizations, then I get the correct answers: {{{ $ /bin/rm -f a.hi a.o a; ghc -O0 a; ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... False False }}} But if I turn optimizations on, then I get: {{{ $ /bin/rm -f a.hi a.o a; ghc -O2 a; ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... True True }}} which is just plain wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2