- ghc-tickets - Haskell.org

[GHC] #12158: ghc: panic! (the 'impossible' happened) translateConPatVec: lookup
by GHC 05 Mar '18

05 Mar '18

#12158: ghc: panic! (the 'impossible' happened) translateConPatVec: lookup -------------------------------------+------------------------------------- Reporter: wozgonon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- *Main> price Stock{name=name,ric=ric,price=price} = price ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-mingw32): translateConPatVec: lookup Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #14888: The (->) type doesn't survive a TH quote-splice roundtrip
by GHC 05 Mar '18

05 Mar '18

#14888: The (->) type doesn't survive a TH quote-splice roundtrip -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- You can roundtrip function types like `Bool -> Bool` through Template Haskell splicing: {{{ $ /opt/ghc/8.2.2/bin/ghci -XTemplateHaskell GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :m + Language.Haskell.TH λ> :k $([t| Bool -> Bool |]) $([t| Bool -> Bool |]) :: * }}} However, GHC doesn't offer the same courtesy to `(->)` applied prefix, as in the following example: {{{ λ> :k $([t| (->) Bool Bool |]) <interactive>:1:3: error: • Illegal type constructor or class name: ‘(->)’ When splicing a TH type: GHC.Prim.(->) GHC.Types.Bool GHC.Types.Bool • In the untyped splice: $([t| (->) Bool Bool |]) }}} One way to fix this would be to consistently desugar `(->)` to `ArrowT` in `DsMeta` (instead of leaving it as `GHC.Prim.(->)`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14888> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14862: Switching to Cabal 2.2 makes ghc unusable
by GHC 05 Mar '18

05 Mar '18

#14862: Switching to Cabal 2.2 makes ghc unusable -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: None | Version: 8.4.1-alpha3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When bumping Cabal to 2.2 as done [https://phabricator.haskell.org/D4453 here], we end up with a stage 1 GHC that seemingly cannot build a non- segfaulting program. For instance, if one builds the following trivial program with a stage 1 built from the ghc-8.4 branch + the patch above... {{{#!hs import System.Exit main = exitSuccess }}} Then... {{{#!sh $ ./foo Segmentation fault }}} So of course, when we proceed and build stage 2, and then build things with stage 2, all the stage2 commands crash. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14862> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13193: Integer (gmp) performance regression?
by GHC 05 Mar '18

05 Mar '18

#13193: Integer (gmp) performance regression? -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For a simple program that uses Integer, but actual data would fit in an Int, ghc-8.0.2 seems to have more runtime overhead than ghc-6.12.3 had: http://www.imn.htwk-leipzig.de/~waldmann/etc/mob/ I am not really sure what to make of it - an answer could be: "if you know that your Integer fits in an Int, then just use Int". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8772: ghci should safe history more often
by GHC 05 Mar '18

05 Mar '18

#8772: ghci should safe history more often ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It is very annoying if `ghci` crashes (due to using a foreign library wrongly, for example), and then the history is lost. It should be simple to save each line to history before it is being executed. Maybe a good task for new contributors? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8772> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12935: Object code produced by GHC is non-deterministic
by GHC 05 Mar '18

05 Mar '18

#12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a continuation of #4012, which made interface files deterministic. Now someone needs to make object code deterministic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #14701: Investigate the performance impact of code alignment
by GHC 03 Mar '18

03 Mar '18

#14701: Investigate the performance impact of code alignment -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Maybe ghc's performance also varies due to reasons like that: https://dendibakh.github.io/blog/2018/01/18/Code_alignment_issues The gist of the article is that tight loops can have significantly different performance depending on whether the location of the assembly instructions themselves cross a cache line. I would not have expected this to make double-digit percentage differences. From `#ghc`: {{{ bgamari: nh2[m], there are nofib tests where this is very likely the cause of a good portion of the variant angerman: nh2[m]: that linked LLVM talk from 2016 makes me not want to have to deal with that... AndreasK: nh2[m]: It's a real issue. But atm I think ghc at least in the native codegen make no real attempt to optimize for this thoughtpolice: GHC does not carry knowledge of alignment or anything, no. I’m not sure how difficult this is to suss out, but at least making sure every branch target does not cross a cache line is probably a good start thoughtpolice: Well, far jump, e.g. a call to a function. not sure how TNTC fits into this story, tbqh }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14796: Pretty-printer bug
by GHC 03 Mar '18

03 Mar '18

#14796: Pretty-printer bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From Ryan's [https://ryanglscott.github.io/2018/02/11/how-to-derive- generic-for-some-gadts/ How to derive Generic for (some) GADTs using QuantifiedConstraints]: {{{#!hs data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a }}} When instantiating types using `-XTypeApplications` something weird happens {{{ $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a Prelude> :t ECC @[] @() @() ECC @[] @() @() :: [()] -> ECC () :: Constraint [] () }}} Doesn't seem to happen in other cases: {{{ Prelude> :t ECC @[] @() @((), ()) ECC @[] @() @((), ()) :: [()] -> ECC (() :: Constraint, () :: Constraint) [] () Prelude> :t ECC @[] @() @(Eq Int) ECC @[] @() @(Eq Int) :: [()] -> ECC (Eq Int) [] () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14874: Trac: TypeError: can't compare datetime.datetime to str
by GHC 03 Mar '18

03 Mar '18

#14874: Trac: TypeError: can't compare datetime.datetime to str -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This problem appears when sorting closed tickets by their "modified" field. [https://ghc.haskell.org/trac/ghc/query?status=closed&col=id&col=changetime&… Example]. The source of the problem appears to be that a few old tickets don't have a "modified" time (changetime). Instead their "changetime" field seems to be set to the empty string. Apparently similar issues have been known to the Trac developers for a while: https://trac.edgewall.org/ticket/12029. ==== How to Reproduce ==== While doing a GET operation on `/query`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {u'col': [u'id', u'changetime'], u'desc': u'1', u'order': u'changetime', u'page': u'2', u'status': u'closed'} }}} User agent: `Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/64.0.3282.167 Chrome/64.0.3282.167 Safari/537.36` ==== System Information ==== ''System information not available'' ==== Enabled Plugins ==== ''Plugin information not available'' ==== Interface Customization ==== ''Interface customization information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 623, in _dispatch_request dispatcher.dispatch(req) File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 239, in dispatch resp = chosen_handler.process_request(req) File "/usr/local/lib/python2.7/dist-packages/trac/ticket/query.py", line 1000, in process_request return self.display_html(req, query) File "/usr/local/lib/python2.7/dist-packages/trac/ticket/query.py", line 1117, in display_html data = query.template_data(context, tickets, orig_list, orig_time, req) File "/usr/local/lib/python2.7/dist-packages/trac/ticket/query.py", line 776, in template_data elif ticket['changetime'] > orig_time: TypeError: can't compare datetime.datetime to str }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14874> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #2269: Word type to Double or Float conversions are slower than Int conversions
by GHC 03 Mar '18

03 Mar '18

#2269: Word type to Double or Float conversions are slower than Int conversions -------------------------------------+------------------------------------- Reporter: dons | Owner: dons@… Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: rules, | performance, double, newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * cc: sjakobi (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2269#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0