September 2018 - ghc-tickets

[GHC] #15333: Weird cachegrind results for binary-trees
by GHC 14 Dec '18

14 Dec '18

#15333: Weird cachegrind results for binary-trees -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: NoFib | Version: 8.5 benchmark suite | 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 currently investigating an alleged regression in my branch of the late lambda lift and hit a confusing data point. Note that I'm very much relying on cachegrinds counted instructions/memory accesses for my findings. Check out the most recent version of `nofib` and run the following script: {{{#!sh #! /usr/bin/env zsh sed -i 's/import Debug.Trace//g' Main.hs # Make the following line idempotent echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp Main.hs # add the import for trace sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt1 sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt2 valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace }}} This will compile two versions of `binary-trees`, one with an extra `trace "" $` call before the only call to the `bit` function. One would expect the version with the `trace` call (`bt1`) to allocate more than the version without (`bt2`). Indeed, the output of `+RTS -s` suggests that: {{{ $ ./bt1 12 +RTS -s ... 43,107,560 bytes allocated in the heap ... $ ./bt2 12 +RTS -s ... 43,116,888 bytes allocated in the heap ... }}} That's fine. A few benchmark runs by hand also suggested the tracing version is a little slower (probably due to IO). Compare that to the output of the above cachegrind calls: {{{ $ valgrind --tool=cachegrind ./bt1 12 > /dev/null ... I refs: 118,697,583 ... D refs: 43,475,212 ... $ valgrind --tool=cachegrind ./bt2 12 > /dev/null ... I refs: 116,340,710 ... D refs: 42,523,369 ... }}} It's the other way round here! How's that possible? Even if this isn't strictly a bug in GHC or NoFib, it's relevant nonetheless, as our benchmark infrastructure currently relies on instruction counts. I couldn't reproduce this by writing my own no-op `trace _ a = a; {-# NOINLINE trace #-}`, btw. I checked this on GHC 8.2.2 and a semi-recent HEAD commit (bb539cfe335eeec7989332b859b1f3162c5e105a). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension)
by GHC 14 Dec '18

14 Dec '18

#14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) -------------------------------------+------------------------------------- Reporter: takenobu | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 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: #13126 #9224 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Implement Underscores in Numeric Literals Proposal. GHC supports various numeric literals such as decimal, octal, hexadecimal, binary, and floating point numbers. However, large numeric literals are hard to read. This proposal improves the readability, quality, expressiveness of numeric literals. This proposal allows underscores to numeric literals when the `NumericUnderscores` language extension is enabled. Underscores (`_`) in numeric literals are simply ignored. The specification of the feature is available here:\\ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0009 -numeric-underscores.rst For a discussion:\\ https://github.com/ghc-proposals/ghc-proposals/pull/76 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14345: Warning when linking with C++ code
by GHC 13 Dec '18

13 Dec '18

#14345: Warning when linking with C++ code -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When linking with a C++ file, GHC 8.2.1.20170928 produces a warning because it runs gcc with 'std=gnu99', even when I pass 'std=c++11' to cc- options (when using stack, I see that the command is something like 'gcc std=gnu99 ... std=c++11', so it isn't *ignoring* my input, just appending it.) I believe this warning is new as of 8.2. The attached example demonstrates the problem: {{{ > cabal configure > cabal build cc1plus: warning: command line option ‘-std=gnu99’ is valid for C/ObjC but not for C++ cc1plus: warning: command line option ‘-std=gnu99’ is valid for C/ObjC but not for C++ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15080: List Operators Sorted by Precedence in GHCi
by GHC 13 Dec '18

13 Dec '18

#15080: List Operators Sorted by Precedence in GHCi -------------------------------------+------------------------------------- Reporter: sjs | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: operator | Operating System: Unknown/Multiple precedence | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a large project, it can be difficult to keep track of the precedence of operators. It would be a nice quality-of-life improvement if there were a GHCi command to list the current operators in scope by precedence. It could list them in a table like this: {{{ :operators | prec | nonassoc | leftassoc | rightassoc | |------+----------+-----------+------------| | 9 | !! | | . | | 8 | | | ^ ^^ ** | | 7 | * / | | | | 6 | + - | | | | 5 | | | : ++ | | 4 | | == | | }}} Perhaps it could list all infix operators, as well as functions that have a fixity declaration? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15080> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15485: GHC uses 300% CPU when calling into blocking C call
by GHC 13 Dec '18

13 Dec '18

#15485: GHC uses 300% CPU when calling into blocking C call -------------------------------------+------------------------------------- Reporter: oconnore | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I'm trying to write a program that modifies /etc/passwd safely, and so I wrote a function that looks like this: {{{#!hs lockPwd f = bracket main recover (\_ -> f) where mode = unionFileModes ownerReadMode ownerWriteMode main = do fd <- openFd "/etc/.pwd.lock" WriteOnly (Just mode) defaultFileFlags putStrLn "waiting to set lock" waitToSetLock fd (WriteLock, AbsoluteSeek, 0, 0) putStrLn "got lock" return fd recover = flip setLock (Unlock, AbsoluteSeek, 0, 0) }}} When I run it, my fans go wild, and CPU usage hits 300%. /u/gelisam did some more in depth investigation here: https://www.reddit.com/r/haskell/comments/94wbfc/systemunixiowaittosetlock_… > Googling confirms that the parallel gc is using spin locks. So I think what is happening is that the waitToSetLock call makes the current thread unavailable for garbage collection (I don't know if that means the thread is "descheduled" as in the linked issue), which then causes the other threads to spin-lock while waiting for that thread at the next parallel GC. The problem still occurs with the latest release, GHC 8.4.3, and I could not find an existing issue describing the problem, so please file a ticket. Maybe an argument could be made that this waitToSetLock call should be converted to be [[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi- chap.html#interruptible-foreign-calls|interruptible]], but it also seems like I should be able to make my haskell program block patiently if I want it to. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15267: Extend TVar/MVar to N capacity / Add primitive channal type
by GHC 13 Dec '18

