December 2018 - ghc-tickets

[GHC] #16056: Hadrian failure: Values have changed since being depended upon
by GHC 16 Dec '18

16 Dec '18

#16056: Hadrian failure: Values have changed since being depended upon -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Hadrian build on Windows appears to fail with: {{{ /--------------------------------------------------------------------------\ | Successfully built program 'haddock' (Stage2). | | Executable: _build/stage2/bin/haddock.exe | | Program synopsis: A documentation-generation tool for Haskell libraries. | \--------------------------------------------------------------------------/ shakeArgsWith 0.002s 0% Function shake 0.035s 0% Database read 0.003s 0% With database 0.001s 0% Running rules 2815.075s 99% ========================= Pool finished (9025 threads, 8 max) 0.001s 0% Lint checking 0.641s 0% Total 2815.758s 100% Lint checking error - 520 values have changed since being depended upon: Key: _build/stage1/gmp/objs/zero_p.o Old: (Just File {mod=0x88773CC6,size=0x2EA,digest=0xACFF03E6},"") New: File {mod=0x8C6CE092,size=0x2EA,digest=0xACFF03E6} Key: _build/stage1/gmp/objs/zero.o Old: (Just File {mod=0x88DC1816,size=0x2F8,digest=0x586B32DC},"") New: File {mod=0x8CA46DC3,size=0x2F8,digest=0x586B32DC} Key: _build/stage1/gmp/objs/xor_n.o Old: (Just File {mod=0x88D86EC7,size=0x1DF,digest=0xFBB5353},"") New: File {mod=0x8CA1D672,size=0x1DF,digest=0xFBB5353} ... }}} All paths listed are in `_build/stage1/gmp` and all changed only in their mtime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15562: `-XStrict -XNoStrict` is not neutral
by GHC 14 Dec '18

14 Dec '18

#15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I assumed we already had a ticket about this, but it appears we have not. I'm not saying this is a necessarily a bug in the implementation; but we should make sure this is properly documented in the user's guide, and ideally justify why it's done this way rather than the alternatives: As described in StrictPragma, > `Strict` implies `StrictData` Currently however the inverse case does not hold, i.e. `NoStrict` does *not* imply `NoStrictData` This has the surprising property (assuming these were left-most flags on the CLI) that - `-XStrict -XNoStrict` == `-XStrictData` - `-XStrictData -XNoStrict` == `-XStrictData` However, if `-XNoStrict` was to naively imply `-XNoStrictData`, we'd have the properties - `-XStrict -XNoStrict` == *id* - `-XStrictData -XNoStrict` == *id* This might be a bit less confusing; another variant would be - `-XStrict -XNoStrict` == *id* - `-XStrictData -XNoStrict` == `-XStrictData` Btw, I'm not sure what the following means: - `-XStrict -XNoStrictData` == ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16049: Add a warning flag that warns when a datatype could be a newtype
by GHC 14 Dec '18

14 Dec '18

#16049: Add a warning flag that warns when a datatype could be a newtype -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Keywords: flags | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- More often than not, `newtype` is desirable over `data` if a type has a single field. I propose a warning flag `-Wdata-could-be-newtype` that would warn users if a data type they've defined has a single field (and thus could be a `newtype`). It would need to be explicitly enabled (and of course enabled by `-Weverything`). An example (relevant Trac ticket: #15995): {{{#!hs -- Control.Concurrent.QSem: data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()])) }}} There's a bang pattern on its single field, but this could just be supplied at every pattern-matching site of `QSem`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15882: :load in ghci should expose the entire namespace of a module
by GHC 14 Dec '18

14 Dec '18

#15882: :load in ghci should expose the entire namespace of a module -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: GHCi | Version: 8.6.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: -------------------------------------+------------------------------------- When using "import" in ghci, only exported names are available. When using :load, the use case is typically for "toying around" or testing a module. In that case, the export list restrictions are much less useful. There is currently no way to just expose the same namespace context of the code in a module in ghci, and having :load do that sounds like it would be very useful. The ordinary "import" namespace semantics are after all available too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15882> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15973: Int used to represent target integer literals
by GHC 14 Dec '18

14 Dec '18

#15973: Int used to represent target integer literals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 numerous places within GHC where we use `Int` to represent a constant literal for the target. For instance, `CmmUtils` has the following: {{{#!hs -- XXX: should really be Integer, since Int doesn't necessarily cover -- the full range of target Ints. mkIntCLit :: DynFlags -> Int -> CmmLit mkIntCLit dflags i = CmmInt (toInteger i) (wordWidth dflags) }}} This could go very wrong when cross-compiling from a 32-bit machine to a 64-bit target. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile
by GHC 14 Dec '18

14 Dec '18

#15929: Explore whether adding XRay attributes to LLVM IR is worthwhile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- LLVM has support for XRay which is a tracing framework developed by Google. It might be possible to add the relevant function attributes to the IR we generate to get access to detailed traces which can be analysed using existing tooling. https://llvm.org/docs/XRay.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15929> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #16007: Implement `-Os`
by GHC 14 Dec '18

14 Dec '18

#16007: Implement `-Os` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #16005 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Popular C compilers like GCC or clang allow to optimise for binary size. Since there are multiple ways in which GHC trades code size for faster programs, it might make sense to follow suit. This ticket is for tracking which optimisations/hacks in the compiler might be affected, as well as Feel free to add items to the following list: - +0.1% increase in code size due to known calls instead of re-using generic apply thunks in #16005 - -0.1% due to `-fstg-lift-lams` #9476 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16010: Broken Link in Data.OldList
by GHC 13 Dec '18

13 Dec '18

#16010: Broken Link in Data.OldList -------------------------------------+------------------------------------- Reporter: supersven | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: ⊥ Component: | Version: 8.7 libraries/base | 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: -------------------------------------+------------------------------------- In `Data.OldList`: {{{ #!haskell infix 5 \\ -- comment to fool cpp: https://www.haskell.org/ghc/docs/latest/html/users_guide/options- phases.html#cpp-string-gaps }}} Looks like the URL changed to: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/phases.html #cpp-and-string-gaps -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7