- ghc-tickets - Haskell.org

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Aug '13

16 Aug '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ----------------------------------------------+---------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): There was some follow-up email on ghc-devs about this. (But let's accumulate comments here.) My summary * If we have `EmptyDataDecls` then surely {{{ data T deriving( Eq ) }}} should work, just as well as standalone deriving {{{ data T deriving Eq T }}} The two must behave the same. * Surely all the built-in classes (Eq, Show, Ord etc) should derive for with `EmptyDataDecls` too. * Haskell 2010 doesn't have `EmptyDataDecls` (eg the [http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2 data type chapter] specifies n>0 constructors). But oddly the [http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-182000… deriving appendix] clause 6 says that nothing is derived if there are no constructors. I think we should just ignore clause 6, since H2010 doesn't have empty data types. * It would be better if the `error "Void Eq"` mentioned the data type. More like `error "Eq on empty data type T"`. Might you do those things, Omer? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Aug '13

16 Aug '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ----------------------------------------------+---------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Omer writes: I just started GHC development made a commit for ticket 7401: http://ghc.haskell.org/trac/ghc/ticket/7401 My patch is here: https://github.com/osa1/ghc/commit/3ec257ff48372de30df59cd8854ce28954c9db95 `make test` succeeds. My test case for this patch is something like this: {{{ data D deriving Eq main :: IO () main = print ((undefined :: D) == (undefined :: D)) }}} example: {{{ haskell$ ./ghc/inplace/bin/ghc-stage2 --interactive derive.hs GHCi, version 7.7.20130806: 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 Main ( derive.hs, interpreted ) Ok, modules loaded: Main. ghci> main True it :: () }}} This behavior (returning True) is consistent with standalone deriving version: {{{ haskell$ cat derive_standalone.hs {-# LANGUAGE StandaloneDeriving #-} data D deriving instance Eq D main :: IO () main = print ((undefined :: D) == (undefined :: D)) haskell$ ./ghc/inplace/bin/ghc-stage2 --interactive derive_standalone.hs GHCi, version 7.7.20130806: 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 Main ( derive_standalone.hs, interpreted ) Ok, modules loaded: Main. ghci> main True it :: () ghci> Leaving GHCi. }}} However, if you want (==) implementation in this case to be `error "Void (==)"`, I think I can also do that by first fixing the code generated by `StandaloneDeriving` extension and then fixing my current patch. Any comments and reviews would be appreciated! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8135: Panic when printing out kind incompatibility error
by GHC 15 Aug '13

15 Aug '13

#8135: Panic when printing out kind incompatibility error ------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I wrote a little utility function against the new pipes 4.0 repository but neglected to put the brackets around lift (f x) like so: mapM :: (Monad m) => (a -> m b) -> Pipe a b m r mapM f = for cat $ \x -> do r <- lift f x yield r Which resulted in this error/panic. src/Utils/Pipes.hs:13:8: Couldn't match kind `* -> *' with `*' Expected type: a -> Proxy () a () b m b Actual type: a -> Proxy () a () b m b Kind incompatibility when matching types: a :: * -> * a :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7978: Profiling broken
by GHC 15 Aug '13

15 Aug '13

#7978: Profiling broken --------------------------------------------+------------------------------ Reporter: gmainland | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): We should add a test, yes, but it's slightly tricky - we have to devise some code that will convince the compiler to generate a non-updatable selector thunk. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7978#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8103: Segfault when passing unboxed Float# and Double# across modules
by GHC 15 Aug '13

15 Aug '13

