November 2016 - ghc-tickets

[GHC] #12455: Compact Regions
by GHC 07 Dec '16

07 Dec '16

#12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime | Version: 8.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: -------------------------------------+------------------------------------- I'm going to use this task to keep track of what we still need to do around compact regions before 8.2.1, and so I have somewhere to hang diffs. Here's the current ToDo list: * compaction should be interruptible by GC, otherwise we block a multithreaded program while compacting (I know how to do this and have a prototype, just need to finish it). * Make it work with profiling * We should have an API that doesn't require specifying a size, just `compact :: NFData a => a -> IO (Compact a)` * libraries/compact/tests failures with `EXTRA_HC_OPTS="-debug -with- rtsopts=-DS"` * Do we need both `totalW` and `totalDataW`? It looks like one of them is redundant to me. * What happens if we try to compact something that refers to a large block? One larger than a megablock? * Improve comments -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12455> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12404: Document version availability for each language extension
by GHC 07 Dec '16

07 Dec '16

#12404: Document version availability for each language extension -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 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: -------------------------------------+------------------------------------- A certain amount of "historical" information about language extensions is of sufficient practical utility to deserve a place in the GHC documentation. I believe that the documentation for each language extension should include 1. The GHC version in which it first appeared. 2. Any major changes that have been made to the extension since the previous major-major version. For example, the GHC 8.x.x documentation for any given language extension should include any major changes to it since 7.0.1. At present, the only way I see to get this information is to dig through previous versions of the documentation and change logs, which is rather inefficient. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12224: Replace placeHolderPunRhs with a PlaceHolder value
by GHC 07 Dec '16

07 Dec '16

#12224: Replace placeHolderPunRhs with a PlaceHolder value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | 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: -------------------------------------+------------------------------------- At the moment `placeHolderPunRhs` is defined as {{{#!hs placeHolderPunRhs :: LHsExpr RdrName -- The RHS of a punned record field will be filled in by the renamer -- It's better not to make it an error, in case we want to print it when debugging placeHolderPunRhs = noLoc (HsVar pun_RDR) pun_RDR = mkUnqual varName (fsLit "pun-right-hand-side") }}} Rather use a type of `PostRn id (LHsExpr id)` where this is used. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11757: Turn on (and require) C99/C11 mode by default
by GHC 07 Dec '16

07 Dec '16

#11757: Turn on (and require) C99/C11 mode by default -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | 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: -------------------------------------+------------------------------------- GCC 5.x started defaulting to C99 (or rather gnu99 mode), while Clang has been defaulting to C99 (or even C11) for a bit longer, as has Apple's patched GCC. So we should try to consistently turn on (if needed) C99 (or C11) support for all compilers supported by GHC, and adapt the code-base to expect C99 compliance (which probably allows us to get rid of a couple of compat-CPP and make the C code more idiomatic and readable in the process...). GNU Autoconf provides a `AC_PROG_CC_C99` which figures out what's needed to have the compiler turn on C99 support, but we need to integrate that with out Requiring C99 will effectively rule out GCC 3.x (which is old enough that we can drop support for that), and possibly also GCC < 4.3 at some point (for reference, even Debian 6 Squeeze didn't have GCC 4.2 anymore), see also https://gcc.gnu.org/c99status.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11757> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11493: Merge compact normal forms
by GHC 07 Dec '16

07 Dec '16

#11493: Merge compact normal forms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 7.10.3 libraries/compact | 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: -------------------------------------+------------------------------------- Merge Yang and Campagna's [[Compact Normal Forms work|http://ezyang.com/compact.html]] There are several pieces to this, * Types and construction logic for compact regions (see Phab:D1264) * Serialization and fixup logic (currently also in Phab:D1264) * Striped allocator for heap sharing between processes (allocator in Phab:D1434, CNF support in Phab:D1435). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11493> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11557: Unbundle Cabal from GHC
by GHC 07 Dec '16

07 Dec '16

#11557: Unbundle Cabal from GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries | Version: 8.1 (other) | 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: -------------------------------------+------------------------------------- Recently, Duncan made it so that GHC proper does not depend on Cabal (so it is just ghc-pkg that is the user-facing executable which links against Cabal). We should now seriously consider unbundling Cabal from GHC, so that the default global database we provide does NOT include Cabal. Pros: * Distributions will be more likely to take point version releases to Cabal, as they no longer have to finesse updating Cabal without updating GHC as they have now * Stack is (improperly) coupling the version of Cabal they build with the release of GHC; while they should fix this, unbundling Cabal would also give them more flexibility with picking LTS packages. Cons: * Bootstrapping Cabal/cabal-install becomes modestly harder. Fortunately, cabal-install is already pretty obnoxious to bootstrap, so SOP is to just distribute binaries for this, in which case things are as easy as before. * We wouldn't be strictly adhering to the Cabal spec, which requires that the compiler always be able to build the Setup executable. * ghc-pkg would have to be statically linked -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10383: AArch64: get GHC Calling convention working
by GHC 07 Dec '16

