Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): I doubt it's the fusion framework (which does work, just not as well as it used to before the typechecker patch). If the ghc package is getting linked in then that is probably the reason for the binary size. The package is only used for one thing by vector: annotations to drive !SpecConstr. That is, I only use a single data type and no functions from package ghc. Why would GHC link in the entire package in that case? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4370: Bring back monad comprehensions
#4370: Bring back monad comprehensions -+-- Reporter: simonpj |Owner: nsch Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by nsch): * owner: = nsch Comment: Thank you for the detailed reply, Simon. I'm currently working for George and his research group and I'm going to take on this task in the next couple of weeks. Those advices will be a great help. - Nils Schweinsberg -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4370#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonpj): Moreover, the annotations stuff, and hence the `ghc` package is only used at ''compile time''. So it should not be linked at run time. There should be literally no references to `ghc` in the `.o` files, so it should not be linked at all. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar |Owner: vivian
Type: feature request | Status: patch
Priority: normal|Milestone: 7.2.1
Component: GHCi | Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by vivian):
How does implementing simonmar's suggestion impact upon #3984? It seems
that it renders it obsolete. Should the patch include removing the {{{:{
}:}}} construct?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#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] #4346: Behaviour of INLINABLE depends on whether the modules included are already compiled.
#4346: Behaviour of INLINABLE depends on whether the modules included are
already
compiled.
-+--
Reporter: milan |Owner: simonmar
Type: bug | Status: merge
Priority: high |Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Changes (by simonmar):
* status: new = merge
Comment:
Fixed - thanks for a great report, and well done for spotting the problem.
{{{
Fri Oct 15 10:48:36 BST 2010 Simon Marlow marlo...@gmail.com
* Fix #4346 (INLINABLE pragma not behaving consistently)
Debugged thanks to lots of help from Simon PJ: we weren't updating the
UnfoldingGuidance when the unfolding changed.
Also, a bit of refactoring and additinoal comments.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4346#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] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: vivian Type: feature request | Status: patch Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonmar): I don't know how well Haskeline will cope with multi-line input. Ideally you want Haskeline to be able to navigate and edit the complete multi-line expression. Also I'm not sure how layout should behave with the prompt, because the first line is already indented: should subsequent lines be indented by the width of the prompt, or should there be a special multi-line continuation prompt? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:17 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by daniel.is.fischer):
FWIW:
{{{
$ ghc -O2 -package vector-0.7 -package base-4.2.0.2 -o aaa6 aaavec.hs
$ ls -l | grep aaa6
-rwxr-xr-x 1 dafis users 1115927 15. Okt 12:16 aaa6
$ nm aaa6 | wc -l
10110
$ nm aaa6 | grep ghc | wc -l
65
$ ~/Haskell/Hacking/bin/ghc -O2 --make aaavec.hs -o aaa7
$ ls -l | grep aaa7
-rwxr-xr-x 1 dafis users 29180744 15. Okt 12:17 aaa7
$ nm aaa7 | wc -l
332020
$ nm aaa7 | grep ghc | wc -l
65413
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): What happens with -O0? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by daniel.is.fischer):
Not much of a difference:
{{{
$ touch aaavec.hs
$ ghc -O0 -package vector-0.7 -package base-4.2.0.2 -o aaa60 aaavec.hs
$ ls -l | grep aaa60
-rwxr-xr-x 1 dafis users 1207342 15. Okt 13:22 aaa60
$ nm aaa60 | wc -l
11025
$ nm aaa60 | grep ghc | wc -l
65
$ ~/Haskell/Hacking/bin/ghc -O0 --make aaavec.hs -o aaa70
[1 of 1] Compiling Main ( aaavec.hs, aaavec.o )
Linking aaa70 ...
$ ls -l | grep aaa70
-rwxr-xr-x 1 dafis users 29221447 15. Okt 13:23 aaa70
$ nm aaa70 | wc -l
332413
$ nm aaa70 | grep ghc | wc -l
65413
$
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:17
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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): Since fusion/inlining doesn't happen with -O0, that pretty much means that it has to be something else. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:18 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] #4401: Functional dependencies regression
#4401: Functional dependencies regression
-+--
Reporter: rl| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Testcase:
{{{
{-# LANGUAGE FlexibleInstances, UndecidableInstances,
MultiParamTypeClasses, FunctionalDependencies #-}
module Foo where
class Mul x y z | x y - z
class IsType a
class IsType a = IsSized a s | a - s
data Array n a = Array
instance IsSized a s = IsType (Array n a)
instance (IsSized a s, Mul n s ns) = IsSized (Array n a) ns
}}}
ghc-7.0.0.20101014 rejects this with:
{{{
Couldn't match type `s' with `s1'
because this skolem type variable would escape: `s1'
This skolem is bound by the instance declaration
In the instance declaration for `IsSized (Array n a) ns'
}}}
ghc-7.0.0.20101005 and all previous versions accept it. This is from the
llvm package, so is fairly critical.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4401
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] #4397: RULES for Class ops don't fire in HEAD
#4397: RULES for Class ops don't fire in HEAD --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: new Priority: normal |Milestone: Component: Compiler | Version: 7.1 Keywords: RULES, classes | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug --+- Comment(by simonpj): Ah yes I see. Thanks for identifying this flaw. It's all in `Rules.isMoreSpecific`, which looks wrong to me. I'll validate a fix. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4397#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by daniel.is.fischer): I've narrowed it down a bit. Importing Data.Vector.Fusion.Util and Data.Vector.Fusion.Stream.Size gives small executables, importing Data.Vector.Fusion.Stream.Monadic a large one. So something in there triggers it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:19 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonmar): One way to track it down would be to issue the link command manually with the GHC package removed, and see what symbols are missing and where they are referred to from. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:20 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by igloo):
Hmm, with
{{{
$ cat h.hs
import SpecConstr
main = return ()
}}}
I get:
{{{
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$ ghc --make h -package ghc
[1 of 1] Compiling Main ( h.hs, h.o )
Linking h ...
$ nm h | grep ghc | wc -l
59049
$ ls -lh h
-rwxr-xr-x 1 ian ian 32M Oct 15 13:29 h
$ strip h
$ ls -lh h
-rwxr-xr-x 1 ian ian 21M Oct 15 13:29 h
}}}
and:
{{{
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.1.20101014
$ ghc --make h -package ghc
[1 of 1] Compiling Main ( h.hs, h.o )
Linking h ...
$ nm h | grep ghc | wc -l
66744
$ ls -lh h
-rwxr-xr-x 1 ian ian 45M Oct 15 13:30 h
$ strip h
$ ls -lh h
-rwxr-xr-x 1 ian ian 29M Oct 15 13:30 h
}}}
i.e. it looks like it never worked for me.
What does
{{{
ar t `ghc --print-libdir`/ghc-6.12.3/libHSghc-6.12.3.a | wc -l
}}}
say for you?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:21
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] #4318: Crash while building HEAD on OS X
#4318: Crash while building HEAD on OS X ---+ Reporter: gwright |Owner: Type: bug | Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler| Version: 6.13 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Building GHC failed ---+ Comment(by gwright): Now I know what the bug is: relocations of type `X86_64_RELOC_GOT` and `X86_64_RELOC_GOT_LOAD` are not handled by the Mach-O linker. There is a stub of code for these cases, but it does something nonsensical. I'm guessing it was simply never finished. This doesn't seem too hard to fix, but it's fiddly. If I'm lucky and my current hunch works, maybe a patch in a couple of days. Otherwise, I'll need to try to understand Apple's ld64 code to understand these relocations in more detail. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4318#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): Replying to [comment:19 daniel.is.fischer]: I've narrowed it down a bit. Importing Data.Vector.Fusion.Util and Data.Vector.Fusion.Stream.Size gives small executables, importing Data.Vector.Fusion.Stream.Monadic a large one. So something in there triggers it. Stream.Monadic contains annotations, the others don't (they are also rather small). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:22 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by igloo): Oh, never mind, I can reproduce it if I use your testcase above. Curious. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:23 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonpj): Ah.. light dawns. Every module has a module-initialisation routine. Apart from initialising the module, it calls the module-initialisation routine for each imported module. So if M imports module `SpecConstr` from package `ghc`, then the module-initialisatin routine for M will call the initialisation routine for `SpecConstr`. Even though nothing from `SpecConstr` is ultimately used. Hmm. That is bad. I'm not sure what to do about it. The obvious alternative is to call the module-init routine for each `Id` mentioned in the final executable for M. That would solve the problem, but at a cost: every module will call zillions of module initialisers. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by daniel.is.fischer):
Yeah, seems that's it,
{{{
#if __GLASGOW_HASKELL__ = 613
import SpecConstr ( SpecConstrAnnotation(..) )
#endif
}}}
means !SpecConstr isn't actually imported with 6.12.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by josef): It seems to me that what is really needed is a form of compile time imports. Some way to indicate that an imported module will only be used at compile time, for instance to use annotations or to generate code using Template Haskell. Jonas Almström Duregård bumped in to the same problem when using Template Haskell. He needed to import modules for use only at compile time but they where also linked in when the binary was created. Link to email: http://www.haskell.org/pipermail/glasgow-haskell- users/2010-September/019211.html -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): Could we just use `collect2` to collect and execute all initialisers that are linked in? GCC already solves this problem for C++ so perhaps we could simply reuse their mechanism. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:27 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Changes (by igloo): * priority: highest = normal Comment: Aha, not a regression, then, so downgrading priority. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:28 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] #4393: GHCi says: ghc: internal error: evacuate: strange closure type 63587
#4393: GHCi says: ghc: internal error: evacuate: strange closure type 63587 --+- Reporter: chrisdone |Owner: Type: bug| Status: new Priority: normal |Milestone: 7.0.2 Component: GHCi | Version: 6.12.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: GHCi crash --+- Changes (by igloo): * milestone: = 7.0.2 Comment: So am I right in thinking you just have 1 long-running ghci process (inside emacs)? The best first step is probably to see if it still happens with 7.0.1. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4393#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] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: vivian Type: feature request | Status: patch Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by igloo): Replying to [comment:17 simonmar]: Also I'm not sure how layout should behave with the prompt, because the first line is already indented: should subsequent lines be indented by the width of the prompt, or should there be a special multi-line continuation prompt? multi-line continuation prompt sounds best to me. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:18 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] #4401: Functional dependencies regression
#4401: Functional dependencies regression -+-- Reporter: rl|Owner: simonpj Type: bug | Status: new Priority: highest |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * owner: = simonpj * priority: normal = highest * milestone: = 7.0.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4401#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] #4402: Ticket #4252 not fixed for 6.12 branch
#4402: Ticket #4252 not fixed for 6.12 branch -+-- Reporter: dieterle | Owner: Type: bug | Status: merge Priority: normal| Component: Build System Version: 6.12.3|Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by dieterle): * status: new = merge -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4402#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] #4402: Ticket #4252 not fixed for 6.12 branch
#4402: Ticket #4252 not fixed for 6.12 branch ---+ Reporter: dieterle | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Build System |Version: 6.12.3 Resolution:| Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by igloo): * status: merge = new -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4402#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] #4402: Ticket #4252 not fixed for 6.12 branch
#4402: Ticket #4252 not fixed for 6.12 branch ---+ Reporter: dieterle | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Build System |Version: 6.12.3 Resolution: wontfix | Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by igloo): * status: new = closed * resolution: = wontfix Comment: The 6.12 branch is no longer being developed; only the HEAD and 7.0 branches are. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4402#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): I thought that `collect2` automates this. IIRC, it ploughs through all object files looking for specific constructor symbols and then generates and links in an additional module which calls those symbols and is, in turn, called at start up. Wouldn't it be enough to simply make sure that module initialiser symbols look like constructors and link with `collect2`? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:30 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
unused record fields
Simon P. Jones wrote recently about that ghc-6.12 takes in
account the elliplis in MkT {t1 = x, ..} when reporting about
unused bindings.
Now, here is the example:
module TT where
data T = T {t1, t2 :: Int}
f d = x where
T {t1 = x, ..} = d
ghc-6.12.2 warns about unused value of t2.
And forf (T {t1 = x, ..}) = x,
it does not warn about this.
Is this a bug?
I use
extensions: TypeSynonymInstances UndecidableInstances FlexibleContexts
FlexibleInstances MultiParamTypeClasses OverlappingInstances
RecordWildCards NamedFieldPuns
ghc-options: -fno-warn-overlapping-patterns -fwarn-unused-binds
-fwarn-unused-matches -fwarn-unused-imports
-O0
,
but the options can be simplified, of course.
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3339: Data.Monoid: Add () as a synonym for mappend
#3339: Data.Monoid: Add () as a synonym for mappend
-+--
Reporter: bos | Owner:
Type: proposal| Status: new
Priority: normal | Milestone: Not GHC
Component: libraries/base |Version: 6.10.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Comment(by nominolo):
Benchmarks checking whether changing associativity of () in `pretty`
would lead to performance issues:
{{{
import Text.PrettyPrint
import Data.List
import Criterion.Main
f_left :: Int - Doc
f_left n = foldl' () empty (map (text . show) [10001..1+n])
f_right :: Int - Doc
f_right n = foldr () empty (map (text . show) [10001..1+n])
main =
defaultMain $
[ bench left $ nf (length . render . f_left) 1
, bench right$ nf (length . render . f_right) 1
, bench left20k $ nf (length . render . f_left) 2
, bench right20k $ nf (length . render . f_right) 2
, bench left30k $ nf (length . render . f_left) 3
, bench right30k $ nf (length . render . f_right) 3
]
}}}
Results (lower numbers are better):
{{{
Iterations
_10K__20K__30K
Left 10.1 (0.5) 24.4 (0.6) 40.0 (1.3)
Right 8.9 (0.2) 22.7 (3.1) 31.2 (4.6)
Format: runtime (stddev) all in milliseconds
}}}
So switching to right-associativity may actually increase performance
slightly. Scaling doesn't seem to be quite linear, but that could be due
to cache effects or suchlike; and it's also outside the scope of this
proposal.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3339#comment:22
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] #4397: RULES for Class ops don't fire in HEAD
#4397: RULES for Class ops don't fire in HEAD
--+-
Reporter: daniel.is.fischer |Owner:
Type: bug| Status: new
Priority: normal |Milestone:
Component: Compiler | Version: 7.1
Keywords: RULES, classes | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
--+-
Comment(by simonpj):
Fixed by
{{{
Fri Oct 15 14:18:14 BST 2010 simo...@microsoft.com
* Give user-defined rules precedence over built-in rules
This fixes Trac #4397. See comments with 'isMoreSpecific'.
}}}
Try now.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4397#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] #4346: Behaviour of INLINABLE depends on whether the modules included are already compiled.
#4346: Behaviour of INLINABLE depends on whether the modules included are already compiled. ---+ Reporter: milan | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.0.1 Component: Compiler |Version: 7.1 Resolution: fixed | Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by igloo): * status: merge = closed * resolution: = fixed Comment: Merged. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4346#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] #3651: GADT type checking too liberal
#3651: GADT type checking too liberal +--- Reporter: MartijnVanSteenbergen|Owner: igloo Type: bug | Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler (Type checker) | Version: 6.10.4 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown +--- Comment(by michalt): Replying to [comment:4 simonpj]: I've noticed that only one of the three errors is reported, at a time. I'll fix that. You're right! I have absolutely no idea why I've tested them one at a time. Sorry if that caused any confusion. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3651#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] #3339: Data.Monoid: Add () as a synonym for mappend
#3339: Data.Monoid: Add () as a synonym for mappend
-+--
Reporter: bos | Owner:
Type: proposal| Status: new
Priority: normal | Milestone: Not GHC
Component: libraries/base |Version: 6.10.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Comment(by jeltsch):
It was also suggested to make {{{()}}} a method of {{{Monoid}}} and
insert the following default definitions:
{{{
() = mappend
mappend = ()
}}}
Any objections against this?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3339#comment:23
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] #3339: Data.Monoid: Add () as a synonym for mappend
#3339: Data.Monoid: Add () as a synonym for mappend
-+--
Reporter: bos | Owner:
Type: proposal| Status: new
Priority: normal | Milestone: Not GHC
Component: libraries/base |Version: 6.10.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Comment(by jeltsch):
In the long run, we should probably get rid of {{{mappend}}} altogether.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3339#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by batterseapower): Having a better solution for compile time imports would also prevent GHC from linking in modules that are import only for their type information (e.g. a type-level natural numbers package). We could also extend it so we get a better solution to the outstanding annoying problem where you have to remember to call `hs_init` and `hs_add_root` when building a C program that links in some Haskell. We can just arrange that hs_init is marked as a constructor for collect2's purposes. This will cause libgcc library to call hs_init for you (via __main), along with the module initialisers. This means that if you build your Haskell-importing C program using the GNU toolchain, then you don't have to worry about starting up the Haskell RTS at all. In particular this means you could write a Haskell library that behaves as a drop-in replacement for a C library. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:31 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] #3339: Data.Monoid: Add () as a synonym for mappend
#3339: Data.Monoid: Add () as a synonym for mappend -+-- Reporter: bos | Owner: Type: proposal| Status: new Priority: normal | Milestone: Not GHC Component: libraries/base |Version: 6.10.3 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: Unknown | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Comment(by nominolo): Getting rid of `mappend` would break a ''lot'' of packages, so that will take a while. Also, what should happen to `mconcat`? The naming of `mappend` makes somewhat sense, because `[a]` is the free Monoid, so `mconcat` is just the extension of that naming strategy. Should `mconcat` stay as is, or can anyone think of a better name? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3339#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] #1634: Type signature normalization
#1634: Type signature normalization -+-- Reporter: kfr...@…| Owner: igloo Type: bug | Status: closed Priority: low | Milestone: 7.0.1 Component: Compiler (Type checker) |Version: 6.6.1 Resolution: fixed | Keywords: Testcase: typecheck/should_compile/T1634 | Blockedby: Difficulty: Unknown | Os: Linux Blocking: | Architecture: x86 Failure: None/Unknown| -+-- Changes (by igloo): * status: patch = closed * resolution: = fixed Comment: Applied to HEAD and 7.0, thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1634#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] #4163: Make cross-compilation work
#4163: Make cross-compilation work -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: high |Milestone: 7.0.2 Component: Build System | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Difficult (2-5 days) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by tedm): * cc: middleton@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4163#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] #2965: GHC on OS X does not compile 64-bit
#2965: GHC on OS X does not compile 64-bit +--- Reporter: Axman6 |Owner: igloo Type: feature request | Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: Keywords: 64bit| Testcase: Blockedby: | Difficulty: Unknown Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Installing GHC failed +--- Changes (by tedm): * cc: middleton@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2965#comment:67 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] #4403: Huge (10 times) increase of binaries produced by GHC 7.0.0 and GHC head
#4403: Huge (10 times) increase of binaries produced by GHC 7.0.0 and GHC head
--+-
Reporter: milan | Owner:
Type: bug| Status: new
Priority: normal | Component: Compiler
Version: 7.0.1 RC1 |Keywords: code bloat
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86| Failure: Other
--+-
When benchmarking Containers, I came over some suspicious increase of code
size. I reduced the test case to the following:
Compile the following trivial benchmark:
{{{
import Data.Set
import Criterion.Main
main = defaultMain [bench set (whnf (length . toList . fromList . concat
. replicate 10) [1..1000])]
}}}
The size of a stripped binary produced by ghc --make -O:
{{{
ghc-6.12.1: 2414128
ghc-7.0.0.20100930: 22572260
ghc-7.1.20101010: 21417316
}}}
That is nearly 10-times increase of code size. I could not figure out why.
When using only 'base' package, there is nearly no increase in code size.
The ghc-bundled libraries use -split-objs, the libraries compiled by
cabal-install are not using -split-objs in any ghc version.
I used I386. The ghc-6.12.1 is precompiled binary, ghc-7.0.0 is compiled
by ghc-6.12.1 by using default build system (configure make, no
build.mk), ghc-7.1 is compiled by ghc-6.12.1 by using custom build.mk (but
it only sets !GhcLibWays=v).
The criterion package was compiled using 'cabal install criterion'. Latest
version 0.5.0.4 was used (vector 0.7, vector-algorithms 0.3.3, statistics
0.8.0.1). For ghc-7.0 and ghc-7.1 some minor changes to the latest hackage
versions of the deepseq, parallel, syb and vector-algorithms packages had
to be made (trivial dependency changes, code that does not type check).
!SimonMar said some of that is already corrected in darcs repos.
Can anyone reproduce this behaviour? If so, it is horrible.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4403
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] #3472: Porting through .hc files broken
#3472: Porting through .hc files broken -+-- Reporter: pumpkin | Type: bug Status: new | Priority: high Milestone: 7.0.2 |Component: Build System Version: 6.12.1 RC1| Resolution: Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by tedm): * cc: middleton@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3472#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] #4403: Huge (10 times) increase of binaries produced by GHC 7.0.0 and GHC head
#4403: Huge (10 times) increase of binaries produced by GHC 7.0.0 and GHC head +--- Reporter: milan | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.0.1 RC1 Resolution: duplicate | Keywords: code bloat Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: x86 Failure: Other | +--- Changes (by igloo): * status: new = closed * resolution: = duplicate Comment: This is because the `ghc` packages is used, and thus linked in, with ghc 7. See #4387 for more discussion. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4403#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] #4404: RecordWildCards
#4404: RecordWildCards
+---
Reporter: igloo|Owner:
Type: bug | Status: new
Priority: normal |Milestone: 7.2.1
Component: Compiler (Type checker) | Version: 6.12.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
+---
With this module:
{{{
{-# LANGUAGE RecordWildCards #-}
module TT where
data T = T {t1, t2 :: Int}
f :: T - Int
f d = x
where T {t1 = x, ..} = d
g :: T - Int
g (T {t1 = x, ..}) = x
}}}
`f` gives warnings about t2 being unused:
{{{
$ ghc -Wall -c n.hs
n.hs:9:11: Warning: Defined but not used: `t2'
}}}
which is probably not what we want for variables bound by a wildcard.
Reported by Serge here:
http://www.haskell.org/pipermail/glasgow-haskell-
bugs/2010-October/025858.html
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4404
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] #4318: Crash while building HEAD on OS X
#4318: Crash while building HEAD on OS X ---+ Reporter: gwright |Owner: Type: bug | Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler| Version: 6.13 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Building GHC failed ---+ Comment(by gwright): I have ghci from HEAD working, built 64 bit on OS X 10.6. At least it works well enough to define `fact` and `fib` at the prompt and get the right answers. (Certainly an improvement over a segfault or abort trap!) I'll resync with HEAD and apply my patches, then run the testsuite. There may still be some other problems with the linker lurking, since there have clearly been paths through the code that were never exercised in the 64 bit Mach-O case. The final change to fix the crash wasn't much; better to be lucky than smart. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4318#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: unused record fields
On Fri, Oct 15, 2010 at 09:04:20PM +0400, Serge D. Mechveliani wrote:
module TT where
data T = T {t1, t2 :: Int}
f d = x where
T {t1 = x, ..} = d
ghc-6.12.2 warns about unused value of t2.
Thanks for the report; filed as:
http://hackage.haskell.org/trac/ghc/ticket/4404
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4388: Unexpected failures, too much allocation
#4388: Unexpected failures, too much allocation
---+
Reporter: daniel.is.fischer |Owner:
Type: bug | Status: new
Priority: high|Milestone: 7.2.1
Component: Test Suite | Version: 7.1
Keywords: test suite, allocation | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple| Blocking:
Architecture: Unknown/Multiple| Failure: None/Unknown
---+
Comment(by daniel.is.fischer):
My latest HEAD just made it for T1969:
{{{
/home/dafis/Haskell/Hacking/ratstuff/bindisttest/install
dir/lib/ghc-7.1.20101015/ghc
-B/home/dafis/Haskell/Hacking/ratstuff/bindisttest/install
dir/lib/ghc-7.1.20101015
-pgmc /usr/bin/gcc -pgma /usr/bin/gcc -pgml /usr/bin/gcc -pgmP
/usr/bin/gcc -E
-undef -traditional -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-
output
-no-user-package-conf -rtsopts -c T1969.hs +RTS -V0 -tT1969.comp.stats
--machine-readable
[(bytes allocated, 269780444)
,(num_GCs, 386)
,(average_bytes_used, 3472012)
,(max_bytes_used, 5944572)
,(num_byte_usage_samples, 8)
,(peak_megabytes_allocated, 19)
,(init_cpu_seconds, 0.01)
,(init_wall_seconds, 0.00)
,(mutator_cpu_seconds, 1.31)
,(mutator_wall_seconds, 1.62)
,(GC_cpu_seconds, 0.78)
,(GC_wall_seconds, 0.81)
]
}}}
close shave, though.
T3294 got better too:
{{{
bytes allocated 912566272 is more than maximum allowed 85000
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4388#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] #4405: tcfail138 compiles but shouldn't
#4405: tcfail138 compiles but shouldn't --+- Reporter: daniel.is.fischer | Owner: Type: bug| Status: new Priority: normal | Component: Test Suite Version: 7.1|Keywords: Testcase: | Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Changes (by daniel.is.fischer): * version: 6.12.3 = 7.1 * component: Compiler = Test Suite -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4405#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] #2271: floor, ceiling, round :: Double - Int are awesomely slow
#2271: floor, ceiling, round :: Double - Int are awesomely slow --+- Reporter: dons |Owner: daniel.is.fischer Type: bug| Status: patch Priority: low|Milestone: 7.0.1 Component: libraries/base | Version: 7.1 Keywords: performance, math, double | Testcase: Blockedby: | Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Changes (by daniel.is.fischer): * status: new = patch Comment: Works now :) Please test on 64 bits to make sure I haven't bungled the CPP stuff. I also have a lot of rewrite rules for !IntN and !WordN, but I'm not sure where to put them. Probably GHC.Int and GHC.Word, but we'd have to import GHC.Float and perhaps GHC.Float.RealFracMethods then. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2271#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] #4397: RULES for Class ops don't fire in HEAD
#4397: RULES for Class ops don't fire in HEAD --+- Reporter: daniel.is.fischer| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.1 Resolution: fixed| Keywords: RULES, classes Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --+- Changes (by daniel.is.fischer): * status: new = closed * resolution: = fixed Comment: Yes, works now. Muchas Gracias. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4397#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
[GHC] #4406: Spurious Haddock links
#4406: Spurious Haddock links
--+-
Reporter: daniel.is.fischer | Owner:
Type: bug| Status: new
Priority: normal | Component: Build System
Version: 7.1|Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Documentation bug
--+-
GHC builds haddock docs for packages it doesn't install and includes the
modules in the library index. The haddock docs for these packages are
however not copied to share/doc/ghc/... (the latter is okay, since the
packages are not installed).
Affected are:
{{{
dph-*
haskeline
mtl
primitive
terminfo
utf8-string
vector
xhtml
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4406
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] #836: rebindable if-then-else syntax
#836: rebindable if-then-else syntax --+- Reporter: nibro |Owner: SamAnklesaria Type: feature request| Status: new Priority: normal |Milestone: _|_ Component: Compiler (Parser) | Version: 6.13 Keywords: | Testcase: N/A Blockedby: | Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Comment(by SamAnklesaria): I've come across a problem with making `if` syntax into a function. Many uses from GHC's base library are for branches with kind # that don't match the * kind expected by my polymorphic `ifThenElse` function. I could switch all such occurrences to `case` statements, but that wouldn't prevent other libraries from having the same problems. Is there any way to make polymorphic (Bool - a - a - a) functions handle things like Int#? I'm kinda stuck. Thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/836#comment:21 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