#8103: Segfault when passing unboxed Float# and Double# across modules -----------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: 6135 Related Tickets: | -----------------------------+---------------------------------- Consider this program consisting of two modules: {{{ {-# LANGUAGE MagicHash #-} module AddWraps where import GHC.Exts {-# NOINLINE foo #-} foo :: Double# -> Double# -> Double# foo a b = (a +## b) }}} {{{ {-# LANGUAGE MagicHash #-} module Main where import AddWraps float_text = case (0.0## `foo` 1.2##) of 0.0## -> "1" _ -> "0" main = putStrLn (float_text) }}} This program segfaults when compiled on i386 with HEAD: {{{ [t-jastol@cam-05-unx : ~] $HOME/master-i386/bin/ghc -fforce-recomp add- double-extern.hs [1 of 2] Compiling AddWraps ( AddWraps.hs, AddWraps.o ) [2 of 2] Compiling Main ( add-double-extern.hs, add-double- extern.o ) Linking add-double-extern ... [t-jastol@cam-05-unx : ~] ./add-double-extern Segmentation fault (core dumped) }}} The problem does not occur: * on x86_64 * on 7.6.3 * when optimizations are turned on * fot `Int#`, `Word#` and `Char#` - only `Float#` and `Double#` are affected Segfault happens on line 223 of `rts/ThreadPaused.c` (`switch (info->i.type)`), which probably means that the stack gets corrupted. It turns out that Cmm generated for the `foo` is the same in both cases: {{{ [section "data" { AddWraps.foo_closure: const AddWraps.foo_info; }, AddWraps.foo_slow() // [R1] { info_tbl: [] stack_info: arg_space: 20 updfr_space: Just 4 } {offset cfx: _rf9::P32 = R1; _B2::F64 = F64[Sp]; _B1::F64 = F64[Sp + 8]; D2 = _B1::F64; D1 = _B2::F64; R1 = _rf9::P32; Sp = Sp + 16; call AddWraps.foo_info(D2, D1, R1) args: 4, res: 0, upd: 4; } }, AddWraps.foo_entry() // [D2, D1] { info_tbl: [(cfB, label: AddWraps.foo_info rep:HeapRep static { Fun {arity: 2 fun_type: ArgGen [True, True, True, True]} })] stack_info: arg_space: 4 updfr_space: Just 4 } {offset cfB: _B1::F64 = D2; _B2::F64 = D1; goto cfD; cfD: _cfA::F64 = %MO_F_Add_W64(_B2::F64, _B1::F64); D1 = _cfA::F64; call (P32[Sp])(D1) args: 4, res: 0, upd: 4; } }] }}} The difference lies in how the calls are generated. When `foo` is in the same module as caller the generated call looks like this: {{{ cjY: I32[Sp - 8] = stg_bh_upd_frame_info; P32[Sp - 4] = Hp - 4; I32[Sp - 12] = ck0; D2 = 1.2 :: W64; D1 = 0.0 :: W64; Sp = Sp - 12; call Main.foo_info(D2, D1) returns to ck0, args: 4, res: 4, upd: 12; ck0: _sjs::F64 = D1; Hp = Hp + 12; if (Hp > HpLim) goto ckf; else goto ckc; }}} Whereas placing `foo` in separate module leads to this code: {{{ ck5: I32[Sp - 8] = stg_bh_upd_frame_info; P32[Sp - 4] = Hp - 4; I32[Sp - 12] = ck7; D1 = 0.0 :: W64; R1 = AddWraps.foo_closure; I32[Sp - 24] = stg_ap_d_info; F64[Sp - 20] = 1.0 :: W64; Sp = Sp - 24; call stg_ap_d_fast(D1, R1) returns to ck7, args: 16, res: 4, upd: 12; ck7: _sjP::F64 = D1; Hp = Hp + 12; if (Hp > HpLim) goto ckm; else goto ckj; }}} The second version causes a segfault. This currently blocks merging of #6135 patches. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8103> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #7116: Missing optimisation: strength reduction of floating-point multiplication
by GHC 15 Aug '13

15 Aug '13

#7116: Missing optimisation: strength reduction of floating-point multiplication -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Jan Stolarek Type: bug | <jan.stolarek@…> Priority: normal | Status: closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: 7.4.2 Operating System: Unknown/Multiple | Keywords: Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: numeric/should_compile/T7116 | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => numeric/should_compile/T7116 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7116#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7953: Segfault on x86 with -O2
by GHC 15 Aug '13

15 Aug '13

#7953: Segfault on x86 with -O2 ---------------------------------------------+---------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: codeGen/should_run/T7953 | Blocked By: Blocking: | Related Tickets: ---------------------------------------------+---------------------------- Changes (by thoughtpolice): * testcase: => codeGen/should_run/T7953 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7953#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7953: Segfault on x86 with -O2
by GHC 15 Aug '13

15 Aug '13

#7953: Segfault on x86 with -O2 -------------------------------------+---------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------- Comment (by Austin Seipp <aseipp@…>): In [changeset:e144ec8c37ba91c6bccedab31e7fa538691ec2db/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="e144ec8c37ba91c6bccedab31e7fa538691ec2db" Add a regression test (see #7953) Signed-off-by: Austin Seipp <aseipp(a)pobox.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7953#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7978: Profiling broken
by GHC 15 Aug '13

15 Aug '13

#7978: Profiling broken --------------------------------------------+------------------------------ Reporter: gmainland | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Very glad this is fixed. Could someone add a regression test, please? Thanks Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7978#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7574: Register allocator chokes on certain branches with literals
by GHC 15 Aug '13

15 Aug '13

#7574: Register allocator chokes on certain branches with literals -------------------------------------------------+------------------------- Reporter: thoughtpolice | Owner: Type: bug | thoughtpolice Priority: highest | Status: new Component: Compiler (NCG) | Milestone: 7.8.1 Resolution: | Version: 7.7 Operating System: Unknown/Multiple | Keywords: ncg, Type of failure: Compile-time crash | codegen Test Case: codeGen/should_compile/T7574 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: 7573 | Related Tickets: | #7571,#7534 -------------------------------------------------+------------------------- Changes (by simonpj): * testcase: => codeGen/should_compile/T7574 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7574#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0