December 2018 - ghc-tickets

[GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm
by GHC 13 Dec '18

13 Dec '18

#15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This looks like a straightforward oversight. I am building my pure haskell LU solver under FreeBSD. I use the -fllvm compiler option because I need extra numerical performance. When I build, I get (this is the output from GitLab CI, which is in turn running 'stack build') {{{ Running with gitlab-runner 11.2.0 (35e8515d) on stacker.18clay.com a2111f63 Using Shell executor... Running on stacker.18clay.com... Fetching changes... Removing .stack-work/ HEAD is now at f8fe3b4 Use llvm60 on FreeBSD. From https://gitlab.18clay.com/software/luSolve f8fe3b4..c993a26 streamlined -> origin/streamlined Checking out c993a262 as streamlined... Skipping Git submodules setup $ stack build --pedantic luSolve-0.5: configure (lib) Configuring luSolve-0.5... luSolve-0.5: build (lib) Preprocessing library for luSolve-0.5.. Building library for luSolve-0.5.. [1 of 1] Compiling Numeric.LinearAlgebra.LUSolve ( src/Numeric/LinearAlgebra/LUSolve.hs, .stack- work/dist/x86_64-freebsd/Cabal-2.4.0.1/build/Numeric/LinearAlgebra/LUSolve.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-portbld-freebsd): Failed to lookup the datalayout for x86_64-unknown-freebsd; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","powerpc64le- unknown-linux","amd64-portbld-freebsd","arm-unknown-nto-qnx-eabi","i386 -apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64-apple- ios","i386-apple-ios","x86_64-apple-ios","aarch64-unknown-freebsd","armv6 -unknown-freebsd-gnueabihf","armv7-unknown-freebsd-gnueabihf"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package luSolve-0.5 using: /home/gitlab-runner/.stack/setup-exe-cache/x86_64-freebsd/Cabal- simple_mPHDZzAJ_2.4.0.1_ghc-8.6.1 --builddir=.stack- work/dist/x86_64-freebsd/Cabal-2.4.0.1 build lib:luSolve --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 ERROR: Job failed: exit status 1 }}} The bug seems simple. The compiler is looking for the datalayout for x86_64-unknown-freebsd; but what is available is amd64-portbld-freebsd. Is this just a simple naming error? The stack resolver was the cutting- edge nightly-2018-10-6; if it is a problem in their packaging rather than ghc itself I will file a report with them (though ghc did panic here, and as the breath ebbed from its ASTs and light faded from the code generator, it pleaded that a bug report be filed). I've attached the .cabal file in case it helps. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[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] #15774: SIGKILL only reports backtrace for one capability
by GHC 13 Dec '18

13 Dec '18

#15774: SIGKILL only reports backtrace for one capability -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime | Version: 8.6.1 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: -------------------------------------+------------------------------------- SIGKILL is intended to mirror the same signal's functionality provided by the JVM. That is, provide a snapshot of a processes' state in the form of backtraces on stderr. However, GHC's implementation currently only prints a backtrace for a single, arbitrary thread. This should be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #15768: Using oneshot kqueue() on macOS
by GHC 13 Dec '18

13 Dec '18

#15768: Using oneshot kqueue() on macOS -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.6.1 Libraries | Keywords: KQueue, | Operating System: MacOS X oneshot, parallel build | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Oneshot kqueue() is disabled on macOS due to https://ghc.haskell.org/trac/ghc/ticket/7651 Recall that the paper "Mio: A High-Performance Multicore IO Manager for GHC" says: "Mio also uses kqueue on OS X, since Darwin, the foundation for Apple’s OS X, is a variant of BSD. However, we encountered problems running parallel builds of the GHC compiler using Mio as described above. We have been unable to uncover the underlying source of the problem to our satisfaction. However, several Internet discussions suggest that the implementation of kqueue and pipe on OS X are unstable. We were able to resolve the observed prob- lems on OS X by avoiding the use of one-shot mode on OS X, instead unregistering events after they are delivered, and by send- ing wakeup writes to a pipe monitored by the dispatcher threads’ kqueue instances on every event registration. With these changes, the behavior on OS X, including parallel builds of GHC, has been stable." Now the serious bug on KQueue has been fixed: - https://ghc.haskell.org/trac/ghc/ticket/13903 - https://phabricator.haskell.org/D3692 So, I guess it's time to use oneshot on macOS. A patch is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15768> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15843: Tuple sections can't be quoted
by GHC 13 Dec '18

13 Dec '18

#15843: Tuple sections can't be quoted -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 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: -------------------------------------+------------------------------------- There are quite a few forms that are not supported in template haskell quotes. It seems that it would be at least a good warm up patch to add support for tuple sections which you can do simply by desugaring to a lambda and the normal tuple constructor. {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TupleSections #-} module Foo where foo = [|| (,5) ||] }}} 1. Modify `DsMeta.repE` to handle tuple sections. You can desugar `(,5) => `\x -> (x, 5)`. 2. Add the above test to the test suite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function
by GHC 13 Dec '18

13 Dec '18

#1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 4258 | Blocking: Related Tickets: 8326 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1498#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications?
by GHC 13 Dec '18

13 Dec '18

#15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- As a part of the work on moving some fragile analyses from Core to final phase before code gen (#9718) I found an unused analysis in CoreToStg which basically assigns each binder this: {{{ data StgBinderInfo = NoStgBinderInfo | SatCallsOnly -- All occurrences are *saturated* *function* calls -- This means we don't need to build an info table and -- slow entry code for the thing -- Thunks never get this value }}} The idea is , as mentioned in the comment, for `SatCallsOnly` binder we can avoid generating code for slow entry. However this is currently not used (see Phab:D5232), and this ticket is to decide whether to use or remove this. I found these comments in `StgCmmClosure` that explains how this became unused and how it was used before: {{{ ----------------------------------------------------------------------------- -- staticClosureRequired ----------------------------------------------------------------------------- {- staticClosureRequired is never called (hence commented out) SimonMar writes (Sept 07) It's an optimisation we used to apply at one time, I believe, but it got lost probably in the rewrite of the RTS/code generator. I left that code there to remind me to look into whether it was worth doing sometime {- Avoiding generating entries and info tables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ At present, for every function we generate all of the following, just in case. But they aren't always all needed, as noted below: [NB1: all of this applies only to *functions*. Thunks always have closure, info table, and entry code.] [NB2: All are needed if the function is *exported*, just to play safe.] * Fast-entry code ALWAYS NEEDED * Slow-entry code Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) we're in the parallel world and the function has free vars [Reason: in parallel world, we always enter functions with free vars via the closure.] * The function closure Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) if the function has free vars (ie not top level) Why case (a) here? Because if the arg-satis check fails, UpdatePAP stuffs a pointer to the function closure in the PAP. [Could be changed; UpdatePAP could stuff in a code ptr instead, but doesn't seem worth it.] [NB: these conditions imply that we might need the closure without the slow-entry code. Here's how. f x y = let g w = ...x..y..w... in ...(g t)... Here we need a closure for g which contains x and y, but since the calls are all saturated we just jump to the fast entry point for g, with R1 pointing to the closure for g.] * Standard info table Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) the function has free vars (ie not top level) NB. In the sequential world, (c) is only required so that the function closure has an info table to point to, to keep the storage manager happy. If (c) alone is true we could fake up an info table by choosing one of a standard family of info tables, whose entry code just bombs out. [NB In the parallel world (c) is needed regardless because we enter functions with free vars via the closure.] If (c) is retained, then we'll sometimes generate an info table (for storage mgr purposes) without slow-entry code. Then we need to use an error label in the info table to substitute for the absent slow entry code. -} staticClosureRequired :: Name -> StgBinderInfo -> LambdaFormInfo -> Bool staticClosureRequired binder bndr_info (LFReEntrant top_level _ _ _ _) -- It's a function = ASSERT( isTopLevel top_level ) -- Assumption: it's a top-level, no-free-var binding not (satCallsOnly bndr_info) staticClosureRequired binder other_binder_info other_lf_info = True -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14