January 2014 - ghc-tickets

[GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks
by GHC 14 Jan '14

14 Jan '14

#8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------+---------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: clang | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- I'm using GHC 7.6.3 with clang/wrapper (setting is modified). This GHC cannot build GHC head with integer-gmp: {{{ checking for assembler byte directive... .byte checking how to define a 32-bit word... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) configure: error: cannot determine how to define a 32-bit word make[1]: *** [libraries/integer-gmp/gmp/gmp.h] Error 1 make: *** [all] Error 2 }}} With integer-simple, build is OK. For more information, please see http://d.hatena.ne.jp/kazu- yamamoto/20131028/1382921924 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 14 Jan '14

14 Jan '14

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Fixed the `transform` issue (when analysing a complex case expression where we do the scrunitee first to feed nested CPR information into the pattern match variable, I was not making sure that the case binder gets at least a flat CPR property, even if the scrunitee has none), and we are finally where Simon expected nested CPR to be: No increased allocations any more (or at least none that are not surpassed by the gains). Still a very small effect, though. {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi +0.3% -0.1% 0.00 0.00 +0.0% awards +0.3% -0.1% 0.00 0.00 +0.0% compress2 +0.6% -0.8% 0.11 0.11 -8.0% fibheaps +0.3% -0.3% 0.03 0.03 +0.0% gamteb +0.4% -0.2% 0.04 0.04 +0.0% grep +0.3% -0.1% 0.00 0.00 +0.0% hpg +0.4% -3.0% 0.13 0.13 +0.0% infer +0.3% -1.2% 0.03 0.03 +0.0% k-nucleotide +0.2% -6.9% -0.7% -0.5% +0.0% maillist +0.4% -0.8% 0.04 0.04 -4.2% mkhprog +0.4% -0.3% 0.00 0.00 +0.0% pic +0.3% -0.7% 0.00 0.00 +0.0% pretty +0.4% -0.1% 0.00 0.00 +0.0% rfib +0.3% -0.2% 0.01 0.01 +0.0% scc +0.3% -0.1% 0.00 0.00 +0.0% spectral-norm +0.4% -0.1% +0.0% +0.0% +0.0% sphere +0.4% -4.7% 0.04 0.04 +0.0% symalg +0.3% -0.1% 0.01 0.01 +0.0% tak +0.3% -0.3% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min +0.2% -6.9% -5.3% -27.3% -8.0% Max +0.7% +0.0% +1.4% +1.4% +50.0% Geometric Mean +0.3% -0.2% -0.7% -2.3% +0.2% }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell
by GHC 14 Jan '14

14 Jan '14

#7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): The classification of predicates is done by `classifyPredType`, in the Type module. From the definition of that function, any predicate not headed by a class, equality predicate, or tuple is "irreducible". Examples of these include predicates headed by type families or predicates headed by variables. Both of these possibilities require `ConstraintKinds`. Here is a full program that exhibits the problem: {{{ {-# LANGUAGE TemplateHaskell, PolyKinds, ConstraintKinds #-} module Irred where import Language.Haskell.TH data Proxy a = Proxy foo :: a b => Proxy a -> b foo = undefined $( do info <- reify 'foo reportWarning (show info) return [] ) }}} GHC 7.6.3 reports {{{ Can't represent irreducible predicates in Template Haskell: a b }}} Producing this error was admittedly harder than I thought. It turns out that !TcSplice and !DsMeta take rather different routes to translating into the TH syntax. (This is, of course, because !TcSplice is translating from Core while !DsMeta is translating from Haskell.) Only !TcSplice checks the classification of predicates. Using a TH quote with an "irreducible" predicate produces a `ClassP`, even on a type like `foo`'s type, above. I hope this helps! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7021#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell
by GHC 13 Jan '14

13 Jan '14

#7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by yoeight): Replying to [comment:9 goldfire]: > This looks nice -- I can easily believe it works. Here is some feedback I have on the code: > > * I would want to see this handle `IrredPred` predicates, as well as tuples. That way, synonyms built with !ConstraintKinds would be fully supported by TH. I don't think this should be too much work beyond what you've already done. Do you have any pointer on what irreducible predicates are please ? If it's possible, could you provide a code sample that triggers irreducible predicate TH error ? > > * I still think a change to !DsMeta is warranted. For example, I would imagine code like `[t| (Show a, (Read a, Num a)) => a -> a |]` would fail to compile, even though TH would now be able to represent such a predicate. You were right, I got an error when compiling your code. I think we should use it in a new test case in order to increase code coverage. What do you think ? > > * The functions `classP` and `equalP` in the `Lib` module are meant to echo the constructors of `Pred`. I would say that, now that `Pred` is a synonym, `classP` and `equalP` should be removed. (It took me a while to understand why all those functions are there in `Lib` -- the answer is that !DsMeta is ''much'' easier to write with those functions there.) Leaving `classP` and `equalP` doesn't cause anyone any real harm, but it would just be a small wart on the design that could easily be eliminated. > > * Along similar lines, you will probably find that you need an `equalityT` function in `Lib` when updating !DsMeta. > > * It looks like you left the old `Pred` commented-out in `Syntax`. > > * While it is probably too late now (and I don't think worth going back to fix), it's best to do whitespace changes in separate commits from substantive changes. Perhaps before editing a new file, removing the trailing whitespace, make a commit, and then go back and to the real changes. You can always then rebase at the end of your session to lump together all the whitespace commits. > I agree. The thing is, I have `(add-to-list 'write-file-functions 'delete- trailing-whitespace)` in my `.emacs`. I didn't notice until I posted my patches. > Continued thanks for working on this! Thanks for your feedback ! Yorick -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7021#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4101: Primitive constant unfolding
by GHC 13 Jan '14

13 Jan '14

#4101: Primitive constant unfolding --------------------------------------------+--------------------------- Reporter: malosh | Owner: schyler Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): So one thing that also maybe needs to be done is add proper way of tracking NAN and other exception values (and coding them correctly too) as a prereq for constant evaluation -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4101#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4101: Primitive constant unfolding
by GHC 13 Jan '14

13 Jan '14

#4101: Primitive constant unfolding --------------------------------------------+--------------------------- Reporter: malosh | Owner: schyler Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): @schyler please please be very careful about anything regarding evaluating floating point, I think before we add optimizations and constant propagation for floating point computations we really need to enrich GHC's internal data model of floating point. a Naive constant progagation alg will not be correct for floating point. I'd in fact argue that any constant propagtion stuff first needs that internal model cleaned up first to be correct. Relatedly: many floating point libs do a lot of work that exploits the specific structure of floating point, for example edward kmett's compensated lib http://hackage.haskell.org/package/compensated I think the first step would be adding better support for writing double# and float# literals, perhaps with hexadecimal notation support, as this ticket suggests, as a prereq to the subsequent parts of the ticket. Perhaps that literal support should be spun out into its own ticket and your first task is adding that literals support? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4101#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 13 Jan '14

13 Jan '14

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): New numbers, after uprooting a bug where things unrelated to CPR (namely things alrady returning an unboxed tuple, with nothing to be CPRed inside) would suddenly get an `INLINE` flag, including some thunks. Finally a measurable positive change in the geometric mean! {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi +0.3% -0.1% 0.00 0.00 +0.0% compress2 +0.6% -0.8% 0.11 0.11 -8.0% fibheaps +0.3% -0.3% 0.03 0.03 +0.0% gamteb +0.4% -0.2% 0.04 0.04 +0.0% grep +0.3% -0.1% 0.00 0.00 +0.0% hpg +0.4% -3.0% 0.13 0.13 +0.0% infer +0.3% -1.2% 0.03 0.03 +0.0% k-nucleotide +0.2% -6.9% -1.6% -1.4% +0.0% maillist +0.4% -0.8% 0.04 0.04 +0.8% mkhprog +0.4% -0.3% 0.00 0.00 +0.0% pic +0.3% -0.7% 0.00 0.00 +0.0% pretty +0.4% -0.1% 0.00 0.00 +0.0% rfib +0.3% -0.2% 0.01 0.01 +0.0% scc +0.3% -0.1% 0.00 0.00 +0.0% spectral-norm +0.4% -0.1% +0.3% +0.3% +0.0% sphere +0.4% -4.7% 0.04 0.04 +0.0% symalg +0.3% -0.1% 0.01 0.01 +0.0% tak +0.3% -0.3% 0.01 0.01 +0.0% transform +0.3% +0.2% -2.2% -2.2% +0.0% -------------------------------------------------------------------------------- Min +0.2% -6.9% -5.3% -28.2% -11.2% Max +0.7% +0.2% +2.1% +2.1% +50.0% Geometric Mean +0.3% -0.2% -0.8% -2.3% +0.2% }}} Surprisingly to me, the bug fix also fixed a +11% increase in wave4main’s allocations, which I thought were caused by join-point losses. A quick glance into `transform` shows that `f_list_cmp` lost its (non- nested) CPR property, accounting for most of the increase according to ticky. Will investigate tomorrow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 13 Jan '14

