July 2016 - ghc-tickets

[GHC] #12042: Infinite loop with type synonyms and hs-boot
by GHC 15 Dec '16

15 Dec '16

#12042: Infinite loop with type synonyms and hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a "known" bug, but the source code comment which mentioned this could happen didn't give a test case so I thought I'd supply one. {{{ -- A.hs-boot module A where data S type R = S -- B.hs module B (module A, module B) where import {-# SOURCE #-} A type U = S -- A.hs module A where import qualified B type S = B.R type R = B.U }}} When I try to build `A.hs` in one-shot I infinite loop: {{{ ezyang@sabre:~$ ghc-8.0 --make A.hs -fforce-recomp [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) A.hs-boot:2:1: error: Type constructor ‘S’ has conflicting definitions in the module and its hs-boot file Main module: type S = R Boot file: abstract S ezyang@sabre:~$ ghc-8.0 -c A.hs -fforce-recomp ^C }}} The problem is that `-c` properly knot ties `data S` in the boot file to the local type synonym (`--make` is unaffected due to #12035), and then we have a type synonym loop which GHC doesn't catch early enough. `TcTyDecls.hs` has a nice comment which suggests that this is a known bug: {{{ Checking for class-decl loops is easy, because we don't allow class decls in interface files. We allow type synonyms in hi-boot files, but we *trust* hi-boot files, so we don't check for loops that involve them. So we only look for synonym loops in the module being compiled. We check for type synonym and class cycles on the *source* code. Main reasons: a) Otherwise we'd need a special function to extract type-synonym tycons from a type, whereas we already have the free vars pinned on the decl b) If we checked for type synonym loops after building the TyCon, we can't do a hoistForAllTys on the type synonym rhs, (else we fall into a black hole) which seems unclean. Apart from anything else, it'd mean that a type-synonym rhs could have for-alls to the right of an arrow, which means adding new cases to the validity checker Indeed, in general, checking for cycles beforehand means we need to be less careful about black holes through synonym cycles. The main disadvantage is that a cycle that goes via a type synonym in an .hi-boot file can lead the compiler into a loop, because it assumes that cycles only occur entirely within the source code of the module being compiled. But hi-boot files are trusted anyway, so this isn't much worse than (say) a kind error. }}} although the circumstances in this example are a little different. I take this bug as evidence that we should NOT attempt to knot-tie in this situation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory
by GHC 13 Dec '16

13 Dec '16

#9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I initially filed this as a [http://stackoverflow.com/questions/26333815 /why-do-hgetbuf-hputbuf-etc-allocate-memory question on StackOverflow], assuming that the behavior I'm seeing was intentional, or that I was misinterpreting the profiler results... but Kazu Yamamoto [https://twitter.com/kazu_yamamoto/status/522583112249663488 suggested] I should file this as an issue here. It's my first GHC ticket, so here goes: {{{#!hs main :: IO () main = do buf <- mallocArray 1 echo buf echo :: Ptr Word8 -> IO () echo buf = forever $ do len <- readRawBufferPtr "read" stdin buf 0 1 writeRawBufferPtr "write" stdout buf 0 (fromIntegral len) }}} I expect the only heap allocation here should be my explicit `mallocArray`, but profiling with `+RTS -P` indicates this isn't the case: both the read and write operations do appear to allocate some short-lived heap objects. In contrast: {{{#!hs echo :: Ptr Word8 -> IO () echo buf = forever $ do threadWaitRead $ Fd 0 len <- c_read 0 buf 1 c_write 1 buf (fromIntegral len) yield }}} does not appear to allocate. I did a bit of digging (copying bits of source code from `base` into my own project, to get cost center annotations) and it seems like the allocation might be happening in `throwErrnoIfRetryMayBlock`. See [https://gist.github.com/anonymous/3ba3cfa118e1d05870d4 this gist] for more detail, including core output from `-ddump-simpl`. In all honesty, I don't know whether this is a bug. I was just surprised by it, when I first encountered it using `hGetBuf` / `hPutBuf`, so I'm trying to understand whether this is expected behavior and why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8248: GHCi should not warn if group writable
by GHC 13 Dec '16

13 Dec '16

