January 2016 - ghc-tickets

[GHC] #11312: GHC inlining primitive string literals can affect program output
by GHC 14 Mar '18

14 Mar '18

#11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #11292 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First noted in #11292, this program, when compiled with `-O1` or higher: {{{#!hs {-# LANGUAGE MagicHash #-} module Main (main) where import GHC.Exts (Addr#, isTrue#) import GHC.Prim (eqAddr#) data A = A { runA :: Addr# } a :: A a = A "a"# main :: IO () main = print (isTrue# (eqAddr# (runA a) (runA a))) }}} will result in the following after inlining: {{{ Main.main2 = case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.eqAddr# "a"# "a"#) of _ [Occ=Dead] { GHC.Types.False -> GHC.Show.shows26; GHC.Types.True -> GHC.Show.shows24 } }}} As a result, there are two of the same string constant with different addresses, which causes `eqAddr#` to return `False`. If compiled without optimizations, `"a"#` is not inlined, and as a result, `eqAddr#` returns `True`. Two questions: 1. Is this okay semantics-wise? Or is this a necessary risk when working with primitive string literals, and should programmers judiciously use `{-# NOINLINE #-}` with them? 2. Is this okay from a code duplication standpoint? As Reid Barton noted in #11292, `"a"#` is duplicated due to inlining. In this example, not much is duplicated, but if it were a longer string constant, that could result in a noticeable increase in the object file size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8542: Suggest NegativeLiterals
by GHC 13 Mar '18

13 Mar '18

#8542: Suggest NegativeLiterals ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- If we write -128 :: Int8, we get a useful warning (#7895), but it would be even better to suggest NegativeLiterals. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm)
by GHC 07 Mar '18

07 Mar '18

#11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- {{{ $ ghc-head --info | grep Project [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","8.1.20151231") ,("Project Git commit id","8afeaad919dc67643b4eff14efafb48b59039b2b") }}} {{{ $ make slowtest TEST=dynamic-paper VERBOSE=2 TEST_HC=ghc-head ... =====> dynamic-paper(normal) 1 of 1 [0, 0, 0] =====> dynamic-paper(hpc) 1 of 1 [0, 0, 0] ... Compile failed (status 256) errors were: *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** <no location info>: warning: In a case alternative: (TypeRepX k_s7Ec :: *, a_s7Ed :: k_a5px, tr2_s7Ee :: TypeRep a_s7Ed) @ k_a5px is out of scope *** Offending Program *** ... <no location info>: error: Compilation had errors *** unexpected failure for dynamic-paper(hpc) =====> dynamic-paper(optasm) 1 of 1 [0, 1, 0] Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20151231 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone delta1 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 203160 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for dynamic-paper(optasm) Unexpected results from: TEST="dynamic-paper" }}} This test was added in commit 52da6bdc17bb491d6d2f462b3680eb44b9be92e5: {{{ Author: Richard Eisenberg <eir(a)cis.upenn.edu> Date: Sat Dec 26 09:11:33 2015 -0500 Have mkCastTy look more closely for reflexivity. This may have performance implications. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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] #11107: Can't use type wildcard infix
by GHC 26 Feb '18

26 Feb '18

#11107: Can't use type wildcard infix -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 fails: {{{ foo :: Int `_a` Bool foo = Right True }}} But moving `_a` to be prefix works. I observe the same behavior with an unnamed type wildcard. This was discovered while poking around in the renamer, not in real code! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8597: Git Hook script to prevent large binary blobs being checked in
by GHC 24 Feb '18

24 Feb '18

#8597: Git Hook script to prevent large binary blobs being checked in ------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It has already occurred in the past in `testsuite.git` repo, that executables were checked in by accident, and caused the Git history to get bloated. In order to avoid such accidents in the future a Git hook script in the style of [http://stackoverflow.com/questions/20226132/is-there-a-git-hook- which-can-prevent-binary-check-ins this] might be useful, but taking also into account the size, and/or possibly with a magic safeword to be put in the commit message, to override the check for a single commit, if the author really knows what (s)he's doing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8597> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11285: Static linking is really slow sometimes
by GHC 20 Feb '18

20 Feb '18

