June 2018 - ghc-tickets

[GHC] #14709: Extend the plugin mechanism to access program representation
by GHC 03 Jun '18

03 Jun '18

#14709: Extend the plugin mechanism to access program representation -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 8.2.2 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: https://phabricator.haskell.org/D4342| https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal -------------------------------------+------------------------------------- This would enable development tools to access the GHC representation in the pre-existing build environment. By the inversion of control, the tool developers don't need to decide which Haskell modules have to be processed and with what configuration, because the normal build procedure could be invoked by the user with plugin flags specifying what tools to invoke. The plan is described in more details at [https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal Extended Plugins Proposal] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14324: Consider deprecating STM invariant mechanism
by GHC 03 Jun '18

03 Jun '18

#14324: Consider deprecating STM invariant mechanism -------------------------------------+------------------------------------- Reporter: bgamari | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- fryguybob and I were recently discussing the STM invariant mechanism. This mechanism is, presumably, intended to expose problems from odd interleavings of transactions. However, fryguybob pointed out that the implementation currently takes so many locks that it very likely prevents these odd interleavings from occurring. In addition, * the implementation doesn't handle nested STM invariants correctly (#7930) * the locking behavior of the implementation was, until very recently, utterly wrong (#14310) * the feature introduces quite a bit of complexity in the RTS * the interface has essentially no users, as evidenced by a Hackage search and the fact that #14310 went unnoticed for years All of this raises the question: Is the STM invariants feature really where we want to spend our complexity budget? Perhaps it is time for this feature to quietly pass (after an appropriate deprecation period, of course). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #77: Compiling with -O yields broken .hc file
by GHC 02 Jun '18

02 Jun '18

#77: Compiling with -O yields broken .hc file --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.04 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Ben Gamari <ben@…>): * failure: => None/Unknown Comment: In [changeset:"a122d4fdd0a5858e44f9d3be90a258903e0288b2/ghc" a122d4fd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a122d4fdd0a5858e44f9d3be90a258903e0288b2" rts: Rip out support for STM invariants This feature has some very serious correctness issues (#14310), introduces a great deal of complexity, and hasn't seen wide usage. Consequently we are removing it, as proposed in Proposal #77 [1]. This is heavily based on a patch from fryguybob. Updates stm submodule. [1] https://github.com/ghc-proposals/ghc-proposals/pull/77 Test Plan: Validate Reviewers: erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14310 Differential Revision: https://phabricator.haskell.org/D4760 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/77#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14310: Assertion triggered by STM invariant.
by GHC 02 Jun '18

02 Jun '18

#14310: Assertion triggered by STM invariant. --------------------------------------+---------------------------------- Reporter: mbw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- The program attached depends on the async and stm packages. It will push some numbers through a pipeline, while keeping track of some state. If invoked without arguments, the program will output the state and result of each iteration. If invoked via "./repro check", an STM invariant will be installed when the state is initialized. This invariant will cause the program to a) hangup, presumably due to a livelock, if the program has been compiled without "-debug", b) crash with the following error: "internal error: ASSERTION FAILED: file rts/RaiseAsync.c, line 1001", if the "-debug" flag has been used for compilation. The latter case also happens with GHC 8.0.2: "internal error: ASSERTION FAILED: file rts/RaiseAsync.c, line 997". Furthermore, this problem only occurs if the program is compiled using the additional flags "-rtsopts -threaded -with-rtsopts=-N". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #15186: ghc 8.4.2 panic in profiling build
by GHC 02 Jun '18

02 Jun '18

#15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building our crucible-llvm library (https://github.com/GaloisInc/crucible) with profiling enabled, we encounter the following: {{{ [19 of 21] Compiling Lang.Crucible.LLVM.Translation ( src/Lang/Crucible/LLVM/Translation.hs, dist/build/Lang/Crucible/LLVM/Translation.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.2 for x86_64-unknown-linux): isUnliftedType r_a4IqS :: TYPE rep_a4IqR Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Procedure to reproduce: {{{ $ git clone https://github.com/GaloisInc/crucible $ cd crucible/crucible-llvm $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ cabal --version cabal-install version 2.0.0.1 compiled using version 2.0.1.0 of the Cabal library $ cabal configure --enable-library-profiling $ cabal build }}} Note: the llvm-pretty dependency on Hackage is not compatible with GHC 8.4.2; use the latest from the github repo at http://github.com/elliottt /llvm-pretty. The crucible and what4 dependencies come from sibling subdirectories in the same crucible checkout. This builds successfully when using GHC 8.2.2 instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 02 Jun '18

