September 2016 - ghc-tickets

[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

[GHC] #10962: Improved arithmetic primops
by GHC 07 Dec '16

07 Dec '16

#10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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://ghc.haskell.org/trac/ghc/wiki/ImprovedArithmeticPrimops -------------------------------------+------------------------------------- See the todo list on the wiki page. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8224: Excessive system time -- new IO manager problem?
by GHC 07 Dec '16

07 Dec '16

#8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: IO Manager, | Operating System: Linux System Time | Type of failure: Runtime Architecture: x86_64 (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- This is an issue that came to light when testing the patches on #910. You can see some of the numbers there. Basically, recent GHC HEAD builds, running a large number of threads blocked on MVars will result in burning a lot of system time. The attached file provides a mediocre reproducer. With it, you can see that building with HEAD as of Aug 31st and running with `-RTS -N32` will result in around 200ms system time, whereas GHC 7.6.3 spends about 30ms in system time. This shows the disparity, but the result is not that egregious. A more noticeable example is on ticket #910, where when running on 31 threads, there is an 8 minutes of system time for 17 minutes of user time, and yet at one thread that system time drops to under two seconds! {{{ 1 thread: real 1m20.028s user 1m17.921s sys 0m1.768s 31 threads: real 1m27.445s user 17m0.314s sys 8m0.175s }}} It needs to be determined whether this system time is a result of the parallel compilation patches on #910, or whether it is a new problem with the runtime system, and in particular with the parallel IO manager. I am inclined to believe that compiling in parallel involves extra IO (repeatedly reading interface files?), but not eight minutes of it!! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40