November 2017 - ghc-tickets

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 02 Nov '17

02 Nov '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, the rest is pretty clear I think: Note that in the RHS of the simplified `newTyConInstRhs` the ticks should wrap the two arguments `ww1_suMl` and `ww2_suMm` but don't. `CoreUtils.mkTick` has the following case for ticks wrapping `Var`s, {{{#!hs mkTick' top rest expr = case expr of ... Var x | notFunction && tickishPlace t == PlaceCostCentre -> orig_expr | notFunction && canSplit -> top $ Tick (mkNoScope t) $ rest expr where -- SCCs can be eliminated on variables provided the variable -- is not a function. In these cases the SCC makes no difference: -- the cost of evaluating the variable will be attributed to its -- definition site. When the variable refers to a function, however, -- an SCC annotation on the variable affects the cost-centre stack -- when the function is called, so we must retain those. notFunction = not (isFunTy (idType x)) }}} Moreover, `CoreSyn.tickishPlace` is defined thusly, {{{#!hs tickishPlace :: Tickish id -> TickishPlacement tickishPlace n@ProfNote{} | profNoteCount n = PlaceRuntime | otherwise = PlaceCostCentre ... }}} This is how the counting and non-counting cases are treated differently. So in short, in the non-counting case we try to wrap a `Var` expression in a tick. `mkTick` then notices that such a tick can be dropped and does so. However, the tick remains in the unfolding. Consequently, when we inline `newTyConInstRhs` in another module we end up with a reference to a cost center whose corresponding symbol doesn't exist in the module that is supposed to define it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 02 Nov '17

02 Nov '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, I know what is going on here: Look at the simplified Core of `Type.newTyConInstRhs`, {{{ newTyConInstRhs :: TyCon -> [Type] -> Type [GblId, Arity=2, Str=<S,1*U><S,U>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) Tmpl= \ (tycon_a9Sq [Occ=OnceL] :: TyCon) (tys_a9Sr [Occ=OnceL] :: [Type]) -> scc<newTyConInstRhs> let { ds_sofN :: ([TyVar], Type) [LclId] ds_sofN = scc<newTyConInstRhs.(...)> newTyConEtadRhs tycon_a9Sq } in applyTysX (scc<newTyConInstRhs.tvs> case ds_sofN of { (tvs_ab8F [Occ=Once], _ [Occ=Dead]) -> tvs_ab8F }) (scc<newTyConInstRhs.rhs> case ds_sofN of { (_ [Occ=Dead], rhs_ab8H [Occ=Once]) -> rhs_ab8H }) tys_a9Sr}] newTyConInstRhs = \ (tycon_a9Sq :: TyCon) (tys_a9Sr :: [Type]) -> scc<newTyConInstRhs> case scc<newTyConInstRhs.(...)> newTyConEtadRhs tycon_a9Sq of { (ww1_suMl, ww2_suMm) -> applyTysX ww1_suMl ww2_suMm tys_a9Sr } }}} Note how the unfolding contains references to two SCCs, `newTyConInstRhs.tvs` and `newTyConInstRhs.rhs`, which do not appear in the RHS. Indeed these were both present in the original desugared Core, so it seems like the simplifier eliminated them. I'm not yet sure why it does this, nor do I know why this is only triggered with `-fno-prof-count- entries`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le
by GHC 02 Nov '17

02 Nov '17

#12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le ---------------------------------+------------------------------------- Reporter: michelmno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+------------------------------------- as detailed in attached log below the initial failure is a reported Segmentation Fault and if adding debuginfo rpms then reported failure is a ghc: panic for mkFastStringWith -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

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

02 Nov '17

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"1317ba625d40fbd51cb0538b3fde28f412f30c01/ghc" 1317ba62/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1317ba625d40fbd51cb0538b3fde28f412f30c01" Implement the EmptyDataDeriving proposal This implements the `EmptyDataDeriving` proposal put forth in https://github.com/ghc-proposals/ghc- proposals/blob/dbf51608/proposals/0006-deriving-empty.rst. This has two major changes: * The introduction of an `EmptyDataDeriving` extension, which permits directly deriving `Eq`, `Ord`, `Read`, and `Show` instances for empty data types. * An overhaul in the code that is emitted in derived instances for empty data types. To see an overview of the changes brought forth, refer to the changes to the 8.4.1 release notes. Test Plan: ./validate Reviewers: bgamari, dfeuer, austin, hvr, goldfire Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #7401, #10577, #13117 Differential Revision: https://phabricator.haskell.org/D4047 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13117: Derived functor instance for void types handles errors badly
by GHC 02 Nov '17

02 Nov '17

#13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- If we have {{{#!hs data V a deriving (Functor) }}} and we evaluate {{{#!hs f <$> (error "Boo!" :: Void) }}} we should really get a "Boo" error, rather than a useless "Void fmap" one. The offending code is in `compiler/typecheck/TcGenFunctor.hs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 02 Nov '17

02 Nov '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 02 Nov '17

02 Nov '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I can reproduce this exact behavior. Investigating. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8171: Extending ExtendedDefaultRules
by GHC 02 Nov '17

02 Nov '17

#8171: Extending ExtendedDefaultRules ------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | 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: | ------------------------------------+------------------------------------- The current `ExtendedDefaultRules` is set up in a way that largely prevents it from being used for scenarios beyond what they get used for in GHCi today. It would be great if there was an extra class that could be included in the list of acceptable classes for Rule 3. {{{ class Defaulting a }}} The proposed change would be that Rule 3 under EDR can be be relaxed to: At least one of the classes Ci is numeric, or is `Show`, `Eq`, `Ord` or `Defaulting`. I went with `Defaulting` rather than `Default`, because `Default` is a common class in use across the ecosystem from the `data-default` package, and I wanted to avoid gratuitous fallout. This would permit projects like Shae Erisson's `ghclive` from last year that need to use defaulting to not have to shoe-horn unnecessary `Show` constraints onto functions. Even better would be for that class to be polykinded! That opens up possibilities for expert users to get defaulting to fire on arguments of other kinds, which is impossible under the current EDR. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14347: Top-level RecordWildCards no longer working.
by GHC 02 Nov '17

02 Nov '17

#14347: Top-level RecordWildCards no longer working. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- {{{#!hs $ ghc -fforce-recomp /tmp/Damn.hs /tmp/T.hs [1 of 2] Compiling Damn ( /tmp/Damn.hs, /tmp/Damn.o ) [2 of 2] Compiling T ( /tmp/T.hs, /tmp/T.o ) /tmp/T.hs:7:5: warning: [-Wmissing-fields] • Fields of ‘D.D’ not initialised: x, y • In the expression: D.D {..} In an equation for ‘d’: d = D.D {..} | 7 | d = D.D {..} | ^^^^^^^^ $ cat /tmp/Damn.hs /tmp/T.hs module Damn (D(..)) where data D = D { x :: Int, y :: () } {-# LANGUAGE RecordWildCards #-} module T where import qualified Damn as D d :: D.D d = D.D {..} x :: Int x = 7 y :: () y = () $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 }}} Meanwhile on 8.0 {{{#!hs $ ghc -Wall -fforce-recomp /tmp/Damn.hs /tmp/T.hs [1 of 2] Compiling Damn ( /tmp/Damn.hs, /tmp/Damn.o ) [2 of 2] Compiling T ( /tmp/T.hs, /tmp/T.o ) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9249: Link to "latest" user's guide
by GHC 01 Nov '17

01 Nov '17

#9249: Link to "latest" user's guide ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I search (say, on Google) for a GHC-related bit of documentation, I variously get referred to old manuals. There doesn't seem to a good way for us, the GHC devs, to avoid this. But, perhaps we can include some information in the header of the pages to allow visitors to link to the latest manual, or perhaps to several versions. This header should also include the version number of the GHC that the page is documenting; currently, this info is only in the URL. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4