March 2019 - ghc-tickets

[GHC] #15967: can't build ghc on Mac with any level of dwarf for base library
by GHC 03 Mar '19

03 Mar '19

#15967: can't build ghc on Mac with any level of dwarf for base library -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- i tried building base in 8.6.2 with -g1 and i get the following error pretty consitently from the system linker ``` ld: in /Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/libraries/base/dist-install/build/libHSbase-4.12.0.0_p.a(Base.p_o), sectionForAddress(0x8066) address not in any section for architecture x86_64 ``` if i do ``` GhcLibHcOpts += -g1 ``` or higher in the build.mk file, i get this linker error at some point in building ghc or resulting executables . I'm not sure if its *just* for profiled libs or every lib, but it looks like theres actually no way to handle the number of dwarf sections for large archives on OSX?! or equivalently, we may need support for more parsimonious dwarf annotations if at all? point being: if we can't support debug symbols for base on a tier 1 platform, either debug symbols working isn't part of our support SLA for tier 1 platforms, OR its a release blocker we've not had in our validate configuration matrix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15967> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16286: Continuations are not labelled in the binaries even with -g3
by GHC 03 Mar '19

03 Mar '19

#16286: Continuations are not labelled in the binaries even with -g3 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Any program would work as a reproducer, but here's what I'm using currently: {{{ {-# LANGUAGE StaticPointers #-} module Main where import Control.Concurrent import System.Mem nats :: [Int] nats = [0 .. ] main = do let z = nats !! 400 print z performGC threadDelay 1000000 print (nats !! 900) }}} If I do `printStack` every time the GC copies a stack I sometimes see stack frames like {{{ RET_SMALL (0x535568) }}} but in gdb or objdump output I can't find a symbol at that address, even when the program is built with `-g3`. When I print the location as `StgInfoTable*` I can see that it's a valid info table so `0x535578` should be labelled as `foo_info`. In the objdump output I see that the location is shown as this: {{{ 535563: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) ... 535570: 1e (bad) 535571: 00 00 add %al,(%rax) 535573: 00 00 add %al,(%rax) 535575: 00 00 add %al,(%rax) 535577: 00 bb e9 e2 85 00 add %bh,0x85e2e9(%rbx) 53557d: 48 83 c5 08 add $0x8,%rbp }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler)
by GHC 03 Mar '19

03 Mar '19

#15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) ----------------------------------------+--------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- for current master, if i build on a mac / OSX high sierra environment with CC set as any flavor of recent GCC rather than apple clang, i get a failure "no open frame" when as (aka apple clang / apple llvm acting as the assembler) is run on the .s file produced by stgRun.c (rts/StgCRun.c to be exact) this error message seems to come from https://github.com/llvm- mirror/llvm/blob/da4a2839d80ac52958be0129b871beedfe90136e/lib/MC/MCStreamer.cpp#L221 https://gist.github.com/cartazio/8cbfb3305e1daa4f7ffc3f6bb90a2891 has the gcc and clang style assembly for /usr/local/bin/gcc-8 -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -fno-common -U__PIC__ -D__PIC__ -x assembler -c /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc22029_0/ghc_1.s -o rts/dist/build/StgCRun.debug_o this is example asm for the the debug way -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 49

[GHC] #15461: Machine accessible interface to GHCi
by GHC 03 Mar '19

03 Mar '19

#15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For a long time tooling users (e.g. `haskell-mode`) have been treating GHCi as a language server. As one would expect this leads to a frustrating situation for both GHC developers (who feel constrained in their ability to change output) and users (who occasionally suffer breakage, e.g. [[https://github.com/haskell/haskell- mode/issues/1553#issuecomment-409267399]]). Ultimately the solution seems fairly clear: 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user could have multiple textual REPLs open, all served by the same GHCi session) 2. add a machine-readable request protocol to GHCi, giving tooling users a way to use GHCi's functionality without parsing human-readable output (1) should be fairly straightforward to implement. (2) on the other hand requires some design work (e.g. what does the wire protocol look like?) and a fair bit of refactoring (to expose the existing commands in a machine-readable manner). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15461> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14494: TBQueue leaks space under certain workloads
by GHC 03 Mar '19

03 Mar '19