02 Jun '18

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer 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 sgillespie): What specific message should we show? I was thinking: {{{ Prelude> :m + Control.Monad.Random <no location info>: error: Could not find module ‘Control.Monad.Random’ It is a member of the package ‘MonadRandom-0.5.1-1421RgpXdhC8e8UI7D3emA’ which is unusable due to missing dependencies: fail-4.9.0.0-BAHmj60kS5K7NVhhKpm9J5 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15193: QSem makes nonsense claim
by GHC 02 Jun '18

02 Jun '18

#15193: QSem makes nonsense claim -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It says waiting threads are serviced in FIFO order. This isn't really a meaningful statement. What does "first in" mean? Furthermore, the first step in `waitQSem` is `takeMVar`, which provides no ordering guarantees whatsoever. As far as I can tell, there's no meaningful difference between a thread waiting a long time in the queue and I've waiting a long time to get into the queue. So I think we probably want to weaken the promise here to match the `MVar` fairness guarantee: if a thread waits on a `TSem`, and that `TSem` continues to be signaled, then the thread will eventually proceed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage
by GHC 02 Jun '18

02 Jun '18

#12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ----------------------------------------+--------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This seems to be a build regression from ghc-8.0.1. The ghc.1 manpage was not installed for the 8.0.2 RC1 build. I reported this in mail earlier and unfortunately in the meantime lost the buildlogs on Fedora Copr, but since the upstream binary tarballs for Linux also don't seem to contain ghc.1 either it should not be too hard to reproduce. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15210: Use ByteStrings for strings that don't use FastString's features
by GHC 02 Jun '18

02 Jun '18

#15210: Use ByteStrings for strings that don't use FastString's features -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: performance, | Operating System: Unknown/Multiple strings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15157 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The first two candidates that I have in mind are SourceText and StringLiteral's sl_fs field. There might be a point in creating a simple wrapper for UTF8-encoded ByteString. HsDocString could use that one too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2
by GHC 01 Jun '18

01 Jun '18

#13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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 notice that buildbots were having a hard-time building GHC 8.2 snapshots... so I investigated... One thing that jumped at me was the memory usage while compiling DynFlags which is the worst memory-offender with 4777MiB of resident size: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.2.0.201 70313 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen - icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompi ler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -pa ckage-id directory-1.3.0.2 -package-id process-1.4.3.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.4.1 -package-id time-1.8.0.1 -package-id containers-0.5.10.2 -package-id array-0.5.1.2 -package-id fil epath-1.4.1.1 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc- boot-8.2.0.20170313 -package-id ghc-boot-th-8.2.0.20170313 -package-id ghci-8.2.0.20170 313 -package-id hoopl-3.10.2.2 -package-id unix-2.7.2.1 -package-id terminfo-0.4.0.2 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-t iming -O2 -no-user-package-db -rtsopts -Wnoncanonical-monad- instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/main/DynFlags.hs -o compiler/stage2/build/DynFlags.o -dyno compiler/stage2/build/DynFlags.dyn_o }}} {{{ <<ghc: 63014533832 bytes, 4032 GCs, 395131448/1973969928 avg/max bytes residency (24 samples), 4777M in use, 0.000 INIT (0.000 elapsed), 32.207 MUT (33.221 elapsed), 26.682 GC (26.685 elapsed) :ghc>> }}} Then I did two clean full builds of the `ghc-8.0` and `ghc-8.2` branch, and collected the -Rghc-timings output into simple 3-columns .csv files; Here's are the respective top-12 entries for GHC 8.0 and GHC 8.2 respectively: {{{#!bash $ sort -t, -k2n build.80.csv | tail -n12 "inplace/bin/ghc-stage1",560,compiler/stage2/build/TcRnDriver.o "inplace/bin/ghc-stage1",572,compiler/stage2/build/TcRnDriver.p_o "inplace/bin/ghc-stage1",572,compiler/stage2/build/TcSplice.o "inplace/bin/ghc-stage1",847,compiler/stage2/build/OptCoercion.p_o "/opt/ghc/bin/ghc",979,compiler/stage1/build/OptCoercion.o "/opt/ghc/bin/ghc",1036,compiler/stage1/build/DynFlags.o "/opt/ghc/bin/ghc",1040,compiler/stage1/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1119,compiler/stage2/build/DynFlags.p_o "inplace/bin/ghc-stage1",1123,compiler/stage2/build/DynFlags.o "inplace/bin/ghc-stage1",1178,compiler/stage2/build/OptCoercion.o "inplace/bin/ghc-stage1",1233,compiler/stage2/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1282,compiler/stage2/build/X86/CodeGen.p_o }}} {{{#!bash $ sort -t, -k2n build.82.csv | tail -n12 "inplace/bin/ghc-stage1",891,compiler/stage2/build/CmmParse.p_o "/opt/ghc/bin/ghc",1053,compiler/stage1/build/DynFlags.o "/opt/ghc/bin/ghc",1058,compiler/stage1/build/OptCoercion.o "inplace/bin/ghc-stage1",1284,compiler/stage2/build/HsExpr.p_o "inplace/bin/ghc-stage1",1313,compiler/stage2/build/HsExpr.o "/opt/ghc/bin/ghc",1394,compiler/stage1/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1495,compiler/stage2/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1605,compiler/stage2/build/X86/CodeGen.p_o "inplace/bin/ghc-stage1",1620,compiler/stage2/build/OptCoercion.o "inplace/bin/ghc-stage1",1733,compiler/stage2/build/OptCoercion.p_o "inplace/bin/ghc-stage1",3989,compiler/stage2/build/DynFlags.p_o "inplace/bin/ghc-stage1",4777,compiler/stage2/build/DynFlags.o }}} What's apparent from this data: - GHC stage0 (which was GHC 8.0.2) is able to build DynFlags.o for GHC 8.0 and GHC 8.2 w/ roughtly the same amount of max resident memory, i.e. 1 GiB - **GHC 8.2 stage1 however needs 4 times the amount of memory more than GHC 8.0 to build the same `DynFlags.hs` module!** -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 59