#8248: GHCi should not warn if group writable ----------------------------+---------------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Any number of Linux distros support the idea of user groups, whereby when a new user is created there is also simultaneously a group created with the same name; ie, instead of {{{ -rw-r--r--. 1 andrew users 19 Sep 5 08:29 ghci.conf }}} as us old traditionalists would have it, you get {{{ -rw-rw-r--. 1 andrew andrew 19 Sep 5 08:29 ghci.conf }}} because the umask in such cases is 0002 instead of 0022. There is entirely nothing unusual or incorrect about this approach, and it is followed, for example, in the Fedora family of distros. GHC, however, is being a bit silly in emitting the following: {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. *** WARNING: /home/andrew/.ghc/ghci.conf is writable by someone else, IGNORING! Prelude> }}} Foremost the fact that the file is group writable is not a problem and the user's choice, //particularly// in this case because it's group writable in the user's group! Regardless of that, GHCi should not be ignoring files with other than 0644 permissions; this isn't `.ssh/`. Can this check and attendant behaviour be removed? AfC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11739: Simplify axioms; should be applied to types
by GHC 12 Dec '16

12 Dec '16

#11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Simon PJ says: In `Note [Coercion axioms applied to coercions]` in Coercion, we find the justification for allowing coercions as arguments to axioms. The goal is to add a bit of extra expressiveness, so that optimisations can be done pair-wise. But the example shows that the new expressiveness is not expressive enough! Rather than give up (as you do in !OptCoercion) maybe we should re-examine the assumption. How could we optimise if axioms could only be instantiated with types, not coercions. Which would be a LOT simpler! Let's take the example from the Note: {{{ C a : t[a] ~ F a g : b ~ c }}} and we want to optimize {{{ sym (C b) ; t[g] ; C c :: F b ~ F c }}} One possibility is to perform a 3-component optimisation, but that's a bit horrible. But what about this: push the `t[g]` ''past'' the axiom rather than ''into'' it. For example {{{ t[g] ; C c ==> C b ; F g where t[g] : t[b]~t[c] C c : t[c] ~ F c }}} If we use this to move axioms to the right, I think we'll get the same optimisations as now, but with a simpler system. Does that seem right? Now it becomes clearer that you can't always commute the things. {{{ ax : F a a ~ a; F a b ~ b co :: Id Bool ~ Bool }}} If we have {{{ (F <Int> co ; ax[1] Int Bool) : F Int (Id Bool) ~ Bool }}} then we might try to commute `co` past the axiom thus: {{{ ax[1] Int (Id Bool) ; co }}} but now (as you point out) the ax[1] is not necessarily OK. But I hazard that the lack of the commuting isn't going to lose useful optimisations. So in some ways we are no further forward (an optimisation is only sometimes OK), but I feel MUCH happier about simplifying the axiom- applied-to-coercion stuff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm
by GHC 09 Dec '16

09 Dec '16

#9308: nofib fannkuch-redux runs perpetually with -fllvm ------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Running the nofib benchmarks with make -k EXTRA_HC_OPTS=-fllvm on a HEAD build of ghc configured with perf-llvm (3.4.2) results in fannkuch-redux running in an infinite loop. The benchmark runs in about 3.5s without the -fllvm {{{ HC = /Users/xx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 RUNTEST_OPTS = -ghc-timing ==nofib== fannkuch-redux: time to compile Main follows... /Users/jrp/Projects/ghc/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 -c Main.hs -o Main.o <<ghc: 358716248 bytes, 313 GCs, 10827462/27497216 avg/max bytes residency (6 samples), 57M in use, 0.00 INIT (0.00 elapsed), 0.20 MUT (0.53 elapsed), 0.21 GC (0.23 elapsed) :ghc>> ==nofib== fannkuch-redux: size of Main.o follows... __TEXT __DATA __OBJC others dec hex 10333 497 0 0 10830 2a4e ==nofib== fannkuch-redux: time to link fannkuch-redux follows... <<ghc: 19914544 bytes, 16 GCs, 1005021/2239600 avg/max bytes residency (3 samples), 25M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.53 elapsed), 0.02 GC (0.02 elapsed) :ghc>> ==nofib== fannkuch-redux: size of fannkuch-redux follows... __TEXT __DATA __OBJC others dec hex 4075520 446464 0 4295945496 4300467480 10053ed18 ==nofib== fannkuch-redux: time to run fannkuch-redux follows... ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9504: LLVM backend TBAA is too aggressive
by GHC 09 Dec '16

09 Dec '16

#9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Ali… there is written > It [a memory load/store] is very rarely of the form: > {{{ > x = Sp + 8 > I64[x] = ... > }}} > And when it is, 'it is' (unconfirmed) always deriving a "heap" pointer, "stack" pointers are always of the in-line variety. In fact commit e10589a505b44f4f0394500c6a0d2db5baa7f3f4 treats any memory access through a Cmm local variable as having the "other" type, which cannot alias any non-"other" address. But it turns out that a Cmm local might be either an offset from Sp (#9125, though TBAA doesn't seem to have been the cause of the bad code there) or an offset from a Cmm global variable (#9308). In general, we don't know anything about what it might be so we should conservatively use the "top" "type". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9125: int-to-float conversion broken on ARM - 7.8.1-rc2
by GHC 09 Dec '16