#11285: Static linking is really slow sometimes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- I'm testing on Cabal `Setup.hs`, which links against Cabal. On a beefy machine with many cores and lots of RAM, I see a x2 regression in linking time from GHC 7.10.2 to GHC 8.0 (a recent HEAD) using GNU ld (not gold): {{{ [ezyang@hs01 ezyang]$ rm A; time ghc --make A.hs -fforce-recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m1.273s user 0m0.990s sys 0m0.210s [ezyang@hs01 ezyang]$ rm A; time ghc-8.0/usr/bin/ghc --make A.hs -fforce- recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m3.270s user 0m2.727s sys 0m0.523s }}} On a puny eight year-old laptop, I see a x2 regression from 7.6 to 7.10 (with not much change with 8.0) {{{ ezyang@sabre:~$ rm A; time ghc --make -O0 A.hs -fforce-recomp rm: cannot remove ‘A’: No such file or directory [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m3.058s user 0m1.860s sys 0m1.164s ezyang@sabre:~$ rm A; time ghc-7.10 --make -O0 A.hs -fforce-recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m7.139s user 0m4.616s sys 0m2.488s }}} There must be something which is causing the linker to run slowly in one case, and quickly in the other. It would be really good to figure out what this is. Slow linking is NOT NICE. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11427: TypeSynonyms not deduced
by GHC 20 Feb '18

20 Feb '18

#11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{ class (AllF f xs, SListI xs) => All (f :: k -> Constraint) (xs :: [k]) instance #if __GLASGOW_HASKELL__ >= 710 {-# OVERLAPPING #-} #endif All SListI xss => SingI (xss :: [[k]]) where sing = sList }}} fails with {{{ • Could not deduce (SListI xss) arising from the superclasses of an instance declaration from the context: All SListI xss bound by the instance declaration at src/Generics/SOP/Constraint.hs:141:3-40 • In the instance declaration for ‘SingI xss’ }}} See https://travis-ci.org/well-typed/generics-sop/jobs/102388817 and https://github.com/phadej/generics-sop/tree/ghc-8.0.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9429: Alternative to type family Any
by GHC 18 Feb '18

18 Feb '18

#9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9097, 9380 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In GHC HEAD, `Any` is no longer a datatype. There are good reasons for this change, one of which was explained in #9097, the original ticket, and another in #9380. Unfortunately, a casualty of this change is that it is no longer easy to generalize the [https://hackage.haskell.org/package/rank1dynamic|rank1dynamic package] to rank-1 types with type variables of arbitrary kind (not just `*`). We submitted a way to do so [here], that exploits the fact that `Any` has the very magical property of inhabiting *all* kinds, including closed ones. This works for GHC 7.8, but won't work in HEAD, because we require that there exists a `Typeable` instance for `Any`, just as there are `Typeable` instances for any other type one wishes to have instances for. The reason is that now that `Any` is a type family, `Any` is no longer a legal instance head. There are several possible solutions that I see: * while it's clearly dangerous for the compiler to be inserting the old `Any` during typechecking from the moment that we have computation in types over closed kinds, we may still want the old `Any`, say under a different name, as a backdoor. It wouldn't be used by the compiler during type checking - only by packages such as rank1dynamic. I believe that furthermore, if we restrict the old `Any` to not inhabit closed kinds, then none of the problems cited in the above tickets arise. * Instead of making the new `Any` a type family, keep it a datatype, but ban it from inhabiting closed kinds. I don't know if such an `Any` would be sufficient for the purposes of GHC, however. * Hardwire a `Typeable` instance for the `Any` type family (not sure if this makes sense). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #8258: GHC accepts `data Foo where` in H2010 mode
by GHC 14 Feb '18

14 Feb '18

#8258: GHC accepts `data Foo where` in H2010 mode --------------------------+------------------------------------------------ Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.1 Component: | Version: 7.0.4 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts invalid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ According to the Haskell2010 report, The grammar productions relevant for `data` declarations are the following: {{{ topdecl → data [context =>] simpletype [= constrs] [deriving] }}} (from [http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2 4.2.1 Algebraic Datatype Declarations]) However, GHC 7.0.4/7.4.2/7.6.3/HEAD all happily compile the following Haskell module without any warning when using `-XHaskell2010 -Wall`, even though this is not valid Haskell2010 afaik: {{{#!hs module Foo where data Foo where }}} The trailing `where` in the `data` declaration is not valid Haskell2010 (without language extensions such as `GADT`). At the very least, this divergence from the Haskell Report should be mentioned in [http://www.haskell.org/ghc/docs/latest/html/users_guide /bugs-and-infelicities.html#haskell-standards-divergence 14.1.1. Divergence from Haskell 98 and Haskell 2010]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5