07 Dec '16

#10383: AArch64: get GHC Calling convention working -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: aarch64 | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Building on AArch64 via the LLVM abckend has been working for some time. Its now time to get `("Unregisterised", "NO")` working as well. Enabling GHC calling convention can be done with this patch to `configure.ac`: {{{ diff --git a/configure.ac b/configure.ac index d5d9ab3..a11e5af 100644 --- a/configure.ac +++ b/configure.ac @@ -241,7 +241,7 @@ AC_SUBST(SOLARIS_BROKEN_SHLD) dnl ** Do an unregisterised build? dnl -------------------------------------------------------------- case "$HostArch" in - i386|x86_64|powerpc|arm) + i386|x86_64|powerpc|arm|aarch64) UnregisterisedDefault=NO ;; *) }}} but when building it this way, the stage2 compiler dies will `Illegal instructon`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #10332: AArch64 : divbyzero test fails
by GHC 07 Dec '16

07 Dec '16

#10332: AArch64 : divbyzero test fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Incorrect result Test Case: | at runtime testsuite/tests/rts/divbyzero.hs | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- On AArch64/Linux the test in `testsuite/tests/rts/divbyzero.hs` which is: {{{ main :: IO () main = print (5 `divInt` 0) }}} just prints "0" and exits with a zero status code. From the "ARMv8 Instriction Set Overview" document I found (wasn't able to find anything more recent): https://www.element14.com/community/servlet/JiveServlet/downloadBody/41836-… Section 3.6 says "There is no hardware check for “divide by zero”, but this check can be performed in the shadow of a long latency division. A divide by zero writes zero to the destination register." Looks like we need extra code to check for this, but not sure how to report it. Should probably look at what GCC and Clang do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel
by GHC 07 Dec '16

07 Dec '16

#10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Building GHC Test Case: | failed Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Compiling git HEAD (e02ef0e6d4eefa5f0) on AArch64 hardware using ghc-7.6.3 from Debian as the bootstrap compiler. LLVM is version 3.6. It fails with: {{{ "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fllvm \ -this-package-key paral_2NTMt5X9WUG6LNupBFIZti -hide-all-packages -i \ -ilibraries/parallel/. -ilibraries/parallel/dist-install/build \ -ilibraries/parallel/dist-install/build/autogen \ -Ilibraries/parallel/dist-install/build \ -Ilibraries/parallel/dist-install/build/autogen -Ilibraries/parallel/. \ -optP-include -optPlibraries/parallel/dist- install/build/autogen/cabal_macros.h \ -package-key array_BLJREAlFJ4zJ2kSDphVieY -package-key base_8gvrDSBdaidLA14EDtK6ja \ -package-key conta_1uqbEcrmZiO1C91Z8ePoyI -package-key deeps_Bw45clVBNVT4S1LLyUOPfh \ -Wall -feager-blackholing -XHaskell2010 -O -fllvm -no-user-package- db -rtsopts \ -odir libraries/parallel/dist-install/build \ -hidir libraries/parallel/dist-install/build \ -stubdir libraries/parallel/dist-install/build \ -dynamic-too -c libraries/parallel/./Control/Parallel/Strategies.hs \ -o libraries/parallel/dist- install/build/Control/Parallel/Strategies.o \ -dyno libraries/parallel/dist- install/build/Control/Parallel/Strategies.dyn_o libraries/parallel/ghc.mk:5: recipe for target 'libraries/parallel/dist-install/build/Control/Parallel/Strategies.o' failed make[1]: *** [libraries/parallel/dist- install/build/Control/Parallel/Strategies.o] Segmentation fault }}} It seems that `inplace/lib/bin/ghc-stage1` (which is working fine) is statically linked to all the Haskell libraries where as `inplace/lib/bin /ghc-stage2` is dynamically linked which would explain why stage1 works fine and stage2 segfaults. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11578: Fix GHC on AArch64/Arm64
by GHC 07 Dec '16

07 Dec '16

#11578: Fix GHC on AArch64/Arm64 --------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- Raising this to track discussion about GHC on Arm64. There is already some discussion in ticket #11206 (ARM is generally a disaster), but that ticket is about 32 bit Arm which is vastly different and is now mostly fixed. Information worth saving from #11206: * GHC 7.8.4 from Debian can build the ghc-8.0 branch, but cannot build HEAD because HEAD requires ghc-7.10 to build. * GHC 7.10 from Debian is broken because of an unfixed bug in llvm-3.5.2. * User @mfox reports that ghc-7.10 does build against llvm-3.7 and results in a compiler that can build HEAD. * That GHC 7.10 can be build against llvm-3.7 is a happy accident. Versions of GHC are usually locked to a specific version of LLVM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12