[GHC] #5974: Casts, rules, and parametricity
#5974: Casts, rules, and parametricity
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.4.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Pedro wrote this
[http://www.haskell.org/pipermail/generics/2012-February/000513.html long
message] about the way that his generic-programming was not optimising as
it should:
My reply was in two parts. The
[http://www.haskell.org/pipermail/generics/2012-March/000516.html first]
was fairly simple. The
[http://www.haskell.org/pipermail/generics/2012-March/000517.html second]
I reproduce below because it highlights a tricky ineraction between RULES
and casts, which I don't know how to solve.
Pedro wondered why it made a difference whether you said
{{{
instance GEnum Nat where
genum = map to genum'
or
instance GEnum Nat-- Fill in from default method
}}}
Well, it turns out that the difference is largely accidental. Here are
the types of the functions involved:
{{{
to :: Representable a = Rep a - a
genum' :: GEnum' a = [a]
type instance Rep Nat = RepNat
type RepNat = U :+: (Rec Nat)
}}}
Consider the instance definition
{{{
genum = map to genum'
}}}
There are two different ways of typing it:
{{{
(A) map @RepNat @Nat (to @Nat dReprNat | g1) (genum' @RepNat
dGEnum'_RepNat)
where
g1 :: Rep Nat - Nat ~ RepNat - Nat
dReprNat :: Representable Nat
dGEnum'Nat :: GEnum' RepNat
}}}
or
{{{
(B) map @(Rep Nat) @Nat (to @Nat dReprNat) (genum' @(Rep Nat)
dGEnum'_Rep_Nat)
where
dReprNat :: Representable Nat
dGEnum'Nat :: GEnum' (Rep Nat)
}}}
Which of these is chosen depends on accidental things in the constraint
solver; it's not supposed to matter.
But it DOES affect whether the `map/(|||)` rule fires.
{{{
{-# RULES ft ||| forall f a b. map f (a ||| b) = map f a ||| map f b #-}
}}}
It makes a difference because in (A) we have an instance for `GEnum'
RepNat` that uses `|||` directly,
{{{
instance (GEnum' f, GEnum' g) = GEnum' (f :+: g) where
genum' = map L genum' ||| map R genum'
}}}
so we get
{{{
map ... (blah1 ||| blah2)
}}}
But in (B) we need an instance for `GEnum' (Rep Nat)` and that has an
extra cast, so we get
{{{
map ... ((blah1 ||| blah2) | g)
}}}
And the cast stops the RULE for `map/(|||)` firing.
== Parametricity to the rescue ==
Note that `(|||) :: [a] - [a] - [a]`. So by parametricity we know that
{{{
if g :: [T1] ~ [T2]
then
((|||) @T1 xs ys | g)
=
((|||) @T2 (xs | g) (ys | g)
}}}
If we used that to push the cast inwards, the RULE would match.
Likewise, map is polymorphic: `map :: (a-b) - [a] - [b]`
So by parametricity
{{{
if :: [T1] - [T2]
then
map @T2 @TR f (xs | g)]
=
map @T1 @TR (f | sym (right g) - TR) xs
}}}
If we used that to move the cast out of the way, the RULE would match too.
But GHC is nowhere near clever enough to do either of these things. And
it's far from obvious what to do in general.
== Bottom line ==
The choices made by the constraint solver can affect exactly where casts
are inserted into the code. GHC knows how to move casts around to stop
them getting in the way of its own transformations, but is helpless if
they get in the way of RULES.
I am really not sure how to deal with this. But it is very interesting!
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5974
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] #2110: Rules to eliminate casted id's
#2110: Rules to eliminate casted id's -+-- Reporter: igloo | Owner: Type: feature request | Status: new Priority: lowest| Milestone: 7.6.1 Component: Compiler | Version: 6.8.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonpj): I'm not sure it makes sense for an undergrad thesis. * It's clear what FC (Core) code to generate. The trick is to find a nice source-language design that feels easy and intuitive, and from which we can generate the right FC. Undergrads aren't going to be able to do that. * Adding type-variable binders in rules is fiddly, but not very glamorous. And to be fair I am a bit concerned about dealing with an undergrad patch to the typechecker, one of the more complicated bits of GHC. There are lots of other open tickets at [wiki:Status/SLPJ-Tickets] if you are interested in a list of open questions. But most of them are tricky in some way, or I'd have done them :-) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2110#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] #2110: Rules to eliminate casted id's
#2110: Rules to eliminate casted id's -+-- Reporter: igloo | Owner: Type: feature request | Status: new Priority: lowest| Milestone: 7.6.1 Component: Compiler | Version: 6.8.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonpj): See also #5974 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2110#comment:16 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] #5974: Casts, rules, and parametricity
#5974: Casts, rules, and parametricity -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonpj): See also #2110 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5974#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] #5960: Show instance for Digraph.Forest overlaps with Show [a]
#5960: Show instance for Digraph.Forest overlaps with Show [a]
--+-
Reporter: SimonHengel | Owner:
Type: bug | Status: new
Priority: normal| Component: GHC API
Version: 7.4.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
Comment(by simonpj@…):
commit 4ecfc7ffab0b8578490f7fbe8aa8912f4af1a76a
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Mar 28 07:02:23 2012 +0100
Remove Show instance for Forest
A Forest is just a list, and we have a Show instance for
lists already. We don't need a special Show instance for
Forests. If we change our minds we can add a newtype,
but I don't think it's worth it.
Fixes Trac #5960
compiler/utils/Digraph.lhs |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5960#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] #5960: Show instance for Digraph.Forest overlaps with Show [a]
#5960: Show instance for Digraph.Forest overlaps with Show [a] ---+ Reporter: SimonHengel | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: GHC API |Version: 7.4.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 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5960#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] #4862: Enable usage of gold linker with GHC
#4862: Enable usage of gold linker with GHC --+- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.4.1 Component: Compiler |Version: 7.0.1 Resolution: | Keywords: Os: Linux| Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Testcase: | Blockedby: Blocking: |Related: --+- Changes (by Veinor): * status: closed = new * resolution: worksforme = Comment: I have /usr/local/bin/ld aliased to gold, and I get `/usr/local/bin/ld: --hash-size=31: unknown option` when I try to run yesod devel on my yesod project; it looks like gold doesn't know about --hash-size. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4862#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
Re: [GHC] #5932: closure_type_names in Printer.c has BLACKHOLE and BLOCKING_QUEUE swapped
#5932: closure_type_names in Printer.c has BLACKHOLE and BLOCKING_QUEUE swapped ---+ Reporter: nomeata | Owner: simonmar Type: bug | Status: closed Priority: normal| Milestone: 7.4.2 Component: Runtime System|Version: 7.4.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by pcapriotti): * status: merge = closed * resolution: = fixed Comment: Merged as ef0ded714687ecf45c99bd61589e55ffe25a94f7. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5932#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] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by simonmar): One thought occurred to me: maybe if we set the size of the `_dsp` symbol to be the size of the info table plus the size of the code, that would prevent `ld` from separating them. But, as far as I can tell, symbols do not have sizes in Mach-O. I'm a bit bemused at how the linker can get away with reordering code within an object file. The behaviour seems to be inconsistent with the man page for ld, which says The object files are loaded in the order in which they are specified on the command line. The segments and the sections in those segments will appear in the output file in the order they are encountered in the object files being linked. [...] The use of the -order_file option will alter the layout rules above, and move the symbols specified to start of their section. which doesn't explicitly say that code within a section will not be reordered, but it strongly implies that. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:24 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] #4076: Add Applicative instance for STM
#4076: Add Applicative instance for STM ---+ Reporter: basvandijk| Owner: simonmar Type: proposal | Status: closed Priority: normal| Milestone: Component: libraries/base|Version: 6.12.2 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * difficulty: = Unknown Comment: Replying to [comment:5 Lemming]: I am still using GHC-6.12.3. How about adding an orphan instance to the stm package that is defined for the GHC versions that do not provide the Applicative instance? Patches welcome... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4076#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] #5843: hGetBufSome blocks when all available input is buffered (on Windows only)
#5843: hGetBufSome blocks when all available input is buffered (on Windows only) --+- Reporter: joeyadams| Owner: pcapriotti Type: bug | Status: closed Priority: high | Milestone: 7.4.2 Component: libraries/base |Version: 7.2.2 Resolution: fixed| Keywords: Os: Windows | Architecture: x86 Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by pcapriotti): * status: merge = closed * resolution: = fixed Comment: Merged as bd399cef9d91060a3d733be4c18cb901a2efbbc8. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5843#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] #5534: ghci -fobject-code strangeness
#5534: ghci -fobject-code strangeness ---+ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.4.2 Component: GHCi |Version: 7.2.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by pcapriotti): * status: merge = closed * resolution: = fixed Comment: Merged as 7aa0047fcb5d70248156480ffdbf6f7b16f56262. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5534#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] #5790: Missing document about .eventlog's u flag
#5790: Missing document about .eventlog's u flag +--- Reporter: shelarcy | Owner: duncan Type: bug| Status: closed Priority: highest| Milestone: 7.4.2 Component: Documentation |Version: 7.4.1-rc1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by pcapriotti): * status: merge = closed * resolution: = fixed Comment: Merged as 49b9a36c1c8e390d5b4f79606e4cb8a813179b9d. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5790#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
[GHC] #5975: ghci can't load file whose name contains non-ASCII chars?
#5975: ghci can't load file whose name contains non-ASCII chars?
--+-
Reporter: j.waldmann| Owner:
Type: bug | Status: new
Priority: normal| Component: GHCi
Version: 7.4.1 | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
http://thread.gmane.org/gmane.comp.lang.haskell.cafe/97465
The file name contains O-umlaut,
and the OS handles it fine, but ghci does not like it
(although it accepts umlauts in the contents of the file
(UTF-8) e.g., as a module name)
{{{
$ cat fÖÖbar.hs
main = print $ product [1..100]
$ ghci fÖÖbar.hs
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
no location info: can't find file: f??bar.hs
Failed, modules loaded: none.
}}}
this is on a standard ubuntu install (11.10 and 11.04) with
{{{
$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=en_US.UTF-8
...
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
$ uname -a
Linux octopus 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5975
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] #5976: GHC compiler panic when using {-# UNPACK #-} and template Haskell
#5976: GHC compiler panic when using {-# UNPACK #-} and template Haskell
+---
Reporter: SimonMeier | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.4.1 | Keywords:
Os: Linux | Architecture: Unknown/Multiple
Failure: Compile-time crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
GhcBangBug.hs:1:1:ghc: panic! (the 'impossible' happened)
(GHC version 7.4.1 for x86_64-unknown-linux):
Could not convert (Strict,Type) to BangType
(Unpacked,ConT GHC.Types.Int)
Language/Haskell/Convert.hs:(64,5)-(65,42): Non-exhaustive patterns in
function conv
See attached test file for further information.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5976
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] #5865: threadDelay is disrupted by system clock changes
#5865: threadDelay is disrupted by system clock changes -+-- Reporter: joeyadams | Owner: pcapriotti Type: bug | Status: patch Priority: high | Milestone: 7.4.2 Component: Runtime System| Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by pcapriotti): Updated win32 patch so that it falls back to `GetTickCount` (with a 64-bit accumulator). Using `GetTickCount` should be perfectly safe, since it's impossible to delay more than 2^31 μs (less than 6 hours), because `threadDelay` takes an `Int`. Incidentally, `GetTickCount` also seems unaffected by changes in the system clock, so the only difference would be in accuracy. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5865#comment:16 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] #5975: ghci can't load file whose name contains non-ASCII chars?
#5975: ghci can't load file whose name contains non-ASCII chars?
--+-
Reporter: j.waldmann| Owner:
Type: bug | Status: new
Priority: normal| Component: GHCi
Version: 7.4.1 | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
Comment(by j.waldmann):
http://article.gmane.org/gmane.comp.lang.haskell.cafe/97474
I looks like GHC correctly decodes command line parameters and then
truncates them to 8-bit.
{{{
$ ghci ффф
command line:
Could not find module `DDD'
fromEnum 'ф' `mod` 256 == fromEnum 'D'
True
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5975#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] #5959: GHC Panic: nameModule
#5959: GHC Panic: nameModule
---+
Reporter: mightybyte | Owner: pcapriotti
Type: bug | Status: new
Priority: high| Milestone: 7.4.2
Component: Compiler| Version: 7.4.1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Compile-time crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by simonpj@…):
commit cb5a3f2d66e4dac2f6f44f56e365d18df884c943
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Mar 28 09:57:57 2012 +0100
Make the LocalRdrEnv keep track of all the Names that are in scope
This allows us to give a sensible error message when a Template
Haskell
splice generates an occurrence without a binding site.
Fixes Trac #5959 and #5971
compiler/basicTypes/Name.lhs|2 +-
compiler/basicTypes/RdrName.lhs | 36
+---
compiler/rename/RnEnv.lhs | 25 ++---
compiler/rename/RnNames.lhs |6 +++---
compiler/rename/RnTypes.lhs |2 +-
5 files changed, 52 insertions(+), 19 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5959#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] #5971: Referencing a newName in a VarE without definition triggers the impossible happened
#5971: Referencing a newName in a VarE without definition triggers the
impossible
happened
+---
Reporter: josh| Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.4.1 | Keywords:
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: Compile-time crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
Comment(by simonpj@…):
commit cb5a3f2d66e4dac2f6f44f56e365d18df884c943
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Mar 28 09:57:57 2012 +0100
Make the LocalRdrEnv keep track of all the Names that are in scope
This allows us to give a sensible error message when a Template
Haskell
splice generates an occurrence without a binding site.
Fixes Trac #5959 and #5971
compiler/basicTypes/Name.lhs|2 +-
compiler/basicTypes/RdrName.lhs | 36
+---
compiler/rename/RnEnv.lhs | 25 ++---
compiler/rename/RnNames.lhs |6 +++---
compiler/rename/RnTypes.lhs |2 +-
5 files changed, 52 insertions(+), 19 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5971#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] #5970: Type checker hangs
#5970: Type checker hangs
+---
Reporter: Lemming | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type checker) | Version: 7.4.1
Keywords: | Os: Linux
Architecture: x86 | Failure: Compile-time
performance bug
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
+---
Comment(by simonpj@…):
commit 516d3138473d7b097cc572901bd02fce9509f1b8
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Mar 28 09:56:14 2012 +0100
Add a crucial forkM on the superclass context of IfaceClass in
tcIfaceDecl
The absence of this was causing a loop when typechecking an interface
where the superclass context mentioned an associated type
class C (T a) = D a where
data T a
Fixes Trac #5970
compiler/iface/BuildTyCl.lhs |7 +++
compiler/iface/LoadIface.lhs |2 +-
compiler/iface/TcIface.lhs | 36
+---
compiler/typecheck/FamInst.lhs |3 +++
4 files changed, 32 insertions(+), 16 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5970#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] #5970: Type checker hangs
#5970: Type checker hangs +--- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.4.1 Keywords: | Os: Linux Architecture: x86 | Failure: Compile-time performance bug Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Comment(by simonpj): Darn. This commit doesn't fix this ticket (#5970). It fixes #5955. So ignore teh above commit. Sorry. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5970#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] #5955: Renamer hangs when checking type family consistency
#5955: Renamer hangs when checking type family consistency
-+--
Reporter: gmainland | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler|Version: 7.5
Resolution: fixed | Keywords:
Os: Unknown/Multiple| Architecture:
Unknown/Multiple
Failure: None/Unknown| Difficulty: Unknown
Testcase: indexed-types/should_compile/T5955 | Blockedby:
Blocking: |Related:
-+--
Changes (by simonpj):
* status: new = closed
* difficulty: = Unknown
* resolution: = fixed
* testcase: = indexed-types/should_compile/T5955
Comment:
Fixed by
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Mar 28 09:56:14 2012 +0100
Add a crucial forkM on the superclass context of IfaceClass in
tcIfaceDecl
The absence of this was causing a loop when typechecking an interface
where the superclass context mentioned an associated type
class C (T a) = D a where
data T a
Fixes Trac #5970
compiler/iface/BuildTyCl.lhs |7 +++
compiler/iface/LoadIface.lhs |2 +-
compiler/iface/TcIface.lhs | 36
+---
compiler/typecheck/FamInst.lhs |3 +++
4 files changed, 32 insertions(+), 16 deletions(-)
}}}
The comment is wrong when it mentions #5970; the patch fixes this ticket
#5955.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5955#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] #5971: Referencing a newName in a VarE without definition triggers the impossible happened
#5971: Referencing a newName in a VarE without definition triggers the impossible happened -+-- Reporter: josh| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.4.1 Resolution: fixed | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: th/T5971| Blockedby: Blocking: |Related: -+-- Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = fixed * testcase: = th/T5971 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5971#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] #5959: GHC Panic: nameModule
#5959: GHC Panic: nameModule
---+
Reporter: mightybyte | Owner: pcapriotti
Type: bug | Status: new
Priority: high| Milestone: 7.4.2
Component: Compiler| Version: 7.4.1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Compile-time crash
Difficulty: Unknown |Testcase: th/T5971
Blockedby: |Blocking:
Related: |
---+
Changes (by simonpj):
* testcase: = th/T5971
Comment:
New error message is:
{{{
T5959.hs:8:1:
The exact Name `b_aUU' is not in scope
Probable cause: you used a unique name (NameU) in Template Haskell
but did not bind it
}}}
This isn't as good as the new message in #5971, which is
{{{
T5971.hs:6:7:
The exact Name `x_aOV' is not in scope
Probable cause: you used newName in Template Haskell but did not
bind it
In the result of the splice:
$(newName x = varE)
To see what the splice expanded to, use -ddump-splices
In the expression: $(newName x = varE)
In a pattern binding: _ = $(newName x = varE)
}}}
Sadly there is a reason that it's not quite as good in this case. In this
case, #5959, there's a top-level declaration splice, which is renamed in a
mutually recursive group with the declarations that follow. So this
works:
{{{
$(f 4) -- Expands to: h x = g (x-1)
g x = h x
}}}
So the splice expands to a declaration that uses the declarations that
follow the splice.
I think it likely that this feature is never used, but it means that we
can't wrap the helpful context info around when we rename the splice
itself. Sigh.
I'm going to leave the ticket open for now... maybe it would be better to
rename and typecheck the result of a top-level splice all by itself?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5959#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
Re: [GHC] #5976: GHC compiler panic when using {-# UNPACK #-} and template Haskell
#5976: GHC compiler panic when using {-# UNPACK #-} and template Haskell
-+--
Reporter: SimonMeier | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler|Version: 7.4.1
Resolution: invalid | Keywords:
Os: Linux | Architecture: Unknown/Multiple
Failure: Compile-time crash | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
-+--
Changes (by simonpj):
* status: new = closed
* difficulty: = Unknown
* resolution: = invalid
Comment:
Looks like a bug in module `Language.Haskell.Convert`, which I don't
recognise.
Why do you think it's a GHC bug? I'm closing as invalid but re-open if
you think it's a GHC bug.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5976#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] #5964: Documentation: DatatypeContexts is NOT on by default in 7.4.1
#5964: Documentation: DatatypeContexts is NOT on by default in 7.4.1 -+-- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Documentation | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * difficulty: = Unknown Comment: I believe `DataTypeContexts` were removed in Haskell 2010, which is GHC's default. Use `-XHaskell98` to get Haskell 98. Ian, or Paolo: could you check, and update the documentation appropriately? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5964#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] #5961: GHC panic (nameModule) on malformed deriving clause
#5961: GHC panic (nameModule) on malformed deriving clause
-+--
Reporter: Philonous | Owner:
Type: bug | Status: closed
Priority: normal | Milestone: 7.6.1
Component: Compiler|Version: 7.4.1
Resolution: fixed | Keywords:
Os: Linux | Architecture: Unknown/Multiple
Failure: Compile-time crash | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
-+--
Changes (by simonpj):
* status: new = closed
* resolution: = fixed
Comment:
Indeed:
{{{
T5961.hs:2:26:
Illegal deriving item `abc'
In the data declaration for `Foo'
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5961#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] #5964: Documentation: DatatypeContexts is NOT on by default in 7.4.1
#5964: Documentation: DatatypeContexts is NOT on by default in 7.4.1
-+--
Reporter: dagit | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Documentation | Version: 7.4.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by pcapriotti):
Data type contexts are in Haskell 2010, AFAICT:
{{{
topdecl → type simpletype = type
| data [context =] simpletype [= constrs] [deriving]
...
}}}
but at the moment they are not only off by default, but deprecated. Should
we change the behavior or the documentation?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5964#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] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability ()
-+--
Reporter: j.waldmann | Owner: simonmar
Type: bug | Status: new
Priority: high| Milestone: 7.4.2
Component: Runtime System |Version: 7.4.1
Resolution: | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Runtime crash | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
-+--
Comment(by marlowsd@…):
commit 734f1d484b12b785795b249b4116cfb4817ab55d
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Mar 28 11:45:39 2012 +0100
Fix a bug in threadStackOverflow() (maybe #5214)
If we overflow the current stack chunk and copy its entire contents
into the next stack chunk, we could end up with two UNDERFLOW_FRAMEs.
We had a special case to catch this in the case when the old stack
chunk was the last one (ending in STOP_FRAME), but it went wrong for
other chunks.
I found this bug while poking around in the core dump attached to
options and running the nofib suite: imaginary/wheel_sieve2 crashed
with +RTS -kc600 -kb300.
I don't know if this is the cause of all the symptoms reported in
rts/Threads.c | 35 ++-
1 files changed, 22 insertions(+), 13 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#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
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () -+-- Reporter: j.waldmann | Owner: simonmar Type: bug | Status: merge Priority: high| Milestone: 7.4.2 Component: Runtime System |Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by simonmar): * status: new = merge Comment: @vshabanov: thanks very much for the core dump. I poked around in it and did manage to find a bug in the RTS, the fix for which I have just committed (see above). I don't know whether this is the only bug, but it is certainly ''a'' bug. We'll close the ticket after the patch has been merged, on the optimistic assumption that the bug is fixed. Please try again with the 7.4.2 release candidate if possible, and re-open the ticket if you still have problems. Thanks again for the report. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#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] #5975: ghci can't load file whose name contains non-ASCII chars?
#5975: ghci can't load file whose name contains non-ASCII chars? ---+ Reporter: j.waldmann | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi| Version: 7.4.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by pcapriotti): * status: new = patch * difficulty: = Unknown Comment: The attached patch fixes the problem. I'm not quite sure what the extra encoding/decoding step was for in the original code. As it stands, it just truncates input strings `Char` to `Word8`, so it breaks for non-ascii characters in utf-8 (say). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5975#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] #5934: ghc: panic! (the 'impossible' happened)
#5934: ghc: panic! (the 'impossible' happened)
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler| Version: 7.4.1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Compile-time crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by simonpj):
* cc: dimitris@… (added)
* difficulty: = Unknown
Comment:
Thanks. I know what is going on here. Will fix as part of the
refactoring Dimitrios is doing on the constraint solver.
Simon
Her's a standalone test case
{{{
{-# LANGUAGE RankNTypes, TypeFamilies, KindSignatures #-}
module T5934 where
import Control.Monad.ST
data Gen s
type GenST s = Gen (PrimState (ST s))
run :: (forall s . GenST s) - Int
run = 0
type family PrimState (m :: * - *)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5934#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] #5946: getAnyProcessStatus signals an exception
#5946: getAnyProcessStatus signals an exception
---+
Reporter: toc | Owner: simonmar
Type: bug | Status: merge
Priority: high| Milestone: 7.4.2
Component: libraries/unix | Version: 7.0.4
Keywords: | Os: Unknown/Multiple
Architecture: x86_64 (amd64) | Failure: Runtime crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by simonmar):
* status: new = merge
Comment:
Fixed the docs:
{{{
commit e518038a0eca7dddbbd3d4326355db9c1d6f0068
Author: Simon Marlow marlo...@gmail.com
Date: Fri Mar 23 15:10:17 2012 +
fix documentation for getAnyProcessStatus/getGroupProcessStatus
(#5946)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5946#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] #5926: Add strict versions of modifyIORef and atomicModifyIORef
#5926: Add strict versions of modifyIORef and atomicModifyIORef
--+-
Reporter: joeyadams| Owner: simonmar
Type: feature request | Status: closed
Priority: normal | Milestone: 7.6.1
Component: libraries/base |Version: 7.4.1
Resolution: fixed| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
{{{
commit 531c09ed708b394c43775c2e07f14a39256bc498
Author: Joey Adams joeyadams3.14...@gmail.com
Date: Sat Mar 10 19:15:40 2012 -0500
Add strict versions of modifyIORef and atomicModifyIORef
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5926#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] #5964: Documentation: DatatypeContexts is NOT on by default in 7.4.1
#5964: Documentation: DatatypeContexts is NOT on by default in 7.4.1
-+--
Reporter: dagit | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Documentation | Version: 7.4.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonpj):
Oh bother. I suppose they should be on by default. The ''flag'' elicits
the deprecation
{{{
Warning: -XDatatypeContexts is deprecated: It was widely
considered a misfeature, and has been removed from the Haskell
language.
}}}
but that seems to be a lie, since it has not yet been removed.
I'd be happy to emit a deprecation at any ''use'' of a context, along the
lines of
{{{
Warning: contexts on data types are a mis-feature of Haskell,
and may be removed. You might want to remove it now!
}}}
along with enough location/context info to identify what's being referred
to.
Or just add `DatatypeContexts` to the default Haskell 2010 flags, and nuke
the deprecation altogether; it's really not very important, and not worth
burning cycles on.
-- but I suggest we continue to deprecate them. They really are a mis-
feature.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5964#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] #5688: instance Read Integer/Rational/Double readsPrec out of memory and crash due to exponential notation
#5688: instance Read Integer/Rational/Double readsPrec out of memory and crash
due
to exponential notation
---+
Reporter: gracjan | Owner: igloo
Type: bug | Status: closed
Priority: highest | Milestone: 7.4.2
Component: libraries/base|Version: 6.12.3
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime crash | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by igloo):
* status: merge = closed
* resolution: = fixed
Comment:
Backported as:
{{{
commit 6cb84cb399c42a764a80b8b34cf67e9f0e9a3ed4
Author: Ian Lynagh ig...@earth.li
Date: Wed Mar 28 16:11:34 2012 +0100
Backport the Read Integer/Double/Float change for 123e456
For the 7.4 branch, I've fixed this in a less pleaseant way, in order
to avoid changing the library interfaces.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5688#comment:64
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] #5964: Documentation: DatatypeContexts is NOT on by default in 7.4.1
#5964: Documentation: DatatypeContexts is NOT on by default in 7.4.1 -+-- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Documentation | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by dagit): From my perspective as a user: I would say it's easiest for the docs to get updated to match the current behavior. It's unfortunate that we don't have a stable release (other than perhaps 7.2.x which I won't count), that had this deprecated before it was off by default. But, now that it's been off by default for at least one release I've been purging its use in any library I come across. So getting the feature back in the next release as deprecated doesn't help me in terms of supporting multiple versions of ghc. In other words, this feature is already dead to me. I say just leave it off. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5964#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] #5976: GHC compiler panic when using {-# UNPACK #-} and template Haskell
#5976: GHC compiler panic when using {-# UNPACK #-} and template Haskell
-+--
Reporter: SimonMeier | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler|Version: 7.4.1
Resolution: | Keywords:
Os: Linux | Architecture: Unknown/Multiple
Failure: Compile-time crash | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
-+--
Changes (by SimonMeier):
* status: closed = new
* resolution: invalid =
Comment:
Replying to [comment:1 simonpj]:
Looks like a bug in module `Language.Haskell.Convert`, which I don't
recognise.
You are right. This module is part of the `derive` package
(http://hackage.haskell.org/package/derive).
Why do you think it's a GHC bug? I'm closing as invalid but re-open if
you think it's a GHC bug.
I thought it's a GHC bug because the error message was:
GhcBangBug.hs:1:1:ghc: panic! (the 'impossible' happened)
(GHC version 7.4.1 for x86_64-unknown-linux):
Could not convert (Strict,Type) to BangType
(Unpacked,ConT GHC.Types.Int)
Language/Haskell/Convert.hs:(64,5)-(65,42): Non-exhaustive patterns in
function conv
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
It seems as if the pattern match failure from executing the template
haskell function bubbled up too high and led to this (partially)
misleading error message. It seems that this is indeed a bug, as such a
failure should lead to a standard compile error instead of a GHC panic. I
would expect something along the line:
Exception during execution of template haskell splice `..splice code':
...explanation of the exception
Best regards,
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5976#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] #5965: pref-llvm failed at integer-gmp-0.3.0.0: stored value and pointer type do not match
#5965: pref-llvm failed at integer-gmp-0.3.0.0: stored value and pointer type do not match ---+ Reporter: Favonia |Owner: dterei Type: bug | Status: closed Priority: normal |Component: Compiler (LLVM) Version: 7.5 | Resolution: fixed Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Building GHC failed Testcase: |Blockedby: Blocking: | Related: ---+ Changes (by dterei): * status: new = closed * resolution: = fixed Comment: OK recent win64 fixes by Ian did this, specifically: 216150a6dc2c59a5ade398cad849a0c093572d12 He truncates an Long (64bit) to an Int (32bit) and stores it back in a Long. As this is in Cmm which plugs directly into the backends you can't have automatic type conversion like this with LLVM (NCG doesn't care). I've changed the storage type to be an Int as well, see commit: 121cd52f9ae00ff0d6d072cc51939fb887db3fba -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5965#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] #5965: pref-llvm failed at integer-gmp-0.3.0.0: stored value and pointer type do not match
#5965: pref-llvm failed at integer-gmp-0.3.0.0: stored value and pointer type do not match --+- Reporter: Favonia | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: libraries (other)|Version: 7.5 Resolution: | Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: Building GHC failed | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by igloo): * status: closed = new * component: Compiler (LLVM) = libraries (other) * priority: normal = highest * difficulty: = Unknown * milestone: = 7.6.1 * owner: dterei = * resolution: fixed = Comment: Oh, sorry, I probably meant to fix that better later and then forgot. I'm not sure the fix is right, though: The GMP function is presumably expecting a long, not an int. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5965#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
[GHC] #5977: Allow ignoring global package db
#5977: Allow ignoring global package db
--+-
Reporter: duncan| Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 7.4.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
For sandboxing, users want to be able to use only local package dbs. To
handle rts, base etc, they copy those specific packages from the global
package db into a local package db.
Currently however there is no sensible way to tell ghc to look '''only'''
at the listed package dbs, and not the global db. There is a flag `-no-
user-package-conf` to avoid looking at the per-user one, but no equivalent
to ignore or to specify the global one.
(Note: as a quirky non-sensible way, you can use `GHC_PACKAGE_PATH=` to
clear the package db stack, but this should be possible using command line
flags.)
The user interface we're now using in cabal is like this:
* `--global` sets the initial db stack to `[GlobalPackageDB]`
* `--user` sets the initial db stack to `[GlobalPackageDB,
UserPackageDB]`
* `--package-db=clear` clears the db stack to `[]`
* `--package-db=global` pushes `GlobalPackageDB` on the top of the stack
* `--package-db=user` pushes `UserPackageDB` on the top of the stack
* `--package-db=`''${otherfile}'' pushes `SpecificPackageDB`
''${otherfile}'' on the top of the stack
It seems to me we could do something similar with ghc. Currently in ghc we
have a `-hide-all-packages` flag that resets the package set to empty. We
could do with an equivalent for the package database stack. I suggest
something like:
* `-clear-package-conf`
* `-global-package-conf`
* `-user-package-conf` (and the existing `-no-user-package-conf`)
* `-package-conf` file
The default would remain that the global and user dbs are used, but this
can be reset using `-clear-package-conf`.
Personally I prefer the nomenclarture package db rather than package
conf here, but it's not that important.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5977
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] #5978: Type error in one function causes wrong type error report in another function in the presence of functionally dependent types
#5978: Type error in one function causes wrong type error report in another
function in the presence of functionally dependent types
---+
Reporter: Lemming| Owner:
Type: bug| Status: new
Priority: normal | Component: Compiler (Type
checker)
Version: 7.4.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHC rejects valid program | Testcase:
Blockedby: | Blocking:
Related: |
---+
When trying to reduce my problem in #5970 to a simple program I
encountered an even more obvious bug. The problem is essentially as
follows: I have
{{{
correct :: T
correct = ...
wrong :: T
wrong = f correct
}}}
where 'wrong' has a type error and 'correct' is type correct. If I
outcomment 'wrong' then GHC correctly confirms type-correctness of
'correct', but if 'wrong' is enabled then GHC claims a type error in both
'wrong' and 'correct'.
To me it looks like the type-checker is trying to unify types across
function boundaries. This would explain both non-linear growth of type-
checking time and the observed effect of incorrect type errors.
See attached program for a working example.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5978
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] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by chak): Replying to [comment:24 simonmar]: I'm a bit bemused at how the linker can get away with reordering code within an object file. The behaviour seems to be inconsistent with the man page for ld, which says The object files are loaded in the order in which they are specified on the command line. The segments and the sections in those segments will appear in the output file in the order they are encountered in the object files being linked. [...] The use of the -order_file option will alter the layout rules above, and move the symbols specified to start of their section. which doesn't explicitly say that code within a section will not be reordered, but it strongly implies that. But don't the `-no_order_inits` and `-no_order_data` options make it clear that reordering within sections is happening? In fact, can't we use `-order_file` to solve this problem once and for all? -order_file file Alters the order in which functions and data are laid out. For each section in the output file, any symbol in that sec- tion that are specified in the order file file is moved to the start of its section and laid out in the same order as in the order file file. Order files are text files with one symbol name per line. Lines starting with a # are comments. A symbol name may be optionally preceded with its object file leaf name and a colon (e.g. foo.o:_foo). This is useful for static functions/data that occur in multiple files. A symbol name may also be optionally preceded with the architecture (e.g. ppc:_foo or ppc:foo.o:_foo). This enables you to have one order file that works for multiple architectures. Lit- eral c-strings may be ordered by by quoting the string (e.g. Hello, world\n) in the order file. In fact, the man page makes it sound as if we can achieve TNTC without any hacks using an order file on OS X. Or am I missing something? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:25 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] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by Irene): Well, we can indeed do it with an order file, but it's unwieldy to have to construct one that encompasses every single module being linked, and then it breaks again if linked again, as for example happens if we build a Haskell library that an innocent and well-meaning author tries to link into a C program without GHC's involvement. Actually, I'm not sure how we can make that scenario work even with some sort of way to tell LLVM explicitly about TNTC, since the Mach-O format doesn't have any way to express that constraint, so it will never survive to a second linking. But the main reason to not use an order file is that the reordering probably actually does provide a good benefit, since (I assume but nobody's actually explained it that I've seen) it does things such as providing additional code locality so as to keep things within the processor's instruction cache more often. It can also do whole-program dead-code removal. This sort of feature, which the LLVM people call link- time optimization (LTO), is defeated if we tell it it can't actually do anything. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:26 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] #5965: pref-llvm failed at integer-gmp-0.3.0.0: stored value and pointer type do not match
#5965: pref-llvm failed at integer-gmp-0.3.0.0: stored value and pointer type do
not match
--+-
Reporter: Favonia | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 7.6.1
Component: libraries (other)|Version: 7.5
Resolution: | Keywords:
Os: Linux| Architecture: x86_64 (amd64)
Failure: Building GHC failed | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by dterei):
hmmm I wasn't sure here either, the docs for the GMP function specify some
strange type for the function def.
If it is expecting a long I guess we should apply two casts to keep the
physical storage the same but truncate it to 32bit representation.
From [http://gmplib.org/manual/Integer-Arithmetic.html#Integer-Arithmetic
GMP Docs]:
{{{
Function: void mpz_mul_2exp (mpz_t rop, mpz_t op1, mp_bitcnt_t op2)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5965#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] #5965: pref-llvm failed at integer-gmp-0.3.0.0: stored value and pointer type do not match
#5965: pref-llvm failed at integer-gmp-0.3.0.0: stored value and pointer type do
not match
--+-
Reporter: Favonia | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 7.6.1
Component: libraries (other)|Version: 7.5
Resolution: | Keywords:
Os: Linux| Architecture: x86_64 (amd64)
Failure: Building GHC failed | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by dterei):
OK also from GMP Docs:
{{{
Counts of bits of a multi-precision number are represented in the C type
mp_bitcnt_t. Currently this is always an unsigned long, but on some
systems it will be an unsigned long long in the future.
}}}
So I guess we should apply two casts. The other option is to add code to
the LLVM backend to handle doing implicit coercions making it compatible
with NCG as bugs of this nature come up every few months. However I'd like
to avoid that as its only the hand written cmm code that it can occur in
so for now dealing with these on a case by case basis seems OK.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5965#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] #5965: pref-llvm failed at integer-gmp-0.3.0.0: stored value and pointer type do not match
#5965: pref-llvm failed at integer-gmp-0.3.0.0: stored value and pointer type do not match --+- Reporter: Favonia | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: libraries (other)|Version: 7.5 Resolution: | Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: Building GHC failed | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by dterei): Igloo should I handle this or will you handle? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5965#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