#14494: TBQueue leaks space under certain workloads -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.2.1 (other) | Keywords: stm | 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 using TBQueue and I noticed suspiciously high memory usage, so I decided to profile and it turned out that readTBQueue leaks space (see attached before.png). After closer inspection it turned out it's the `writeTVar rsize (r + 1)` in readTBQueue definition that's the problem - after substitution it for `writeTVar rsize $! r + 1` the leak is gone (see attached after.png) Here are -s outputs: Before: {{{ 366,535,518,024 bytes allocated in the heap 115,643,281,224 bytes copied during GC 241,356,416 bytes maximum residency (1182 sample(s)) 1,516,944 bytes maximum slop 392 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 247273 colls, 247273 par 128.854s 28.654s 0.0001s 0.0182s Gen 1 1182 colls, 1181 par 352.162s 87.812s 0.0743s 0.1322s Parallel GC work balance: 78.17% (serial 0%, perfect 100%) TASKS: 24 (1 bound, 16 peak workers (23 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.003s ( 0.003s elapsed) MUT time 581.754s (226.191s elapsed) GC time 317.130s ( 75.533s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 163.885s ( 40.933s elapsed) EXIT time 0.013s ( 0.011s elapsed) Total time 1062.789s (301.738s elapsed) Alloc rate 630,052,684 bytes per MUT second Productivity 54.7% of total user, 61.4% of total elapsed gc_alloc_block_sync: 8998531 whitehole_spin: 96 gen[0].sync: 180553 gen[1].sync: 31648044 }}} After: {{{ 431,671,260,464 bytes allocated in the heap 86,540,207,400 bytes copied during GC 170,338,336 bytes maximum residency (1381 sample(s)) 1,159,472 bytes maximum slop 260 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 290179 colls, 290179 par 148.921s 33.097s 0.0001s 0.0217s Gen 1 1381 colls, 1380 par 206.679s 51.492s 0.0373s 0.0528s Parallel GC work balance: 75.51% (serial 0%, perfect 100%) TASKS: 23 (1 bound, 17 peak workers (22 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.005s ( 0.004s elapsed) MUT time 681.718s (241.009s elapsed) GC time 258.643s ( 60.370s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 96.957s ( 24.219s elapsed) EXIT time 0.009s ( 0.007s elapsed) Total time 1037.335s (301.390s elapsed) Alloc rate 633,210,748 bytes per MUT second Productivity 65.7% of total user, 71.9% of total elapsed gc_alloc_block_sync: 5494680 whitehole_spin: 184 gen[0].sync: 184109 gen[1].sync: 24223953 }}} Attached patch fixes the problem (I made all Int increments/decrements in the module strict as there is no need for them to be lazy). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16382: Lifting a function from where clause to top level causes compilation time to triple
by GHC 03 Mar '19

03 Mar '19

#16382: Lifting a function from where clause to top level causes compilation time to triple -------------------------------------+------------------------------------- Reporter: danidiaz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.2 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: -------------------------------------+------------------------------------- I have this program that depends on the library "red-black-record" version 2.0.2.2 on Hackage: {{{#!hs {-# LANGUAGE DataKinds, TypeApplications #-} module Main where import Data.RBR (FromList,Delete,Variant,I,injectI,winnowI,match) import GHC.TypeLits type Phase01 = FromList '[ '("ctor1",Int), '("ctor2",Bool), '("ctor4",Char), '("ctor3",Char), '("ctor6",Char), '("ctor5",Char), '("ctor10",Char), '("ctor11",Char), '("ctor13",Char), '("ctor14",Char), '("ctor39",Char), '("ctor46",Char), '("ctor47",Char), '("ctor44",Char), '("ctor43",Char), '("ctor7",Char), '("ctor9",Char), '("ctor20",Char), '("ctor45",Char), '("ctor21",Char), '("ctor48",Char), '("ctor49",Char), '("ctor50",Char), '("ctor41",Char), '("ctor33",Char), '("ctor32",Char), '("ctor42",Char), '("ctor22",Char), '("ctor23",Char), '("ctor8",Char), '("ctor40",Char), '("ctor29",Char), '("ctor24",Char), '("ctor38",Char), '("ctor25",Char), '("ctor26",Char), '("ctor27",Char), '("ctor28",Char), '("ctor36",Char), '("ctor52",Char), '("ctor51",Char), '("ctor53",Char), '("ctor12",Char), '("ctor54",Char), '("ctor15",Char), '("ctor31",Char), '("ctor30",Char), '("ctor34",Char), '("ctor35",Char), '("ctor17",Char), '("ctor16",Char), '("ctor18",Char), '("ctor19",Char), '("ctor37",Char) ] type Phase02 = Delete "ctor1" Int Phase01 main :: IO () main = print (match @"ctor17" (fromPhase1ToPhase2 (injectI @"ctor1" 2))) where fromPhase1ToPhase2 :: Variant I Phase01 -> Variant I Phase02 fromPhase1ToPhase2 v = case winnowI @"ctor1" @Int v of Right z -> injectI @"ctor2" False Left l -> l }}} "red-black-record" provides extensible variants; the code is basically removing a branch from a variant with 50-plus branches, and then trying to match another branch. It is type family-heavy code. The code as it is takes **~9 seconds** to compile on my machine. But when I move the `fromPhase1ToPhase2` function to the top level (including the signature) compilation time balloons to **~29 seconds**. Is there a reason it should be so? As another datapoint, moving the function to the top level but omitting the complex type-level map parameters (`Phase01`, `Phase02`) using partial type signatures (also requires a new type application) compiles in **~9 seconds** again. {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# OPTIONS_GHC -Wno-partial-type-signatures #-} -- ... type Phase02 = Delete "ctor1" Int Phase01 fromPhase1ToPhase2 :: Variant I _ -> Variant I _ fromPhase1ToPhase2 v = case winnowI @"ctor1" @Int @Phase01 v of Right z -> injectI @"ctor2" False Left l -> l main :: IO () main = print (match @"ctor17" (fromPhase1ToPhase2 (injectI @"ctor1" 2))) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3094: Some GHC.* module should export word size and heap object header size
by GHC 03 Mar '19

