- ghc-tickets - Haskell.org

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 18 Oct '18

18 Oct '18

#7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Examples using `map` are important, but they also need to be taken with a grain of salt. List fusion will tear those things apart and put them together again and that can eliminate some problems we want to look at. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 18 Oct '18

18 Oct '18

#7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by chessai): It also produces the same core with -O1. With -O0, i see the problem, but i would expect that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 18 Oct '18

18 Oct '18

#7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by chessai): I'm using ghc 8.4.3, and compiling your example exactly with -O2 produces no difference whether i compile with '-fpedantic-bottoms' or '-fno- pedantic-bottoms' produce the same core. {{{ module Foo (foo) where (#) :: (b -> c) -> (a -> b) -> a -> c (#) f g = f `seq` g `seq` \x -> f (g x) foo :: (a -> b) -> [a] -> [b] foo f = map (id # f) }}} the core shows `foo = map`. This is in contrast to @nomeata's comment from 5 years ago, where compilation with -fpedantic-bottoms is necessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'
by GHC 18 Oct '18

18 Oct '18

#15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 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: -------------------------------------+------------------------------------- {{{ % cat Nopie.hs module Nopie where main :: IO () main = putStrLn "hi" % ghc -fforce-recomp -c -fhpc Nopie.hs clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] }}} This happens for every source file when -fhpc is given, but also happens on links even when -fhpc isn't given. With -v, I see a call to gcc with -no-pie. When I run the same compile with ghc 8.4.1, I see the same call to gcc, only without that -no-pie flag, so this is new. It seems to be a harmless warning, but really clutters up the output. Incidentally, it looks like the particular spelling of -no-pie was added to LLVM a year ago due to ghc: https://reviews.llvm.org/D35462 Not sure if that's relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15773: User Guide contains erroneous information about `-rtsopts` modes.
by GHC 18 Oct '18

18 Oct '18

#15773: User Guide contains erroneous information about `-rtsopts` modes. -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Keywords: User Guide | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the user guide section on [https://downloads.haskell.org/%7Eghc/latest/docs/html/users_guide/phases.ht… #ghc-flag--rtsopts[=%E2%9F%A8none|some|all|ignore|ignoreAll%E2%9F%A9 `-rtsopts`] specifies that `-rtsopts=some` is the default setting in the text under it, while the specified default is `all`. Happy to submit a patch if someone can confirm that `all` is actually the default, and that I'm not misunderstanding the meaning here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15771: Could there be further refactoring to the `seq` typing rule
by GHC 18 Oct '18

18 Oct '18

#15771: Could there be further refactoring to the `seq` typing rule -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Seq has a special cased typing rule. It's been greatly simplified in aab3c6d18416b3bc8e1378dfc4d485a9307ca5c7 . But there is still duplication, with a different rule applying when `seq` is used in infix position (unchanged in that commit), and when used in prefix position. Could there be a way to reduce code duplication here? I find it really hard to convince myself that both cases do the same thing. Though, really, given levity polymorphism, does `seq` need a special typing rule at all anymore? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15680: Flag for printing absolute paths in diagnostics
by GHC 18 Oct '18

18 Oct '18

#15680: Flag for printing absolute paths in diagnostics -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Currently, GHC will produce errors and warnings with relative paths pointing to the input that caused it. This is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in different working directories and interleave the output from multiple GHC invocations. In particular, this makes using `next-error` in emacs a lot less useful than it could be with cabal-install's output. [https://github.com/commercialhaskell/stack/blob/0740444175f41e6ea5ed236cd2c… Stack has some rather hackish code to post-process the diagnostics and to turn the relative paths absolute.] I can personally report that this makes the development process a lot more pleasant! I think it'd be much cleaner to have a GHC flag for this at the source. `-fabsolute-diagnostic-paths` or something similar, subject to bikeshedding. I had a look at implementing this myself, and `mkLocMessageAnn` in `ErrUtils` would be the locus of the change. However, I can't figure out how that function should learn what the current working directory is! Any tips? Is that information lurking somewhere in `DynFlags`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15766: GeneralizedNewtypeDeriving should support classes with ambiguous types
by GHC 17 Oct '18

