[GHC] #7544: GHC downloads are unsigned
#7544: GHC downloads are unsigned --+- Reporter: afcowie| Owner: Type: feature request| Status: new Priority: normal | Component: Build System Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Other Failure: Documentation bug | Blockedby: Blocking: |Related: --+- Hi, I recently came across a feature that is patched in 7.6 but not in 7.4; cause to upgrade. The Haskell website has binary downloads, ie http://www.haskell.org/ghc/download_ghc_7_6_1#x86_64linux but there are no SHA1 hashes or GPG signatures. This may seem like busy work, but it's important to know who is building software and how it was built. Would it be possible to first of all post md5sums or sha1sums of the builds, and then down the road get that file GPG signed by someone responsible for the process? Not sure where best to file this; sorry for noise if this is the wrong place. AfC -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7544 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7216: Compositional blocking on file descriptors
#7216: Compositional blocking on file descriptors ---+ Reporter: AndreasVoellmy| Owner: igloo Type: feature request | Status: patch Priority: normal| Milestone: 7.8.1 Component: libraries/base|Version: 7.4.2 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by AndreasVoellmy): I made a new patch that implements the threadWaitReadSTM and threadWaitWriteSTM functions for Windows with the threaded RTS. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7526: Minor typo in error message
#7526: Minor typo in error message
-+--
Reporter: parcs | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
Comment(by simonpj@…):
commit 18003c9ec8e2f5a6ae82565c1e1ba35fada72021
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Tue Jan 1 22:40:45 2013 +
Fix typo in comment (Trac #7526)
compiler/typecheck/TcMType.lhs |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7526#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7536: Panic with TypeFamilies with type synonym instances
#7536: Panic with TypeFamilies with type synonym instances
---+
Reporter: snowleopard | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: Compile-time crash | Blockedby:
Blocking: |Related:
---+
Comment(by simonpj@…):
commit e89f3bac94f513841f46346528183920783ce1f9
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Jan 2 08:26:28 2013 +
In type or data instances, check that all variables are bound
Trac #7536 points out that it's possible for the LHS to *look*
as if it binds variables, but does not acutally do so
type T a = Int
type instance F (T a) = a
This patch makes it an error.
compiler/typecheck/TcInstDcls.lhs | 43
++-
compiler/typecheck/TcMType.lhs | 36 ++---
compiler/typecheck/TcTyClsDecls.lhs | 23 ++
3 files changed, 57 insertions(+), 45 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7536#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7216: Compositional blocking on file descriptors
#7216: Compositional blocking on file descriptors ---+ Reporter: AndreasVoellmy| Owner: igloo Type: feature request | Status: patch Priority: normal| Milestone: 7.8.1 Component: libraries/base|Version: 7.4.2 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by AndreasVoellmy): Sorry for all the patches. You can ignore all, but the last. expose- threadWaitSTM-on-master.2.patch which expose-threadWaitSTM-on- master.3.patch fixed. expose-threadWaitSTM-on-master.4.patch is a minor simplification. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7526: Minor typo in error message
#7526: Minor typo in error message ---+ Reporter: parcs | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = fixed Comment: Thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7526#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7536: Panic with TypeFamilies with type synonym instances
#7536: Panic with TypeFamilies with type synonym instances -+-- Reporter: snowleopard | Owner: Type: bug | Status: merge Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown |Testcase: indexed_types/should_fail/T7536 Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * status: new = merge * difficulty: = Unknown * testcase: = indexed_types/should_fail/T7536 Comment: Thanks for pointing this out. I guess this fix is worth merging to the 7.6 branch, if it goes through smoothly. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7536#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7533: References to very old GHC in the docs
#7533: References to very old GHC in the docs +--- Reporter: benmachine | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: Documentation |Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = fixed Comment: Thanks; I've committed the patch. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7533#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Fundeps and type equality
As far as I understand, the reason that GHC does not construct such proofs is that it can't express them in its internal proof language (System FC). Iavor is quite right It seems to me that it should be fairly straight-forward to extend FC to support this sort of proof, but I have not been able to convince folks that this is the case. I could elaborate, if there's interest. Iavor: I don’t think it’s straightforward, but I’m willing to be educated. By all means start a wiki page to explain how, if you think it is. I do agree that injective type families would be a good thing, and would deal with the main reason that fundeps are sometimes better than type families. A good start would be to begin a wiki page to flesh out the design issues, perhaps linked from http://hackage.haskell.org/trac/ghc/wiki/TypeFunctions The main issues are, I think: · How to express functional dependencies like “fixing the result type and the first argument will fix the second argument” · How to express that idea in the proof language Simon From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-boun...@haskell.org] On Behalf Of Iavor Diatchki Sent: 26 December 2012 02:48 To: Conal Elliott Cc: glasgow-haskell-bugs@haskell.org; GHC Users Mailing List Subject: Re: Fundeps and type equality Hello Conal, GHC implementation of functional dependencies is incomplete: it will use functional dependencies during type inference (i.e., to determine the values of free type variables), but it will not use them in proofs, which is what is needed in examples like the one you posted. The reason some proving is needed is that the compiler needs to figure out that for each instantiation of the type `ta` and `tb` will be the same (which, of course, follows directly from the FD on the class). As far as I understand, the reason that GHC does not construct such proofs is that it can't express them in its internal proof language (System FC). It seems to me that it should be fairly straight-forward to extend FC to support this sort of proof, but I have not been able to convince folks that this is the case. I could elaborate, if there's interest. In the mean time, the way forward would probably be to express the dependency using type families, which I find tends to be more verbose but, at present, is better supported in GHC. Cheers, -Iavor PS: cc-ing the GHC users' list, as there was some talk of closing the ghc-bugs list, but I am not sure if the transition happened yet. On Tue, Dec 25, 2012 at 6:15 PM, Conal Elliott co...@conal.netmailto:co...@conal.net wrote: I ran into a simple falure with functional dependencies (in GHC 7.4.1): class Foo a ta | a - ta foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool foo = (==) I expected that the `a - ta` functional dependency would suffice to prove that `ta ~ tb`, but Pixie/Bug1.hs:9:7: Could not deduce (ta ~ tb) from the context (Foo a ta, Foo a tb, Eq ta) bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool at Pixie/Bug1.hs:9:1-10 `ta' is a rigid type variable bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool at Pixie/Bug1.hs:9:1 `tb' is a rigid type variable bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool at Pixie/Bug1.hs:9:1 Expected type: ta - tb - Bool Actual type: ta - ta - Bool In the expression: (==) In an equation for `foo': foo = (==) Failed, modules loaded: none. Any insights about what's going wrong here? -- Conal ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.orgmailto:Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7543: Constraint synonym instances
#7543: Constraint synonym instances
-+--
Reporter: monoidal | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by simonpj):
* difficulty: = Unknown
Comment:
I can see your point; and I agree it's odd that it's accepted when no
methods are given. But it's not easy to fix in the way you want. Here's
why.
Suppose we have
{{{
class C a where
reverse :: a - a
instance C Int where
reverse x = x
}}}
When GHC encounters the binding `reverse x = x`, it has to figure out
which `reverse` you mean -- there are two in scope. Ah! Since this is in
an instnace declaraction, it must be the one that's method of class `C`,
not the one from `Prelude`.
This scope resolution is done by the '''renamer'''. The renamer does not
understand type synonyms (they are interpreted by the subsequent '''type
checker'''), so it can't figure out that `Ring` really means `Num` in your
example.
I can't see an easy way round this in GHC's current structure. The only
think that comes to mind is to postpone all scope resolution for instance
bindings until the type checker. But that would mean a bit of an upheaval
of datatypes etc. Quite do-able, but not very simple.
As things stand it might be more consistent to reject an instance
declaration if the class turns out to be a synonym.
I'm rather inclined to do nothing!
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7543#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3282: How to start an emacs editor within ghci asynchronously with :edit filename.hs :set editor emacs don't go
#3282: How to start an emacs editor within ghci asynchronously with :edit filename.hs :set editor emacsdon't go -+-- Reporter: petersonx | Owner: Type: feature request | Status: new Priority: lowest| Milestone: 7.6.2 Component: GHCi | Version: 6.10.2 Keywords:| Os: Linux Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by mf825): * failure: = None/Unknown Comment: there is an easy work-around, at least for emacs users: start emacs like this in a separate terminal: $ emacs -e server-start then, in ghci: :set editor emacsclient -n :load Main.hs :edit emacsclient should not block, so you can continue using ghci. the only catch is that emacs will only open a new window if it is configured to do that (mine only has buffers), and only if Main.hs hasn't already been loaded into a buffer. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3282#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
#1407: Add the ability to :set -l{foo} in .ghci files
+---
Reporter: guest| Owner:
Type: feature request | Status: new
Priority: normal | Milestone: _|_
Component: GHCi | Version: 6.6.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Easy (less than 1 hour) |Testcase:
Blockedby: |Blocking:
Related: |
+---
Changes (by mf825):
* failure: = None/Unknown
Comment:
I would like to second this request. I use emacs as an IDE, and call ghci
from emacs with all the command line parameter handling in .ghci. Of
course I could write elisp functions to pluck -l parameters from :set
statements in .ghci, but that seems a little insane.
Also, since both -L and -l are documented as dynamic, and all dynamic
command line arguments are documented to work both on the command line and
in .ghci, I suggest this is changed into a bug.
I reproduced this with ghc-7.6.1 on debian and with ghc-7.4.1 on ubuntu.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1407#comment:8
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
#1407: Add the ability to :set -l{foo} in .ghci files
+---
Reporter: guest| Owner: igloo
Type: feature request | Status: new
Priority: normal | Milestone: _|_
Component: GHCi | Version: 6.6.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Easy (less than 1 hour) |Testcase:
Blockedby: |Blocking:
Related: |
+---
Changes (by simonpj):
* owner: = igloo
Comment:
Ian, could you investigate why this doesn't already work? Thanks.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1407#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7532: -ddump-splices output doesn't match generated code for data instances inside instances.
#7532: -ddump-splices output doesn't match generated code for data instances
inside instances.
-+--
Reporter: Aninhumer | Owner:
Type: bug | Status: new
Priority: normal| Component: Template Haskell
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
Comment(by simonpj@…):
commit 9b9f197b05c4bf9d16289d3aa6e71e9f081da7f6
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Jan 2 12:37:07 2013 +
Improve HsSyn pretty-printing of instance declarations (fixes Trac
#7532)
compiler/hsSyn/HsDecls.lhs | 42
+++---
1 files changed, 27 insertions(+), 15 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7532#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7541: Unavoidable duplicate constraint warning
#7541: Unavoidable duplicate constraint warning
--+-
Reporter: blamario | Owner:
Type: bug| Status: new
Priority: normal | Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
Failure: Incorrect warning at compile-time | Blockedby:
Blocking: |Related:
--+-
Comment(by simonpj@…):
commit 5a6a223f855538112ec9d089425e34853fb3542b
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Jan 2 11:57:00 2013 +
Add flag -fwarn-duplicate-constraints
This fixes Trac #7541, and is on by default.
Use -fno-warn-duplicate-constraints to switch it off.
compiler/main/DynFlags.hs |5 -
compiler/typecheck/TcMType.lhs |9 +
docs/users_guide/flags.xml |7 +++
docs/users_guide/using.xml | 19 +++
4 files changed, 35 insertions(+), 5 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7541#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7541: Unavoidable duplicate constraint warning
#7541: Unavoidable duplicate constraint warning +--- Reporter: blamario | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Difficulty: Unknown Testcase: typecheck/should_compile/T7541 | Blockedby: Blocking: |Related: +--- Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = fixed * testcase: = typecheck/should_compile/T7541 Comment: OK I've added a flag to suppress duplicate constraint warnings. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7541#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7532: -ddump-splices output doesn't match generated code for data instances inside instances.
#7532: -ddump-splices output doesn't match generated code for data instances inside instances. ---+ Reporter: Aninhumer | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Template Haskell |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: th/T7532 | Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = fixed * testcase: = th/T7532 Comment: Good point, thank you. A pretty printing bug, now fixed. I don't think this is worth merging to 7.6 becuase that code has changed a bit, so it'll need a bit of fiddling and it's not a big deal. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7532#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
#7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion -+-- Reporter: shachaf | Owner: Type: bug | Status: patch Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by dreixel): I don't think I ever wrote any of the deriving code apart from `Generic` and `Typeable`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7436#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7545: Type variable capture in InstanceSigs message
#7545: Type variable capture in InstanceSigs message
-+--
Reporter: Feuerbach | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
If I load this file in GHCi:
{{{
{-# LANGUAGE RankNTypes, InstanceSigs #-}
class C a where
f :: a - b
instance C (a - b) where
f :: x
f = undefined
}}}
I get the message
{{{
Method signature does not match class; it should be
f :: forall b. (a - b) - b
In the instance declaration for `C (a - b)'
}}}
However, this is not the correct type (and if I copy-paste it, GHCi would
still complain). The b from the instance head got captured. The correct
type would be forall b1. (a - b) - b1.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7545
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
#7436: Derived Foldable and Traversable instances become extremely inefficient
due
to eta-expansion
-+--
Reporter: shachaf | Owner:
Type: bug | Status: patch
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by twanvl):
I wrote the original deriving code for Functor/Foldable/Traversable.
Someone else later cleaned it up a bit.
The strange code that is generated are lambdas applied to arguments, which
is something that GHC should be able to optimize away easily. To avoid the
eta-expansion, the generated code is always a function. So you end up with
code like
{{{
data Cons a = Cons (a,a)
fmap f (Cons x) = (\x - case x of (x1,x2) - (f x1 , f x2)) x
}}}
I could add this example to a note, if you insist.
There are no library changes in the patch, and the derived code is
functionally equivalent to what was there before.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7436#comment:12
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7546: Manual 6.2 doesn't match current output formatting
#7546: Manual 6.2 doesn't match current output formatting
-+--
Reporter: chrisseaton | Owner:
Type: bug | Status: new
Priority: normal| Component: Documentation
Version: 7.6.1 | Keywords: strictness iface
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
Section 6.2 of the manual, under “How do I find out a function's
strictness?”, talks about using GHC to show strictness in the interface
file.
It says to look for {{{__S string}}}. Should that be {{{Strictness:
string}}}. I don't see the former anywhere in the GHC's formatting of
the interface file, but I do see the latter. I looked through the history
of ghc/compiler/iface/IfaceSyn.lhs, and it appears to have been the latter
for at least several years.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7546
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
#7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion -+-- Reporter: shachaf | Owner: Type: bug | Status: patch Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonpj): Yes, I think it'd be very helpful to add a `Note [Avoid eta-expanded code]`, explaining the problem, giving an example, and pointing to this ticket. Thank you. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7436#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #619: Port Hugs's Windows front end to GHCi.
#619: Port Hugs's Windows front end to GHCi. ---+ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal| Milestone: _|_ Component: Compiler |Version: None Resolution: None | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Project (more than a week) Testcase: N/A | Blockedby: Blocking:|Related: ---+ Changes (by shelarcy): * failure: = None/Unknown Comment: I think we could close this ticket. Because Haskell Platform includes WinGHCi on Windows Platform, though GHC doesn't include WinGHCi. * https://github.com/haskell/haskell-platform/tree/master/src/win32 * http://code.google.com/p/winghci/ If anyone has opinion about WinGHCi, I think we should open another ticket on Haskell Platform's Trac, or any other more suitable place. * http://trac.haskell.org/haskell-platform/wiki -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/619#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7547: Loop when printing External Core
#7547: Loop when printing External Core
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Daniel Fischer points out: something is amiss between -fext-core and
optimisations.
Validating (`--testsuite-only --slow`) brought my box to its knees badly,
the culprit turned out to be `T7239` with the optasm, hpc, and optllvm
ways:
{{{
= T7239(hpc) 1434 of 3536 [0, 4, 0]
cd ./ext-core '/home/dafis/GHC/bghc/bindisttest/install dir/bin/ghc'
-
fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
- rtsopts -fno-ghci-history -c T7239.hs -O -fhpc -fext-core
T7239.comp.stderr
21
Compile failed (status 256) errors were:
stack overflow: use +RTS -Ksize to increase it
*** unexpected failure for T7239(hpc)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7547
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7547: Loop when printing External Core
#7547: Loop when printing External Core
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonpj@…):
commit 3f7b147c41a83bb69e2cd2337994434bf2507ef3
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Jan 2 15:47:31 2013 +
Fix bug in External Core pretty printer (fixes Trac #7547)
This bug was making GHC loop when printing external core from test
T7239.
compiler/coreSyn/PprExternalCore.lhs | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7547#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7546: Manual 6.2 doesn't match current output formatting
#7546: Manual 6.2 doesn't match current output formatting
-+--
Reporter: chrisseaton | Owner:
Type: bug | Status: new
Priority: normal| Component: Documentation
Version: 7.6.1 | Keywords: strictness iface
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
Comment(by simonpj@…):
commit 5f77b315a8f66fd9842f9120a9def4f85209efae
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Jan 2 15:43:34 2013 +
Update strictness documentation (Trac #7546)
docs/users_guide/sooner.xml | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7546#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7510: Immediate seg-fault on 32-bit windows build
#7510: Immediate seg-fault on 32-bit windows build
-+--
Reporter: simonpj | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by igloo):
I just tried a build with
{{{
--- a/compiler/nativeGen/X86/Instr.hs
+++ b/compiler/nativeGen/X86/Instr.hs
@@ -741,22 +741,22 @@ x86_mkJumpInstr id
x86_mkStackAllocInstr
:: Platform
-- Int
+- Int -- number of stack slots needed
- Instr
x86_mkStackAllocInstr platform amount
= case platformArch platform of
- ArchX86- SUB II32 (OpImm (ImmInt amount)) (OpReg esp)
- ArchX86_64 - SUB II64 (OpImm (ImmInt amount)) (OpReg rsp)
+ ArchX86- SUB II32 (OpImm (ImmInt (4 * amount))) (OpReg esp)
+ ArchX86_64 - SUB II64 (OpImm (ImmInt (8 * amount))) (OpReg rsp)
_ - panic x86_mkStackAllocInstr
x86_mkStackDeallocInstr
:: Platform
-- Int
+- Int -- number of stack slots needed
- Instr
x86_mkStackDeallocInstr platform amount
= case platformArch platform of
- ArchX86- ADD II32 (OpImm (ImmInt amount)) (OpReg esp)
- ArchX86_64 - ADD II64 (OpImm (ImmInt amount)) (OpReg rsp)
+ ArchX86- ADD II32 (OpImm (ImmInt (4 * amount))) (OpReg esp)
+ ArchX86_64 - ADD II64 (OpImm (ImmInt (8 * amount))) (OpReg rsp)
_ - panic x86_mkStackDeallocInstr
}}}
but that still segfaults when configuring the timeout program.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7510#comment:8
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7545: Type variable capture in InstanceSigs message
#7545: Type variable capture in InstanceSigs message
-+--
Reporter: Feuerbach | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
Comment(by simonpj@…):
commit 7fa2ce2043e2faed2b2b545ba5c1c9958954800a
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Jan 2 16:24:14 2013 +
Tidy the type in badInstSigErr (fixes Trac #7545)
compiler/typecheck/TcInstDcls.lhs | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7545#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7258: Compiling DynFlags is jolly slow
#7258: Compiling DynFlags is jolly slow
-+--
Reporter: simonpj | Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonpj@…):
commit 9ea2bcb6684279a120c688e8557bcef3dc73
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Dec 24 11:34:51 2012 +
Simplify the binder-swap transformation
The occurrence analyser implements the binder-swap transformation,
described in Note [Binder swap] in OccAnal. For some reason I had
implemeted an extremely complicated version, I believe intended to get
as much as possible done in single simplifier pass. But it turned
out (Trac #7258) that the 'getProxies' bit of this complicated code
scaled rather non-linearly, and all by itself could consume half of
the entire compile time.
The patch dramatically simplifies the transformation, so that
we simply swizzle
case x of y { I# v - e }
to
case x of y { I# v - let x = y in e }
I can't see any reason not to do this
* Compiler allocation for #7258 with 200 fields goes down by 25%
and compile time by 20%
* The nofib figures do not budge
* Quite a bit of complicated code goes away
compiler/simplCore/OccurAnal.lhs | 255
+++---
1 files changed, 46 insertions(+), 209 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7258#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7360: Case-of-identical-alts optimisation fails abjectly
#7360: Case-of-identical-alts optimisation fails abjectly
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonpj@…):
commit bacf7ca075498aed745f68448f7e2b8d15c39541
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Dec 24 13:25:12 2012 +
Make combine-identical-alternatives work again (Trac #7360)
Move the combine indentical alternatives transformation *before*
simplifying the alternatives. For example
case x of y
[] - length y
(_:_) - length y }
If we look *post* simplification, since 'y' is used in the
alterantives, the case binders *might* be (see the keep_occ_info test
in Simplify.simplAlt); and hence the combination of the two
alteranatives does not happen. But if we do it *pre* simplification
there is no problem.
This fixes Trac #7360.
compiler/simplCore/SimplUtils.lhs | 127
-
1 files changed, 68 insertions(+), 59 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7360#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7360: Case-of-identical-alts optimisation fails abjectly
#7360: Case-of-identical-alts optimisation fails abjectly -+-- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: None/Unknown| Difficulty: Unknown Testcase: simplCore/should_compile/T7360 | Blockedby: Blocking: |Related: -+-- Changes (by simonpj): * status: new = closed * testcase: = simplCore/should_compile/T7360 * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7360#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7546: Manual 6.2 doesn't match current output formatting
#7546: Manual 6.2 doesn't match current output formatting -+-- Reporter: chrisseaton | Owner: Type: bug | Status: merge Priority: normal| Milestone: Component: Documentation | Version: 7.6.1 Keywords: strictness iface | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * status: new = merge * difficulty: = Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7546#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7547: Loop when printing External Core
#7547: Loop when printing External Core -+-- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * status: new = merge Comment: Fixed. I won't add a new test. Merge to 7.6. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7547#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7545: Type variable capture in InstanceSigs message
#7545: Type variable capture in InstanceSigs message
-+--
Reporter: Feuerbach | Owner:
Type: bug | Status: merge
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase: typecheck/should_fail/T7545
Blockedby:|Blocking:
Related:|
-+--
Changes (by simonpj):
* status: new = merge
* difficulty: = Unknown
* testcase: = typecheck/should_fail/T7545
Comment:
Good point, thank you. Now we get
{{{
T7545.hs:8:9:
Method signature does not match class; it should be
f :: forall b1. (a - b) - b1
In the instance declaration for `C (a - b)'
}}}
Merge to 7.6 if it's easy.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7545#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7519: CLK_TCK is not always a constant
#7519: CLK_TCK is not always a constant -+-- Reporter: singpolyma| Owner: Type: bug | Status: patch Priority: normal| Milestone: Component: libraries/base| Version: 7.7 Keywords: qnx | Os: Other Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * difficulty: = Unknown Comment: Does it expand to `sysconf(_SC_CLK_TCK)`? If `sysconf` and `_SC_CLK_TCK` are portable enough, then we may as well just unconditionally use that. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7519#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7539: Hard ghc api crash when calling runStmt on code which has not been compiled
#7539: Hard ghc api crash when calling runStmt on code which has not been compiled -+-- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * difficulty: = Unknown Comment: Wierd. Does anyone feel able to investigate a bit nore, to nail down what's happening? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7539#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7510: Immediate seg-fault on 32-bit windows build
#7510: Immediate seg-fault on 32-bit windows build
-+--
Reporter: simonpj | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by igloo):
But with
{{{
--- a/compiler/nativeGen/AsmCodeGen.lhs
+++ b/compiler/nativeGen/AsmCodeGen.lhs
@@ -189,7 +189,7 @@ x86_64NcgImpl dflags
,maxSpillSlots = X86.Instr.maxSpillSlots dflags
,allocatableRegs = X86.Regs.allocatableRegs platform
,ncg_x86fp_kludge = id
- ,ncgAllocMoreStack = X86.Instr.allocMoreStack platform
+ ,ncgAllocMoreStack = noAllocMoreStack --
X86.Instr.allocMoreStack platform
,ncgExpandTop = id
,ncgMakeFarBranches= id
}
}}}
the build fails with
{{{
inplace/bin/ghc-stage1.exe -static-H32m -O -Werror -Wall -H64m -O0
-package-name Cabal-1.17.0 -hide-all-packages -i
-ilibraries/Cabal/Cabal/. -ilibraries/Cabal/Cabal/dist-install/build
-ilibraries/Cabal/Cabal/dist-install/build/autogen
-Ilibraries/Cabal/Cabal/dist-install/build -Ilibraries/Cabal/Cabal/dist-
install/build/autogen -Ilibraries/Cabal/Cabal/.-optP-include
-optPlibraries/Cabal/Cabal/dist-install/build/autogen/cabal_macros.h
-package array-0.4.0.2 -package base-4.7.0.0 -package bytestring-0.10.2.0
-package containers-0.5.0.0 -package deepseq-1.3.0.2 -package
directory-1.2.0.1 -package filepath-1.3.0.2 -package pretty-1.1.1.0
-package process-1.2.0.0 -package time-1.4.0.2-fwarn-tabs -Wall -fno-
ignore-asserts -XHaskell98 -XCPP -O2 -O -dcore-lint -fno-warn-deprecated-
flags-no-user-package-db -rtsopts -w -odir
libraries/Cabal/Cabal/dist-install/build -hidir libraries/Cabal/Cabal
/dist-install/build -stubdir libraries/Cabal/Cabal/dist-install/build
-hisuf hi -osuf o -hcsuf hc -c
libraries/Cabal/Cabal/./Distribution/Simple/SrcDist.hs -o
libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/SrcDist.o
ghc-stage1.exe: panic! (the 'impossible' happened)
(GHC version 7.7.20130101 for i386-unknown-mingw32):
Register allocator: out of stack slots (need 682)
If you are trying to compile SHA1.hs from the crypto library then this
is a known limitation in the linear allocator.
Try enabling the graph colouring allocator with -fregs-graph instead.
You can still file a bug report if you like.
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
so we are at least hitting this code, so it's plausible that it is to
blame.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7510#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7519: CLK_TCK is not always a constant
#7519: CLK_TCK is not always a constant -+-- Reporter: singpolyma| Owner: Type: bug | Status: patch Priority: normal| Milestone: Component: libraries/base| Version: 7.7 Keywords: qnx | Os: Other Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by singpolyma): That is what it expands to on QNX, yes. Well, it actually expands to `_sysconf(_SC_CLK_TCK)` which is an internal QNX wrapper, but the result is the same. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7519#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
#7542: GHC doesn't optimize (strict) composition with id
-+--
Reporter: shachaf | Owner:
Type: bug | Status: infoneeded
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by simonpj):
* status: new = infoneeded
* difficulty: = Unknown
Comment:
Can you give a concrete example? With this module
{{{
module T7542 where
newtype Id a = MkId a
f1 = map reverse
f2 = map (MkId . reverse)
}}}
compiled with `ghc-7.6 -O -ddump-stg` I get
{{{
STG syntax:
T7542.f1 :: forall a_afy. [[a_afy]] - [[a_afy]]
[GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
\r [eta_B1] GHC.Base.map GHC.List.reverse eta_B1;
SRT(T7542.f1): []
T7542.f2 :: forall a_afr. [[a_afr]] - [T7542.Id [a_afr]]
[GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
\r [eta_B1] GHC.Base.map GHC.List.reverse eta_B1;
SRT(T7542.f2): []
}}}
which looks fine to me.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7542#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7548: GHC API dependency analysis is broken
#7548: GHC API dependency analysis is broken +--- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Component: GHC API Version: 7.4.2| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking: |Related: +--- Sometimes, when a module fails to compile, GHC API invalidates other modules that do not depend on it (the attached example shows that) and sometimes the opposite --- it does not invalidate modules it should (I haven't created a standalone example with that so far). The problem is deterministic, but depends on the order in which targets are added using addSingle. Generally, it seems if module B imports A, it correctly assumes A does not depend on B, but if B does not import A, it sometimes assumes A must depend on B, even if neither mentions the other. See comments in the example. To reproduce, compile the example with ghc --make typecheck-dir.hs -package ghc-7.4.2 create directory ./tmp and run typecheck-dir. You should see that module XXX is needlessly recompiled. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7548 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: DoCon and GHC
Serge
That's odd. I've tried with both 7.6 and HEAD, and both fail on T_cubeext thus:
T_cubeext.hs:102:10:
Overlapping instances for LinSolvRing (UPol k)
arising from a use of `upEucRing'
Matching instances:
instance [overlap ok] EuclideanRing a = LinSolvRing (UPol a)
-- Defined in `docon-2.12:Pol2_'
instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) =
LinSolvRing (UPol (Pol a))
-- Defined in `docon-2.12:Pol3_'
(The choice depends on the instantiation of `k'
To pick the first instance above, use -XIncoherentInstances
when compiling the other instance declarations)
In the expression: upEucRing unA Map.empty
In an equation for `dA': dA = upEucRing unA Map.empty
I am using ghc-7.6 from Dec 3 (ie *later* than the released GHC 7.6.1), so
perhaps the difference in error message is due to a bug in 7.6.1 that's fixed
in my version. I suggest you use the 7.6.2 release candidate.
Anyway, the error message looks entirely legitimate. It really does matter how
'k' is instantiated! I have no idea how it compiled before.
The solution is to add (EuclideanRing k) to the type sig of cubicExt. Then it
compiles all the way up to the top.
Simon
| -Original Message-
| From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-
| bugs-boun...@haskell.org] On Behalf Of Serge D. Mechveliani
| Sent: 21 December 2012 18:46
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-bugs@haskell.org
| Subject: Re: DoCon and GHC
|
| On Fri, Dec 21, 2012 at 01:45:04PM +, Simon Peyton-Jones wrote:
| OK, do this
|
| * {-# LANGUAGE ScopedTypeVariables, MonoLocalBinds #-}
|
| * import Categs( Domains1 )
|
| * Add type sig for dP'
| dP' :: (LinSolvRing (Pol a), CommutativeRing a) = Domains1 (Pol
| a)
|
| Then it compiles.
|
| You are very close to the edge of what can be done!
|
|
| It works. Thank you.
|
| There remains only a single unlucky module: T_cubeext.
| The test demotest/Main works with exception of T_cubeext, but I need
| T_cubeext.cubicExt to work.
|
| Please, continue the test with
|
| make install
| cd demotest
| ghc $doconCpOpt --make Main
|
| (for $doconCpOpt =
| -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports
| -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns
| -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances
| -XTypeSynonymInstances -XFlexibleInstances -XOverlappingInstances ).
|
| It reports
|
| --
| ...
| T_cubeext.hs:102:20:
| Could not deduce (k ~ k1)
| from the context (Field k, FactorizationRing (UPol k))
| bound by the type signature for
| cubicExt :: (Field k, FactorizationRing (UPol k)) =
| k - k - Domains1 k - (Domains1 (E k), [E
| k], k - E k)
| at T_cubeext.hs:(79,13)-(80,69)
| or from (Field k1, FactorizationRing (UPol k1))
| bound by the type signature for
| unA :: (Field k1, FactorizationRing (UPol k1)) = UPol
| k1
| at T_cubeext.hs:101:9-56
| `k' is a rigid type variable bound by
| the type signature for
| cubicExt :: (Field k, FactorizationRing (UPol k)) =
| k - k - Domains1 k - (Domains1 (E k), [E k],
| k - E k)
| at T_cubeext.hs:79:13
| `k1' is a rigid type variable bound by
|the type signature for
| unA :: (Field k1, FactorizationRing (UPol k1)) = UPol k1
|at T_cubeext.hs:101:9
| Expected type: Domains1 k1
| Actual type: Domains1 k
| In the second argument of `cToUPol', namely `dK'
| In the expression: cToUPol d dK unK
| In an equation for `unA': unA = cToUPol d dK unK
|
| T_cubeext.hs:105:7:
| Overlapping instances for LinSolvRing (UPol k1)
| arising from a use of `upEucRing'
| Matching instances:
| instance [overlap ok] EuclideanRing a = LinSolvRing (UPol a)
| -- Defined in `docon-2.12:Pol2_'
| instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) =
| LinSolvRing (UPol (Pol a)) ...
| --
|
| I tried {-# LANGUAGE ScopedTypeVariables, MonoLocalBinds #-}, and
| setting type signatures in various parts in cubicExt.
| But this does not help.
|
| There is another point. In
| ``cubicExt :: (Field k, FactorizationRing (UPol k)) = ...''
|
| the part ``, FactorizationRing (UPol k)'' (1)
|
| was always considered as parasitic. ghc-7.4.1 needs (1) to work, and
| at least ghc-7.4.1 does compile the test.
|
| I thought, may be, the future compilers will allow to omit this part.
| At least it is desirable for ghc-7.6.2 to do the test in any variant,
| with (1) or without it.
|
| Regards,
|
| --
| Sergei
|
|
Re: [GHC] #7510: Immediate seg-fault on 32-bit windows build
#7510: Immediate seg-fault on 32-bit windows build
-+--
Reporter: simonpj | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by joeyadams):
I also tried a similar tweak to `x86_mkStackAllocInstr` and
`x86_mkStackDeallocInstr`, but still got a segfault. I multiplied by 12
instead of 4, as suggested by the `spillSlotSize` function.
{{{
spillSlotSize :: DynFlags - Int
spillSlotSize dflags = if is32Bit then 12 else 8
where is32Bit = target32Bit (targetPlatform dflags)
}}}
Apparently, the problem is a little more complicated than a missing
multiplication.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7510#comment:10
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7548: GHC API dependency analysis is broken
#7548: GHC API dependency analysis is broken +--- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHC API | Version: 7.4.2 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Changes (by simonpj): * priority: normal = highest * difficulty: = Unknown * milestone: = 7.8.1 Comment: That sounds bad. We'd better get it fixed for 7.8. Would anyone like to look into it? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7548#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7510: Immediate seg-fault on 32-bit windows build
#7510: Immediate seg-fault on 32-bit windows build
-+--
Reporter: simonpj | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by igloo):
I also tried kludging around it by adding `Opt_RegsGraph` to the default
DynFlags, but the build then fails with
{{{
inplace/bin/ghc-stage1.exe -o utils/ghc-pkg/dist-install/build/tmp/ghc-
pkg -static-H32m -O -Werror -Wall -H64m -O0-hide-all-packages
-i -iutils/ghc-pkg/. -iutils/ghc-pkg/dist-install/build -iutils/ghc-pkg
/dist-install/build/autogen -Iutils/ghc-pkg/dist-install/build -Iutils
/ghc-pkg/dist-install/build/autogen -optP-include -optPutils/ghc-
pkg/dist-install/build/autogen/cabal_macros.h -package Cabal-1.17.0
-package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package
binary-0.5.1.1 -package bytestring-0.10.2.0 -package directory-1.2.0.1
-package filepath-1.3.0.2 -package process-1.2.0.0-XHaskell98 -XCPP
-XForeignFunctionInterface -XNondecreasingIndentation-no-user-package-
db -rtsopts-odir utils/ghc-pkg/dist-install/build -hidir utils
/ghc-pkg/dist-install/build -stubdir utils/ghc-pkg/dist-install/build
-hisuf hi -osuf o -hcsuf hc utils/ghc-pkg/dist-install/build/Main.o
utils/ghc-pkg/dist-install/build/Version.o utils/ghc-pkg/dist-
install/build/CRT_noglob.o
ghc-stage1.exe: panic! (the 'impossible' happened)
(GHC version 7.7.20130101 for i386-unknown-mingw32):
regSpill: out of spill slots!
regs to spill = 1355
slots left= 677
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
Aside from fixing the bug, should we look into why we're getting so much
spilling?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7510#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7548: GHC API dependency analysis is broken
#7548: GHC API dependency analysis is broken --+- Reporter: MikolajKonarski | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHC API |Version: 7.4.2 Resolution: duplicate| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by parcs): * status: new = closed * resolution: = duplicate Comment: I believe this is a duplicate of #7231, which is fixed in HEAD. When I run the program with ghc-7.7.20121224, it prints wrong2 OK. So I think it's okay to close this ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7548#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7548: GHC API dependency analysis is broken
#7548: GHC API dependency analysis is broken --+- Reporter: MikolajKonarski | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHC API |Version: 7.4.2 Resolution: duplicate| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by simonpj): Thanks parcs! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7548#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7548: GHC API dependency analysis is broken
#7548: GHC API dependency analysis is broken --+- Reporter: MikolajKonarski | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHC API |Version: 7.4.2 Resolution: duplicate| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by MikolajKonarski): Oh, thanks for the pointer. If if says wrong2 OK then it's most probably fixed. And if it does not compile XXX twice, it's completely OK. Too bad I'm stuck with 7.4.2. I'll try to cook up some workaround based on HEAD. Thanks again! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7548#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7473: getModificationTime gives only second-level resolution
#7473: getModificationTime gives only second-level resolution --+- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/directory |Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by igloo): * status: patch = new * milestone: = 7.8.1 Comment: Applied, thanks. I'll leave the ticket open for the Windows half. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7473#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7548: GHC API dependency analysis is broken
#7548: GHC API dependency analysis is broken --+- Reporter: MikolajKonarski | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHC API |Version: 7.4.2 Resolution: duplicate| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by parcs): Indeed, XXX is compiled only once. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7548#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #619: Port Hugs's Windows front end to GHCi.
#619: Port Hugs's Windows front end to GHCi. ---+ Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal| Milestone: _|_ Component: Compiler |Version: None Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Project (more than a week) Testcase: N/A | Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: new = closed * resolution: None = wontfix Comment: I don't think WinGHCi being part of the platform really helps, as you still can't use the GHC extensions etc with it. But I do agree that this ticket isn't really serving any purpose; if someone wants to make a Windows frontend, then they will do so, and this ticket won't really help. So I'm closing it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/619#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7475: Mysterious Data.Word Segmentation Fault in GHCi
#7475: Mysterious Data.Word Segmentation Fault in GHCi --+- Reporter: VKS| Owner: Type: bug| Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: ghci, data.word, segfault | Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown|Testcase: Blockedby: 3658 |Blocking: Related: | --+- Changes (by igloo): * difficulty: = Unknown * blockedby: = 3658 * milestone: = 7.8.1 Comment: Thanks for the report. This looks like it's probably a duplicate of #7043, although that ticket claims to only affect 32bit platforms. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7475#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7043: 32-bit GHC ceiling of negative float SEGFAULT: 11
#7043: 32-bit GHC ceiling of negative float SEGFAULT: 11 --+- Reporter: DrGodCarl | Owner: igloo Type: bug| Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: Segfault, ceiling, segmentation fault | Os: MacOS X Architecture: Other | Failure: GHCi crash Difficulty: Unknown|Testcase: ceiling (-0.8) Blockedby: 3658 |Blocking: Related: | --+- Comment(by igloo): See also #7475 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7043#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: Allow empty case analysis
#2431: Allow empty case analysis +--- Reporter: RalfHinze| Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Keywords: empty case analysis | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Comment(by igloo): What's the status of this? ac230c5ef652e27f61d954281ae6a3195e1f9970 from #6067 sounds like it implements this, but it looks like it only allows it in core, not Haskell? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7549: Deriving Bug?
#7549: Deriving Bug?
-+--
Reporter: davorak | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.4.2 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
ghci -XDeriveDataTypeable
import Data.Typeable
data S = S deriving (typeable)
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.2 for x86_64-unknown-linux):
nameModule typeable{tv av8}
Please report ...
data S = S deriving typeable causes a parse error
and
The following work just fine:
data S = S deriving Typeable
data S = S deriving (Typeable)
data S = S deriving (show) causes a similar error the only change being:
nameModule show{tv av8}
The same problem exists outside of ghci when trying to compile with GHC.
The ascii tree for the dependancies of the ghc install produced with
nix-store -q --tree $(which ghc)
/nix/store/gzb4pca6nnb16lw2mbmr68kx2vwx8q56-ghc-7.4.2-wrapper[[BR]]
+---/nix/store/043zrsanirjh8nbc5vqpjn93hhrf107f-bash-4.2-p24[[BR]]
| +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13[[BR]]
| | +---/nix/store/jfcs9xnfbmiwqs224sb0qqsybbfl3sab-linux-
headers-2.6.35.14[[BR]]
| | | +---/nix/store/jfcs9xnfbmiwqs224sb0qqsybbfl3sab-linux-
headers-2.6.35.14 [...][[BR]]
| | +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
[...][[BR]]
| +---/nix/store/043zrsanirjh8nbc5vqpjn93hhrf107f-bash-4.2-p24
[...][[BR]]
+---/nix/store/858ww5lrjxca5asa79vwq5rm6m1h3q6k-ghc-7.4.2[[BR]]
| +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13 [...][[BR]]
| +---/nix/store/043zrsanirjh8nbc5vqpjn93hhrf107f-bash-4.2-p24
[...][[BR]]
| +---/nix/store/1iigiim5855m8j7pmwf5xrnpf705s4dh-binutils-2.21.1a[[BR]]
| | +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
[...][[BR]]
| | +---/nix/store/i3mqzy76lf51v5zqxjxyvf11j25iwycd-zlib-1.2.7[[BR]]
| | | +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
[...][[BR]]
| | | +---/nix/store/i3mqzy76lf51v5zqxjxyvf11j25iwycd-zlib-1.2.7
[...][[BR]]
| | +---/nix/store/1iigiim5855m8j7pmwf5xrnpf705s4dh-binutils-2.21.1a
[...][[BR]]
| +---/nix/store/a9jvlnrva7vr1szbg6shpw6nr5xz898p-gmp-5.0.5[[BR]]
| | +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
[...][[BR]]
| | +---/nix/store/4gv9gby4bn1y0rlw3k0d5lyqy0yfkrc6-gcc-4.6.3[[BR]]
| | | +---/nix/store/jfcs9xnfbmiwqs224sb0qqsybbfl3sab-linux-
headers-2.6.35.14 [...][[BR]]
| | | +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
[...][[BR]]
| | | +---/nix/store/i3mqzy76lf51v5zqxjxyvf11j25iwycd-zlib-1.2.7
[...][[BR]]
| | | +---/nix/store/4gv9gby4bn1y0rlw3k0d5lyqy0yfkrc6-gcc-4.6.3
[...][[BR]]
| | +---/nix/store/a9jvlnrva7vr1szbg6shpw6nr5xz898p-gmp-5.0.5
[...][[BR]]
| +---/nix/store/ahg5mlj2mlp7yfl3x875pq95ar763vgj-ncurses-5.9[[BR]]
| | +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
[...][[BR]]
| | +---/nix/store/043zrsanirjh8nbc5vqpjn93hhrf107f-bash-4.2-p24
[...][[BR]]
| | +---/nix/store/ahg5mlj2mlp7yfl3x875pq95ar763vgj-ncurses-5.9
[...][[BR]]
| +---/nix/store/v4m3gahx1iz53v51rdinh0lcmipn1p4j-perl-5.14.2[[BR]]
| | +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
[...][[BR]]
| | +---/nix/store/4gv9gby4bn1y0rlw3k0d5lyqy0yfkrc6-gcc-4.6.3
[...][[BR]]
| |
+---/nix/store/vpp6h8l3mzjdn5paziz31vk52pg73635-coreutils-8.15[[BR]]
| | | +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
[...][[BR]]
| | | +---/nix/store/qh3l8f8369kvbhnkbwwnpaxayvnvi55v-
acl-2.2.51[[BR]]
| | | | +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
[...][[BR]]
| | | | +---/nix/store/jaabnv7dgxzvyhg0nxzk7xqs2qxp5rcy-
attr-2.4.46[[BR]]
| | | | |
+---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13 [...][[BR]]
| | | | | +---/nix/store/jaabnv7dgxzvyhg0nxzk7xqs2qxp5rcy-
attr-2.4.46 [...][[BR]]
| | | | +---/nix/store/qh3l8f8369kvbhnkbwwnpaxayvnvi55v-acl-2.2.51
[...][[BR]]
| | | +---/nix/store/vpp6h8l3mzjdn5paziz31vk52pg73635-coreutils-8.15
[...][[BR]]
| | +---/nix/store/v4m3gahx1iz53v51rdinh0lcmipn1p4j-perl-5.14.2
[...][[BR]]
| +---/nix/store/xl3kqxs68gzs4h309wjyd32im9n6cnyr-gcc-
wrapper-4.6.3[[BR]]
| | +---/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
[...][[BR]]
| | +---/nix/store/043zrsanirjh8nbc5vqpjn93hhrf107f-bash-4.2-p24
[...][[BR]]
| | +---/nix/store/1iigiim5855m8j7pmwf5xrnpf705s4dh-binutils-2.21.1a
Re: [GHC] #7549: Deriving Bug?
#7549: Deriving Bug? -+-- Reporter: davorak |Owner: Type: bug | Status: closed Priority: normal|Component: Compiler Version: 7.4.2 | Resolution: duplicate Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Blockedby:| Blocking: Related:| -+-- Changes (by monoidal): * status: new = closed * resolution: = duplicate Comment: Thanks for the report, the bug is already fixed in GHC 7.6 - bug #5961. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7549#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7550: incorrect bang patterns rejected with report a ghc bug
#7550: incorrect bang patterns rejected with report a ghc bug
--+-
Reporter: aavogt | Owner:
Type: bug| Status: new
Priority: normal | Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
Failure: Incorrect warning at compile-time | Blockedby:
Blocking: |Related:
--+-
{{{
{-# LANGUAGE BangPatterns #-}
data E a = E { e :: ! [] a }
{- The current error given is not graceful:
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.1 for x86_64-unknown-linux):
tc_hs_type: bang
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
-}
-- maybe there could be some suggestion that E should have been written
data D a = D { d :: ! ([] a) }
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7550
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7550: incorrect bang patterns rejected with report a ghc bug
#7550: incorrect bang patterns rejected with report a ghc bug -+-- Reporter: aavogt|Owner: Type: bug | Status: closed Priority: normal|Component: Compiler Version: 7.6.1 | Resolution: duplicate Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time Blockedby:| Blocking: Related:| -+-- Changes (by monoidal): * status: new = closed * resolution: = duplicate Comment: Thanks for the report. The bug is already fixed in HEAD, see #7210. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7550#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7490: ghc-stage1 panic when building QNXNTO cross-compiler
#7490: ghc-stage1 panic when building QNXNTO cross-compiler +--- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: qnx Os: Other| Architecture: x86 Failure: Building GHC failed | Blockedby: Blocking: |Related: +--- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7490#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler (was: ghc-stage1 panic when building QNXNTO cross-compiler)
#7490: ghc-stage1 panic when building a cross-compiler or cross-building a
compiler
+---
Reporter: singpolyma | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.7 | Keywords: cross-compilation
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Building GHC failed | Blockedby:
Blocking: |Related:
+---
Changes (by PHO):
* keywords: qnx = cross-compilation
* os: Other = Unknown/Multiple
* architecture: x86 = Unknown/Multiple
Comment:
This happens to me too while cross-building a compiler for NetBSD/amd64,
so this isn't specific to QNXNTO:
{{{
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.7.20121224 for x86_64-unknown-netbsd):
expectJust initTcInteractive
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7490#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
