August 2015 - ghc-tickets

[GHC] #8364: equip GHC with an accurate internal model of floating point
by GHC 07 Oct '15

07 Oct '15

#8364: equip GHC with an accurate internal model of floating point ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- currently there really isn't a systematic / portable story for doing compile time reduction / evaluation for floating point numbers. there are some folks in the larger haskell community who are working on high precision soft float implementations / modelling. Once that work becomes available, might be worth exploring having something like that for doing controlled high precision evaluation of intermediate expressions in ghc proper. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10687: Clang 3.6 fails with -g due to .file directive order
by GHC 07 Oct '15

07 Oct '15

#10687: Clang 3.6 fails with -g due to .file directive order -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- On Mac Os X, compiling with `-g` will sometimes fail with an error like follows: {{{ /var/folders/yt/bmbchswn57nbmz1l67btd6p00000gn/T/ghc27418_0/ghc_1.s:6573:7: error: error: unassigned file number in '.loc' directive .loc 7 106 17 /* cast */ ^ }}} Which refers to the following code: {{{ [...] .file 7 "libraries/base/Data/Typeable.hs" .file 6 "libraries/ghc-prim/GHC/Classes.hs" [...] .loc 7 106 17 /* cast */ }}} So the file number is clearly assigned, we are just not assigning them "in order". This is okay for most compilers, but Clang 3.6 seems to disagree. The attached patch changes the code so `.file` directives are always generated in order. Could try to produce a testcase if required - it would be rather easy to check that `.file` directives appear in order in a given assembly file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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] #10810: Data constructor operators mis-printed in Template Haskell
by GHC 03 Oct '15

03 Oct '15

#10810: Data constructor operators mis-printed in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-} module Bug where $([d| data Foo = (:!) |]) }}} I get {{{ Bug.hs:6:3-24: Splicing declarations [d| data Foo = :! |] ======> data Foo = :! }}} There are missing parentheses in that output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10810> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4