17 Oct '18

#15766: GeneralizedNewtypeDeriving should support classes with ambiguous types -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The following module has a class with an ambiguous type: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Ambig where class C a where c :: Int data A = A instance C A where c = 5 newtype B = B A deriving C }}} Thanks to TypeApplications, this typeclass is still usable. However, GeneralizedNewtypeDeriving fails on it: {{{ Ambig.hs:12:26: error: • Ambiguous type variable ‘a0’ arising from a use of ‘c’ prevents the constraint ‘(C a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance C A -- Defined at Ambig.hs:10:10 instance C B -- Defined at Ambig.hs:12:26 • In the third argument of ‘GHC.Prim.coerce’, namely ‘c’ In the expression: GHC.Prim.coerce @(Int) @(Int) c In an equation for ‘c’: c = GHC.Prim.coerce @(Int) @(Int) c When typechecking the code for ‘c’ in a derived instance for ‘C B’: To see the code I am typechecking, use -ddump-deriv | 12 | newtype B = B A deriving C | }}} It shouldn't. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15763: GHC forbids kind signatures in data family instances
by GHC 17 Oct '18

17 Oct '18

#15763: GHC forbids kind signatures in data family instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 I say {{{#!hs class C (a :: k) instance (C :: Type -> Constraint) a }}} GHC is happy. Note that this is actually useful to do. But if I say {{{#!hs data family D (a :: k) data instance (D :: Type -> Type) a }}} GHC is unhappy: {{{ Malformed head of type or class declaration: (D :: Type -> Type) a }}} Fixing this will require a change to the `FamEqn` type, which doesn't have enough flexibility to deal with a kind signature there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15692: GHC panic from pattern synonyms + deferred type errors
by GHC 17 Oct '18

17 Oct '18

#15692: GHC panic from pattern synonyms + deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language DataKinds, TypeOperators, PolyKinds, PatternSynonyms, GADTs #-} {-# Options_GHC -dcore-lint -fdefer-type-errors #-} import Data.Kind data Ctx :: Type -> Type where E :: Ctx(Type) (:&:) :: a -> Ctx(as) -> Ctx(a -> as) data ApplyT (k::Type) :: k -> Ctx(k) -> Type where AO :: a -> ApplyT(Type) a E AS :: ApplyT(ks) (f a) ctx -> ApplyT(k -> ks) f (a:&:ctx) pattern ASSO = AS (AS (AO False)) }}} {{{ $ ghci -ignore-dot-ghci 463.hs hs/463.hs:16:27: warning: [-Wdeferred-type-errors] • Couldn't match type ‘a a1 a2’ with ‘Bool’ Expected type: a3 Actual type: Bool • In the pattern: False In the pattern: AO False In the pattern: AS (AO False) | 16 | pattern ASSO = AS (AS (AO False)) | ^^^^^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180828 for x86_64-unknown-linux): urk! lookup local fingerprint $mASSO [iESflb :-> ($trModule, 1ca40dc83a9c879effdb760462cc9a2d), iESgKD :-> ($tc'E, 79f67a27a14dc1bb6eecb39e4b061e2c), iESgKF :-> ($tc':&:, 24793c0c1652ffcf92e04f47d38fa075), iESgKH :-> ($tcCtx, a3f9358cbfe161bf59e75500d70ce0ae), iESgKI :-> ($tc'AO, 72111d1891cb082e989c20a2191a8b4b), iESgKK :-> ($tc'AS, ff019c04c400d5fbdd46ff8a816d4913), iESgKM :-> ($tcApplyT, cbfe28374b4115925c7213e6330ab115)] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:524:37 in ghc:MkIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8