13 Jan '14

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): New numbers, after uprooting a bug where things unrelated to CPR (namely things alrady returning an unboxed tuple, with nothing to be CPRed inside) would suddenly get an `INLINE` flag, including some thunks. Finally a measurable positive change in the geometric mean! {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi +0.3% -0.1% 0.00 0.00 +0.0% awards +0.3% -0.1% 0.00 0.00 +0.0% compress2 +0.5% -0.8% 0.11 0.11 -8.0% fibheaps +0.3% -0.3% 0.03 0.03 +0.0% gamteb +0.3% -0.2% 0.04 0.04 +0.0% grep +0.3% -0.1% 0.00 0.00 +0.0% hpg +0.3% -3.0% 0.13 0.13 +0.0% infer +0.3% -1.2% 0.04 0.04 +0.0% k-nucleotide +0.1% -6.9% -1.3% -1.1% +0.0% kahan -11.9% -0.1% 0.17 0.17 +0.0% maillist +0.3% -0.8% 0.04 0.04 -22.5% mkhprog +0.3% -0.3% 0.00 0.00 +0.0% pic +0.3% -0.6% 0.00 0.00 +0.0% pretty +0.3% -0.1% 0.00 0.00 +0.0% rfib +0.3% -0.1% 0.01 0.01 +0.0% scc +0.3% -0.1% 0.00 0.00 +0.0% spectral-norm +0.3% -0.1% +0.2% +0.3% +0.0% sphere +0.3% -4.7% 0.04 0.04 +0.0% symalg +0.3% -0.1% 0.01 0.01 +0.0% tak +0.3% -0.3% 0.01 0.01 +0.0% transform +0.3% +0.2% -0.7% -0.7% +0.0% wave4main +0.4% +12.2% 0.21 0.21 +7.7% -------------------------------------------------------------------------------- Min -11.9% -6.9% -4.5% -26.8% -22.5% Max +0.6% +12.2% +2.1% +1.9% +50.0% Geometric Mean +0.2% -0.1% -0.3% -2.1% +0.1% }}} The increase of `wave4main` is due to a lost join point, as discussed in [wiki:NestedCPR/wave4main]. The increase in transform is not yet investigated (but will be, and then be discussed [wiki:NestedCPR#Motivatingexamples here]. I also did not look into the code size changes yet; `kahan` certainly looks interesting here... I was not especially careful about the runtime numbers, but I believe that the machine was unloaded when doing either ran. It certainly was when I was doing the baseline. So these are maybe a bit reliable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6070: Fun with the demand analyser
by GHC 13 Jan '14

13 Jan '14

#6070: Fun with the demand analyser -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): The first issue is also reported as #5949. So I guess this ticket should track the second infelicity. Unfortunately, I am not able to edit the ticket description, otherwise I’d remove it here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6070#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8616: "Internal error" with ScopedTypeVariables and kind variables
by GHC 13 Jan '14

13 Jan '14

#8616: "Internal error" with ScopedTypeVariables and kind variables ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I try to compile the following nonsense with HEAD {{{ {-# LANGUAGE PolyKinds, RankNTypes, ScopedTypeVariables #-} import Data.Proxy import GHC.Exts withSomeSing :: forall (kproxy :: k). Proxy kproxy withSomeSing = undefined :: (Any :: k) }}} I get this {{{ GHC internal error: ‛k’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [(a4XG, Type variable ‛kproxy’ = kproxy), (r4MW, Identifier[withSomeSing::forall (k :: BOX) (kproxy :: k). Proxy k kproxy, <NotTopLevel>])] In the kind ‛k’ In an expression type signature: (Any :: k) In the expression: undefined :: (Any :: k) }}} The code is very bogus, but so is GHC's response. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3