February 2018 - ghc-tickets

[GHC] #14654: Nofib: Strip called without .exe extension resulting in errors.
by GHC 08 Feb '18

08 Feb '18

#14654: Nofib: Strip called without .exe extension resulting in errors. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 8.2.2 benchmark suite | Keywords: nofib, | Operating System: Windows windows | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ ... ==nofib== bernouilli: size of Main.o follows... text data bss dec hex filename 8080 1632 0 9712 25f0 Main.o ==nofib== bernouilli: time to link bernouilli follows... <<ghc: 27269080 bytes, 11 GCs, 471856/801256 avg/max bytes residency (2 samples), 32M in use, 0.000 INIT (0.000 elapsed), 0.016 MUT (1.134 elapsed), 0.016 GC (0.015 elapsed) :ghc>> C:\ghc\msys64\mingw64\bin\strip.exe: 'bernouilli': No such file make[2]: *** [../../mk/target.mk:96: size] Error 1 make[2]: Target 'all' not remade because of errors. Finished making all in bernouilli: 0 ... }}} I assume strip looks for a file, not an executable. And as such requires the full name "foo.exe" instead of just "foo". Make sees this error and stops before the actual benchmark is run. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14778: FunDep origin not correctly attributed
by GHC 08 Feb '18

08 Feb '18

#14778: FunDep origin not correctly attributed -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: FunDeps | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `TcInteract.improveTopFunEqs` we do not give the derived constraints an origin of `FunDepOrigin`. As a result, `dropDerivedSimples` will discard even an insoluble constraint arising from a fundep. In contrast class instance fundeps do have `FunDepOrigin` and are kept. This is at least inconsistent. And we get less good error messages. Shows up in tests `T13651, `TR8450`, `T13506`, `T14325`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14778> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12262: Binary output is not deterministic
by GHC 07 Feb '18

07 Feb '18

#12262: Binary output is not deterministic -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- The goal of DeterministicBuilds (#4012) was to get ABI-compatible binaries given the same sources, flags and the environment. There's a stronger goal of getting bit-for-bit identical binaries and this ticket will track that. Known causes of binary nondeterminism: * Unique comparison * Uniques converted to strings for symbol names * everything else from #4012 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14774: Recusive superclass epansion is over-keen
by GHC 07 Feb '18

07 Feb '18

#14774: Recusive superclass epansion is over-keen -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Consider this, with `RecursiveSuperClasses`: {{{ class C a => D a where cop :: a -> a class D a => C a where dop :: a -> a g :: C a => a -> Bool g x = g x f :: C a => a -> Bool f x = g x }}} When we compile this we get {{{ f = \ (@ a_aXf) ($dC_aXh :: C a_aXf) (eta_B1 :: a_aXf) -> g @ a_aXf (Foo.$p1D @ a_aXf (Foo.$p1C @ a_aXf $dC_aXh)) eta_B1 }}} Notice the ridiculous double superclass selection from `$dC_aXh`. It's not wrong, just stupid! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14772: Keep Role Annotations in the renamed syntax tree
by GHC 06 Feb '18

06 Feb '18

#14772: Keep Role Annotations in the renamed syntax tree -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | 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: -------------------------------------+------------------------------------- Currently role annotations are present in the parsed representation, but missing from the renamed version of the syntax tree. GHC should keep them instead. I found no evidence that this would be intended, we even have `rnRoleAnnots` that should return the renamed annotations. Keeping role annotations would help tooling to be consistent. For example, renaming the datatype should also rename its occurrence in the role annotation. Minimal example: A.hs {{{#!hs module A where import B data A x = A B }}} B.hs {{{#!hs module B where import {-# SOURCE #-} A data B = B (A ()) }}} A.hs-boot {{{#!hs {-# LANGUAGE RoleAnnotations #-} module A where type role A phantom -- the role annotation is needed here data A x }}} When inspecting the representation using the GHC API, the role is present in the parsed representation: {{{ module A where -- Parsed module type role A phantom data A x }}} But missing from the renamed one: {{{ (data A x, [import (implicit) Prelude], Nothing, Nothing) -- RenamedSource }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14772> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #481: Recompilation check fails for TH
by GHC 06 Feb '18

06 Feb '18

#481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: #14769 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * related: => #14769 Comment: I believe I have found a bug with the current implementation of the `[TH]`/`RecompBecause "TH"` check: It doesn't work when the build is interrupted. See #14769 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/481#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12685: getNumProcessors semantics dont match documentation
by GHC 06 Feb '18

06 Feb '18

#12685: getNumProcessors semantics dont match documentation ----------------------------------------+--------------------------------- Reporter: Llgn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hi, The documentation of getNumProcessors says : "Returns the number of CPUs that the machine has", but it is true only for program compiled with -threaded option. https://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-Conc- Sync.html#v:getNumProcessors I guess the documentation is just misleading. Or is it a bug ? Regards -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14717: Hidden package hints no longer display
by GHC 06 Feb '18

06 Feb '18

#14717: Hidden package hints no longer display -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This started as a mailing list thread: https://mail.haskell.org/pipermail /haskell-cafe/2018-January/128485.html. Dan Burton demonstrated a reproduction without any build tool. With GHC 8.0.2, when you try to use a module from a hidden package, you get an error message with a helpful hint to add the package to the build- depends. With GHC 8.2.2 (and I believe 8.2.1), it appears that this hint is no longer displayed. To demonstrate, I'll copy Dan's repro: {{{ $ cat Main.hs module Main where import Data.Map main = putStrLn "It compiles" $ ghc-pkg list containers /usr/local/Cellar/ghc/8.2.2/lib/ghc-8.2.2/package.conf.d containers-0.5.10.2 $ ghc --make -hide-all-packages -package base Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:2:1: error: Could not find module ‘Data.Map’ Use -v to see a list of the files searched for. | 2 | import Data.Map | ^^^^^^^^^^^^^^^ $ ghc --make -hide-all-packages -package base -package containers Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14693: Computing imp_finst can take up significant amount of time
by GHC 06 Feb '18

06 Feb '18

#14693: Computing imp_finst can take up significant amount of time -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Type checker) | 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 profiled a build of a production code base with thousands of modules and merging `imp_finsts` [1] from different imports came up on top taking up 9% of total compile time. I made a synthetic test case to reproduce the issue (see attached `generateModules`). The test case is basically multiple layers of modules where each module defines a type family instance through deriving Generic. The problem is quite obvious, `unionLists` is quadratic and `imp_finsts` just keeps growing with the size of the code base. [1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/typech… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14637: Simplifier Ticks Exhausted when compiling with profiling
by GHC 06 Feb '18

06 Feb '18

#14637: Simplifier Ticks Exhausted when compiling with profiling -------------------------------------+------------------------------------- Reporter: cfhammill | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Hi GHC devs, I've run into a problem with the Frames library, I can compile a simple example using stack without executable profiling enabled, but when I enable profiling I get the simplifier ticks exhausted error. I've tried using -fsimpl-tick-factor=1000 to no avail. I've attached the stack config, cabal file, haskell code, two csv files, and the simplifier dump. Any help would be appreciated. Chris -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22