Re: [GHC] #3437: Optimizer creates space leak on simple code
#3437: Optimizer creates space leak on simple code
---+
Reporter: lilac |Owner:
Type: run-time performance bug| Status: closed
Priority: normal |Milestone:
Component: Compiler| Version: 6.10.3
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: simplCore/should_run/T3437 | Os: Linux
Architecture: x86_64 (amd64) |
---+
Changes (by simonpj):
* testcase: = simplCore/should_run/T3437
* status: new = closed
* resolution: = fixed
* type: bug = run-time performance bug
Comment:
Done! Fixed by
{{{
Fri Aug 21 10:52:51 BST 2009 simo...@microsoft.com
* Fix Trac #3437: strictness of specialised functions
'lilac' helpful pin-pointed a space leak that was due to a specialised
function being insufficiently strict. Here's the new comment in
SpecConstr:
Note [Transfer strictness]
~~
We must transfer strictness information from the original function to
the specialised one. Suppose, for example
f has strictness SS
and a RULE f (a:as) b = f_spec a as b
Now we want f_spec to have strictess LLS, otherwise we'll use call-by-
need
when calling f_spec instead of call-by-value. And that can result in
unbounded worsening in space (cf the classic foldl vs foldl')
See Trac #3437 for a good example.
The function calcSpecStrictness performs the calculation.
M ./compiler/specialise/SpecConstr.lhs +44
}}}
Thank you for identifying the problem so precisely.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3437#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] #3371: Spurious Defined but not used when using record wildcards
#3371: Spurious Defined but not used when using record wildcards
+---
Reporter: Baughn |Owner:
Type: bug | Status: closed
Priority: normal |Milestone:
Component: Compiler | Version: 6.10.3
Severity: minor| Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: rename/should_compile/T3371 | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
+---
Changes (by simonpj):
* testcase: = rename/should_compile/T3371
* difficulty: = Unknown
* status: new = closed
* resolution: = fixed
Comment:
Good point. I fixed this, and some related stuff concerning named fields,
with this patch:
{{{
Thu Aug 20 13:34:43 BST 2009 simo...@microsoft.com
* Improvements to record puns, wildcards
* Make C { A.a } work with punning, expanding to C { A.a = a }
* Make it so that, with -fwarn-unused-matches,
f (C {..}) = x
does not complain about the bindings introduced by the ...
* Make -XRecordWildCards implies -XDisambiguateRecordFields.
* Overall refactoring of RnPat, which had become very crufty.
In particular, there is now a monad, CpsRn, private to RnPat,
which deals with the cps-style plumbing. This is why so many
lines of RnPat have changed.
* Refactor the treatment of renaming of record fields into two passes
- rnHsRecFields1, used both for patterns and expressions,
which expands puns, wild-cards
- a local renamer in RnPat for fields in patterns
- a local renamer in RnExpr for fields in construction and update
This make it all MUCH easier to understand
* Improve documentation of record puns, wildcards, and disambiguation
M ./compiler/basicTypes/RdrName.lhs -5 +9
M ./compiler/main/DynFlags.hs +6
M ./compiler/parser/RdrHsSyn.lhs -11 +4
M ./compiler/rename/RnBinds.lhs -6 +7
M ./compiler/rename/RnEnv.lhs -139 +124
M ./compiler/rename/RnExpr.lhs -6 +27
M ./compiler/rename/RnPat.lhs -384 +394
M ./compiler/rename/RnSource.lhs -5 +4
M ./compiler/rename/RnTypes.lhs -2 +2
M ./compiler/typecheck/TcEnv.lhs -2 +2
M ./compiler/typecheck/TcPat.lhs -1 +1
M ./docs/users_guide/glasgow_exts.xml -22 +92
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3371#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] #3446: Library enhancement request: Data.Maybe.justIf
#3446: Library enhancement request: Data.Maybe.justIf
-+--
Reporter: nomeata | Owner:
Type: feature request | Status: new
Priority: normal| Component: libraries/base
Version: 6.10.4| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
Hi,
I found myself often writing the idiom if a then Just v else Nothing. It
can be nicely abbreviated by the function:
{{{
justIf :: a - Bool - Just a
justIf x True = Just x
justIf x False = Nothing
}}}
Which would allow me to write the nicely write- and readable {{{v `justIf`
a}}}.
Asking on #haskell, I got positive feedback about this addition:
{{{
endojelly nomeata, I'm all for it. my last project was *full* of that
idiom
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3446
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] #3446: Library enhancement request: Data.Maybe.justIf
#3446: Library enhancement request: Data.Maybe.justIf
--+-
Reporter: nomeata | Owner:
Type: feature request | Status: new
Priority: normal| Milestone:
Component: libraries/base|Version: 6.10.4
Severity: normal| Resolution:
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
--+-
Comment (by nomeata):
Of course it should say
{{{
justIf :: a - Bool - Maybe a
justIf x True = Just x
justIf x False = Nothing
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3446#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] #3446: Library enhancement request: Data.Maybe.justIf
#3446: Library enhancement request: Data.Maybe.justIf -+-- Reporter: nomeata |Owner: Type: feature request | Status: closed Priority: normal|Milestone: Component: libraries/base| Version: 6.10.4 Severity: normal| Resolution: wontfix Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: new = closed * difficulty: = Unknown * resolution: = wontfix Comment: Can you please make a [http://www.haskell.org/haskellwiki/Library_submissions library submissions proposal] for this? Given the timing of ICFP, I'd recommend end of September as a discussion deadline. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3446#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] #3320: Parallel program crashes using GHC 6.11 under OS X
#3320: Parallel program crashes using GHC 6.11 under OS X
---+
Reporter: sebf|Owner: simonmar
Type: bug | Status: new
Priority: high|Milestone: 6.12.1
Component: Runtime System | Version: 6.11
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: MacOS X
Architecture: x86 |
---+
Comment (by igloo):
{{{
ian-lynaghs-macbook-pro:foo ian$ ./idfs +RTS -N3
Bus error
ian-lynaghs-macbook-pro:foo ian$ ./idfs +RTS -N3 -g1
500
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3320#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] #3424: Corrupt executable when compiling large do block for List monad
#3424: Corrupt executable when compiling large do block for List monad
-+--
Reporter: guest |Owner: simonmar
Type: bug | Status: closed
Priority: high |Milestone: 6.12.1
Component: Compiler | Version: 6.10.4
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase:| Os: Linux
Architecture: x86 |
-+--
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
Fixed:
{{{
Thu Aug 20 06:15:37 PDT 2009 Simon Marlow marlo...@gmail.com
* Add a case for IND (and a comment). Fixes #3424, perhaps only
partially.
Thu Aug 20 07:43:08 PDT 2009 Simon Marlow marlo...@gmail.com
* Relax the assumption that all objects fit in a single block (#3424)
}}}
Interesting that it took ~10 years for anyone to find this bug.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3424#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] #3447: Class restrictions on type instances
#3447: Class restrictions on type instances
-+--
Reporter: LysikovVV | Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 6.10.4| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
I'm using type families to implement bools and integers on type level.
There is a class BoolT with with two instances and type families
representing usual boolean functions, e.g. NotT. By semantics of NotT,
implication (BoolT a) = (BoolT (NotT a)) holds, but I cannot specify this
to compiler, and using BoolT with NotT is painful.
So I think there must be syntactic construction to restrict type family
instances to some class, something like
{{{
type family NotT a
with (BoolT a) = (BoolT (NotT a))
}}}
or
{{{
class BoolT a where
type NotT a
with BoolT (NotT a)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3447
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] #3446: Library enhancement request: Data.Maybe.justIf
#3446: Library enhancement request: Data.Maybe.justIf -+-- Reporter: nomeata |Owner: Type: proposal | Status: reopened Priority: normal|Milestone: Component: libraries/base| Version: 6.10.4 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by nomeata): * status: closed = reopened * type: feature request = proposal * resolution: wontfix = Comment: Ok, darcs patch is sent, and references this ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3446#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] #3448: Error with .so files in HEAD snapshot distribution
#3448: Error with .so files in HEAD snapshot distribution
---+
Reporter: dons| Owner:
Type: bug | Status: new
Priority: normal | Component: Build System
Version: 6.11| Severity: normal
Keywords: | Testcase:
Os: Linux | Architecture: x86_64 (amd64)
---+
Installing the ghc-6.11.20090818 binary snapshot for x86_64 fails at 'make
install' time with:
{{{
inplace/bin/ghc-cabal install
Installing library in /home/dons/lib/ghc-6.11.20090818/ghc-prim-0.1.0.0
ghc-cabal: dist-install/build/libHSghc-prim-0.1.0.0-ghc6.11.20090818.so:
does
not exist
}}}
Meaning I am unable to install the snapshot.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3448
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] #3320: Parallel program crashes using GHC 6.11 under OS X
#3320: Parallel program crashes using GHC 6.11 under OS X
---+
Reporter: sebf|Owner: simonmar
Type: bug | Status: new
Priority: high|Milestone: 6.12.1
Component: Runtime System | Version: 6.11
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: MacOS X
Architecture: x86 |
---+
Comment (by igloo):
Here's the end of a run with a slightly instrumented RTS:
{{{
RELEASE_LOCK(0x801330) rts/Capability.c 644
Calling yieldCapability 2 with 0x801280
Called yieldCapability with 0x801280
RELEASE_LOCK(0x7009f8) rts/Capability.c 618
ACQUIRE_LOCK(0x8011f0) rts/Capability.c 622
RELEASE_LOCK(0x8011f0) rts/Capability.c 626
ACQUIRE_LOCK(0x7009f8) rts/Capability.c 613
RELEASE_LOCK(0x801330) rts/Capability.c 842
Calling yieldCapability 1 with 0x801140
Called yieldCapability with 0x801140
ACQUIRE_LOCK(0x2ca7e0) rts/Schedule.c 906
RELEASE_LOCK(0x2ca7e0) rts/Schedule.c 916
Garbage collecting
ACQUIRE_LOCK(0x2cb8a0) rts/sm/GC.c 199
ACQUIRE_LOCK(0x2ca2a0) rts/Stable.c 325
RELEASE_LOCK(0x2cb8a0) rts/sm/GC.c 755
ACQUIRE_LOCK(0x2cb8a0) rts/sm/GC.c 757
RELEASE_LOCK(0x2cb8a0) rts/sm/GC.c 760
ACQUIRE_LOCK(0x2cb8a0) rts/sm/GC.c 763
RELEASE_LOCK(0x2ca2a0) rts/Stable.c 331
RELEASE_LOCK(0x2cb8a0) rts/sm/GC.c 812
Finished garbage collecting
ACQUIRE_LOCK(0x8011f0) rts/Capability.c 534
RELEASE_LOCK(0x8011f0) rts/Capability.c 545
Calling yieldCapability 2 with 0x801140
ACQUIRE_LOCK(0x700ac8) rts/Capability.c 548
Calling yieldCapability 2 with 0x801280
Called yieldCapability with 0x801140
Called yieldCapability with 0xb0103000
Calling releaseCapabilityAndQueueWorker with 0x801140
Calling releaseCapabilityAndQueueWorker with 0xb0103000
ACQUIRE_LOCK(0x8011f0) rts/Capability.c 457
ACQUIRE_LOCK(0xb01030b0) rts/Capability.c 457
ACQUIRE_LOCK(0x700ac8) rts/Capability.c 350
Task is NULL! 0xb0103000 0xb01030b0
RELEASE_LOCK(0x700ac8) rts/Capability.c 356
RELEASE_LOCK(0x8011f0) rts/Capability.c 481
RELEASE_LOCK(0x700ac8) rts/Capability.c 553
ACQUIRE_LOCK(0x700be8) rts/Capability.c 613
ACQUIRE_LOCK(0x8011f0) rts/Capability.c 556
RELEASE_LOCK(0x8011f0) rts/Capability.c 566
Bus error
}}}
The
{{{
Garbage collecting
[...]
Finished garbage collecting
}}}
are the start and end of `rts/sm/GC.c:GarbageCollect`, so it looks to me
like we aren't supposed to be GCing when things go wrong.
In particular, see these two lines:
{{{
Calling yieldCapability 2 with 0x801280
[...]
Called yieldCapability with 0xb0103000
}}}
These are:
{{{
if (prev_pending_gc) {
do {
debugTrace(DEBUG_sched, someone else is trying to GC
(%d)...,
prev_pending_gc);
ASSERT(cap);
printf(Calling yieldCapability 2 with %p\n, cap);
yieldCapability(cap,task);
} while (waiting_for_gc);
return cap; // NOTE: task-cap might have changed here
}
}}}
and
{{{
void
yieldCapability (Capability** pCap, Task *task)
{
Capability *cap = *pCap;
printf(Called yieldCapability with %p\n, cap);
}}}
The
{{{
Task is NULL! 0xb0103000 0xb01030b0
}}}
is the point where the bus error actually happens:
{{{
static void
releaseCapabilityAndQueueWorker (Capability* cap USED_IF_THREADS)
{
Task *task;
ACQUIRE_LOCK(cap-lock);
task = cap-running_task;
if (task == NULL) {
printf(Task is NULL! %p %p\n, cap, cap-lock);
fflush(stdout);
}
[...]
if (!isBoundTask(task) !task-stopped !task-suspended_tso) {
}}}
which looks like a symptom of the corrupt cap.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3320#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] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work
#2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work ---+ Reporter: ajd |Owner: Type: feature request | Status: closed Priority: normal |Milestone: 6.12 branch Component: Compiler| Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: indexed_types/should_compile/T2850 | Os: Unknown/Multiple Architecture: Unknown/Multiple| ---+ Changes (by simonpj): * testcase: = indexed_types/should_compile/T2850 * status: new = closed * resolution: = fixed Comment: Happily this seems OK in the HEAD (and hence 6.12). So I'll add a regression test and close the bug. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2850#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] #3423: No match in record selector Var.tcTyVarDetails with ghc = 6.10.2
#3423: No match in record selector Var.tcTyVarDetails with ghc = 6.10.2
---+
Reporter: morrow |Owner:
Type: bug | Status: closed
Priority: normal |Milestone:
Component: Compiler| Version: 6.10.4
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: indexed_types/should_compile/T3423 | Os:
Unknown/Multiple
Architecture: Unknown/Multiple|
---+
Changes (by simonpj):
* testcase: = indexed_types/should_compile/T3423
* difficulty: = Unknown
* status: new = closed
* resolution: = fixed
Comment:
Ah yes, excellent point thank you. A missed instantiation.
{{{
Fri Aug 21 22:07:00 GMT Daylight Time 2009 simo...@microsoft.com
* Fix Trac #3423: missed instantiation for newtype-derived instances
Somehow I'd forgotten to instantiate the coercion that is stored in a
'NewtypeDerived' constructor in an InstInfo. The necessary code is
in TcInstDcls.tc_inst_decl2.
The result was ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for x86_64-unknown-linux):
No match in record selector Var.tcTyVarDetails
because we were looking at an (uninstantiated) TyVar instead of
an (instantiated) TcTyVar.
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3423#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] #3449: Unavoidable unused bindings warnings in boot files
#3449: Unavoidable unused bindings warnings in boot files
-+--
Reporter: heatsink | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 6.10.4| Severity: minor
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
The {{{-fwarn-unused-binds}}} flag produces warnings for bindings that
cannot, in fact, be deleted from hs-boot files. It would be nice not to
see these warnings. Definitions in .hs-boot files must match the
definitions in .hs files, but .hs-boot files don't necessarily use or
export the same identifiers that the .hs file does.
Running {{{ghc -c A.hs-boot -fwarn-unused-binds}}} produces warnings for
this hs-boot file, regardless of whether the identifiers are exported in
the hs file.
{{{
{- A.hs-boot -}
{-# OPTIONS_GHC -XTypeFamilies #-} -- to demonstrate associated type
warnings
module A(Foo, HasFoo) where
newtype Foo = Foo {unFoo :: Int}
class HasFoo a where
data Foo' a
getFoo :: a - Foo
}}}
For identifiers defined on the RHS of an equal sign or 'where'---namely,
data constructors, field names, class methods, and associated types---I
suggest silencing unused binding warnings in the boot file. The rationale
is that you should be allowed to copy an entire definition into the boot
file, and regard a binding as unused only if it appears unused in the .hs
file.
See also #3283.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3449
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] #2798: Enable rec keyword when RecursiveDo is enabled?
#2798: Enable rec keyword when RecursiveDo is enabled? -+-- Reporter: nominolo |Owner: igloo Type: task | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2798#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