09 Dec '16

#9125: int-to-float conversion broken on ARM - 7.8.1-rc2 --------------------------+------------------------------------------------ Reporter: | Owner: Ansible | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1 Component: | Operating System: Linux Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: arm | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I compiled ghc on the raspberry pi. See this bug for more about that build of ghc: [https://ghc.haskell.org/trac/ghc/ticket/8896 8896]. A simple test program: {{{ main = do mapM_ (print . (fromInteger :: Integer -> Float)) [0..100] }}} And the result: {{{ 0.0 127.0 256.0 257.0 516.0 517.0 518.0 519.0 1040.0 1041.0 1042.0 1043.0 1044.0 1045.0 1046.0 1047.0 2096.0 2097.0 2098.0 2099.0 2100.0 2101.0 2102.0 2103.0 2104.0 2105.0 2106.0 2107.0 2108.0 2109.0 2110.0 2111.0 4224.0 4225.0 4226.0 4227.0 4228.0 4229.0 4230.0 4231.0 4232.0 4233.0 4234.0 4235.0 4236.0 4237.0 4238.0 4239.0 4240.0 4241.0 4242.0 4243.0 4244.0 4245.0 4246.0 4247.0 4248.0 4249.0 4250.0 4251.0 4252.0 4253.0 4254.0 4255.0 8512.0 8513.0 8514.0 8515.0 8516.0 8517.0 8518.0 8519.0 8520.0 8521.0 8522.0 8523.0 8524.0 8525.0 8526.0 8527.0 8528.0 8529.0 8530.0 8531.0 8532.0 8533.0 8534.0 8535.0 8536.0 8537.0 8538.0 8539.0 8540.0 8541.0 8542.0 8543.0 8544.0 8545.0 8546.0 8547.0 8548.0 8538.0 }}} This code, however, works normally: {{{ main = do mapM_ (print . (fromInteger :: Integer -> Double)) [0..100] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9125> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #12357: Increasing maximum constraint tuple size significantly blows up compiler allocations
by GHC 09 Dec '16

09 Dec '16

#12357: Increasing maximum constraint tuple size significantly blows up compiler allocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In July 2015 (dd3080fe0263082f65bf2570f49189c277b12e28) the maximum constraint tuple size was raised from 16 to 62 to address #10451. It turns out that this change is apparently one of the larger compile-time regressions in recent GHC history. For instance, the nofib `real/fulsom/Shapes.hs` module regresses by 16% in both compiler allocations and compile time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #8953: Reifying poly-kinded type families misses kind annotations
by GHC 09 Dec '16

09 Dec '16

#8953: Reifying poly-kinded type families misses kind annotations ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following two modules: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-} module A where type family Poly (a :: k) :: * type instance Poly (x :: Bool) = Int type instance Poly (x :: Maybe k) = Double }}} {{{ {-# LANGUAGE TemplateHaskell #-} module B where import Language.Haskell.TH import A $( do info <- reify ''Poly runIO $ putStrLn $ pprint info return [] ) }}} Compiling with HEAD yields this output: {{{ type family A.Poly (a_0 :: k_1) :: * type instance A.Poly x_2 = GHC.Types.Double type instance A.Poly x_3 = GHC.Types.Int }}} The problem is that the type patterns in the reified instances are just plain variables, without their kind annotations. This omission makes the instance declarations unfaithful to the original meaning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8953> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #8925: :print and :sprint sometimes fully evaluates strings
by GHC 09 Dec '16

09 Dec '16

#8925: :print and :sprint sometimes fully evaluates strings ------------------------------------+------------------------------------- Reporter: soapie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Not too confident in my terminology but `:sprint`ing a string that has been evaluated down to its spine seems to fully evaluate the string: {{{ Prelude> let a = map (Debug.Trace.trace "!!!") "abc" Prelude> a `seq` () () Prelude> :sprint a a = _ : _ -- looks fine Prelude> length a 3 Prelude> :sprint a a = "!!! -- strange! a!!! b!!! c" }}} What I expect to see is `a = [_,_,_]`. `:print` behaves similarly. Since neither `:print` nor `:sprint` is supposed to force any evaluation this seems like a bug. At least it can make debugging quite confusing if you're not aware of it! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8925> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2