13 Dec '18

#15267: Extend TVar/MVar to N capacity / Add primitive channal type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | 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 current concurrent primitives `TVar` and `MVar` have a fixed single capacity for holding the value to be synchronized. This pose great limitations on implementing many higher level concurrent structures efficiently, e.g. bound channel, semaphore, resource pool, etc. For example current <semaphore's implementation http://hackage.haskell.org/package/base-4.11.1.0/docs/src/Control.Concurren…> is not ideal due to the extensive usage of multiple `MVar` s. If we have a good `BoundedChan a` type, semaphores can be easily implemented with `BoundedChan ()`. Currently we have various bound channel implementations, but these implementations are often not very efficient or too complex. For example the `BoundedChan` from <BoundedChan http://hackage.haskell.org/package/BoundedChan-1.0.3.0/docs/Control- Concurrent-BoundedChan.html> is based on an array of `MVar` s, thus consumes much more memory than a primitve channel which only have to record parked `StgTSO` s. I'm thinking adding something like: ``` typedef struct { StgHeader header; struct StgMVarTSOQueue_ *head; struct StgMVarTSOQueue_ *tail; StgInt capacity; // the channel's capacity StgInt read_index; // the reading end's index StgInt write_index; // the writing end's index StgClosure *payload[]; // payload array in continuous memory } StgMChan; ``` I still can't work out all the details, but I'm confident something similar to this will work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules
by GHC 12 Dec '18

12 Dec '18

#14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Because of the way the GHCi defaults are applied, specifying `-XMonomorphismRestriction` or `-XNoExtendedDefaultRules` on the GHCi command line doesn't actually make those take effect at the interactive prompt. They get reset to their interactive defaults afterwards. This is rather surprising, and I think it should be fixed. One option is to dig through the parsed flags after setting the defaults to try to find these, but that sounds unpleasant. We're slowly accumulating hacks in this area, and it would be nice to find a better approach. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates
by GHC 12 Dec '18

12 Dec '18

#15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: GHCProposal | 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 [https://github.com/ghc-proposals/ghc-proposals/pull/71 proposal] has been accepted, and could be implemented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs
by GHC 11 Dec '18

11 Dec '18

#11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10458 #5289 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In particular when compiling on NixOS, but also in many other situations, it is often needed to pass --extra-lib-dirs / --extra-include-dirs to cabal/stack, to help GHC find required system libraries. This works fine for GHC, but not GHCi, and therefore also not Template Haskell code. Minimal example attached. Try it in an environment where libz is not in a standard location, e.g. inside a nix-shell. Note that if you remove the template Haskell splice in Main.hs, the code compiles just fine. This affects GHC 7.10.2, but also HEAD from 2015-08-28, even one including Tamar Christina's 5d841108acef950fed6a5e608ac9b18e7431aa87 commit cherry- picked. I haven't been able to test more recent HEAD, because of unrelated compilation issues. I surmise that a fix to #10458, which currently blocks using HaskellR in GHCi, would also fix this, but I'm not sure. The error message I get is different: {{{ $ stack build --skip-ghc-check --extra-lib- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/lib --extra- include- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/include b-0.1.0.0: build Preprocessing executable 'b' for b-0.1.0.0... [2 of 2] Compiling Main ( src/Main.hs, .stack- work/dist/x86_64-linux/Cabal-1.23.0.0/build/b/b-tmp/Main.o ) <command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory) -- While building package b-0.1.0.0 using: /home/mboes/.stack/setup-exe-cache/setup-Simple- Cabal-1.23.0.0-x86_64-linux-ghc-7.11.20150828 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.23.0.0/ build exe:b --ghc-options " -ddump- hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings
by GHC 11 Dec '18

11 Dec '18

#15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using GHC 8.4.3, I'd expect the following to work: {{{#!hs {-# LANGUAGE RebindableSyntax, OverloadedStrings #-} module Fail where import Prelude hiding (fail) foo x = do Just y <- x return y newtype Text = Text String fail :: Text -> a fail (Text x) = error x fromString :: String -> Text fromString = Text }}} But it fails with: {{{ Fail.hs:8:5-15: error: * Couldn't match expected type `[Char]' with actual type `Text' * In a stmt of a 'do' block: Just y <- x In the expression: do Just y <- x return y In an equation for `foo': foo x = do Just y <- x return y | 8 | Just y <- x | ^^^^^^^^^^^ }}} Given the enabled extensions, I'd expect {{{foo}}} to desugar as: {{{#!hs foo x = x >>= \v -> case v of Just y -> return y _ -> fail (fromString "pattern match error") }}} But looking at TcMatches.tcMonadFailOp it checks the fail operation (which is literally {{{fail}}}) takes an argument of type tyString (e.g. {{{[Char]}}}). One way around that would be to make the "fail-op" being passed around be {{{fail . fromString}}} if the appropriate extensions are enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16