03 Mar '19

#3094: Some GHC.* module should export word size and heap object header size -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 6.10.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It seems to me like the new `ghc-heap` package would be a good place for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3094#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10841: Run handler on STM retry
by GHC 03 Mar '19

03 Mar '19

#10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Keywords: stm | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It would be nice to have a function like: {{{#!hs -- | Perform a series of STM actions atomically. -- -- Whenever the transaction retries, run the handler. If it doesn't return 'Nothing', -- stop the retrying and return the value given by the handler. atomicallyWithRetryHandler :: STM a -> IO (Maybe a) -> IO a }}} This would allow tracking retry statistics, printing debug messages on each retry, etc. without resorting to unsafeIOToSTM which can't safely do things like printing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16381: Regression: Implicitly kind variables not in scope
by GHC 03 Mar '19

03 Mar '19

#16381: Regression: Implicitly kind variables not in scope -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.10.1 Component: Compiler | Version: 8.9 (Type checker) | 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: -------------------------------------+------------------------------------- Our new `head.hackage` CI infrastructure has caught its first regression, it seems. A number of packages now fail to build due to out-of-scope kind variables. For instance, `singleton-bool`: {{{ [1 of 1] Compiling Data.Singletons.Bool ( src/Data/Singletons/Bool.hs, dist/build/Data/Singletons/Bool.o ) *** Parser [Data.Singletons.Bool]: Parser [Data.Singletons.Bool]: alloc=4264704 time=6.901 *** Renamer/typechecker [Data.Singletons.Bool]: Renamer/typechecker [Data.Singletons.Bool]: alloc=17554720 time=92.794 src/Data/Singletons/Bool.hs:119:29: error: Not in scope: type variable ‘k’ | 119 | sboolEqRefl :: forall (a :: k) (b :: k). SBoolI (a == b) => Maybe (a :~: b) | ^ src/Data/Singletons/Bool.hs:119:38: error: Not in scope: type variable ‘k’ | 119 | sboolEqRefl :: forall (a :: k) (b :: k). SBoolI (a == b) => Maybe (a :~: b) | ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16320: Clean up printing of foralls
by GHC 03 Mar '19

03 Mar '19

#16320: Clean up printing of foralls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Simon and I agreed on several infelicities around the printing of types with foralls. Before cleaning up the code, though, we wanted a ''specification'' of what we should do. Here is what we have. When printing types for users (in GHCi and certain error messages), it is convenient to sometimes suppress `forall`s. Given a type `ty` to print, `forall`s will be suppressed when ''all'' of the following are true: 1. `-fprint-explicit-foralls` is not in effect. 2. The kinds of all bound type variables are Haskell98-style. That is, the kinds consist only of `Type` and `->`. 3. No bound type variable is `Required`. 4. The `forall`s are all at the top. Exception: `forall`s are allowed to be mixed with class constraints, but no `forall`s can appear under a proper `->`. 5. No two quantified type variables are spelled the same. This decision is made once, while looking at the overall type. Once made, it is not challenged: either all `forall`s in a type are printed, or none are. Reasons behind the conditions: 1. No comment. 2. Currently, we print `forall k (a :: k). ...` when there is a bound type variable with a variable kind. But, really, the fact that it's a variable isn't the only way it could be interesting. 3. `Required` type variables must be supplied; omitting these would be very confusing. 4. If a type has nested `forall`s, it's best to print. Reason for exception: the type of `return` is properly `forall (m :: Type -> Type). Monad m => forall (a :: Type). a -> m a`. Note that a `forall` is under a class constraint. But we want to suppress the `forall`s there, too. 5. Imagine this abuse of our language: {{{#!hs class C a b where meth :: forall a. a -> b }}} The type of `meth` is `forall a b. C a b => forall a. a -> b`. This is, actually, a well-formed type, where one type variable shadows another. But if we don't print the `forall`s, any reader will come to the wrong conclusion about the meaning of the type. This is a slight tweak to the current rules, meaning more `forall`s are printed than previously. Pointedly, this will not happen in Haskell98-style code, so they will not appear for beginners. The current state of affairs is messy, on the other hand, where some `forall`s may be suppressed in a type while others are printed, causing more trouble. While in town, any fix should also address comment:17:ticket:11786, which is about a seeming inefficiency of the implementation of `eliminateRuntimeReps`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16320> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2