Re: [GHC] #7243: regression: acceptable foreign result types
#7243: regression: acceptable foreign result types ---+ Reporter: dmwit | Owner: Type: bug| Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: x86_64 (amd64) Failure: GHC rejects valid program | Testcase: Blockedby: | Blocking: Related: | ---+ Changes (by romildo): * cc: malaquias@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7243#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] #7243: regression: acceptable foreign result types
#7243: regression: acceptable foreign result types
---+
Reporter: dmwit | Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler (FFI) | Version: 7.6.1
Keywords: | Os: Unknown/Multiple
Architecture: x86_64 (amd64) | Failure: GHC rejects valid program
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by igloo):
* owner: = igloo
* difficulty: = Unknown
* component: Compiler = Compiler (FFI)
* milestone: = 7.6.2
Comment:
The problem is:
{{{
Dynamic wrapper.
The type of a wrapper stub has to be of the form ft - IO (FunPtr ft),
where ft may be any foreign type.
}}}
e.g. this is accepted:
{{{
import Foreign.Ptr
foreign import ccall wrapper foo :: () - IO (FunPtr ())
}}}
I'll leave the ticket open, though, as I think we should give the expected
pattern in the error message.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7243#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] #7237: CgCase fails with strict data/functions
#7237: CgCase fails with strict data/functions
--+-
Reporter: jwlato| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
Comment(by simonpj@…):
commit 84bb8541fffb99d425fcd50532dc4556f4bd7aca
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Sat Sep 15 23:06:20 2012 +0100
Fix Trac #7237; mixup with empty tuples
When converting from Core to STG, we swith pattern matching on
on a *nullary* unboxed tuple into matching using a PrimAlt on
RealWorld#
case e (RealWorld#) of { DEFAULT - ... }
This semms messy to me, but it works. There was a bug in that we were
changing to PrimAlt, but not using a DEFAULT AltCon.
compiler/stgSyn/CoreToStg.lhs | 11 ++-
compiler/types/Type.lhs | 16
2 files changed, 18 insertions(+), 9 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7237#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] #7238: class methods with associated equality constraints panic
#7238: class methods with associated equality constraints panic
---+
Reporter: dmwit | Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler| Version: 7.6.1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Compile-time crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by simonpj@…):
commit 7d83fdea229b940ae198ddc5c179ac449defd2ef
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Sat Sep 15 00:12:16 2012 +0100
Bind given evidence to a variable, always
This was being done in xCtFlavor, but not in rewriteCtFlavor,
resulting in Trac #7238.
See Note [Bind new Givens immediately] in TcSMonad and
and Note [Coercion evidence terms] in TcEvidence.
compiler/typecheck/TcEvidence.lhs | 29 ++---
compiler/typecheck/TcSMonad.lhs | 26 +-
2 files changed, 31 insertions(+), 24 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7238#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] #5252: UNPACK without optimisation leads to panic
#5252: UNPACK without optimisation leads to panic
---+
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 7.6.1
Resolution:| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: deSugar/should_compile/T5252 | Blockedby:
Blocking:|Related:
---+
Comment(by simonpj@…):
commit 5bae803a18b17bdb158a7780e6b6ac3c520e5b39
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Sat Sep 15 23:09:25 2012 +0100
Fix UNPACK with -fomit-interface-pragmas.
We were missing a case, so that you could expose a constructor
with UNPACKed fields, but the field tpye was trimmed, and hence
can't be expanded.
Fixes Trac #5252 (revived)
compiler/typecheck/TcTyClsDecls.lhs | 29 -
1 files changed, 16 insertions(+), 13 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5252#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] #7230: GHC states the same kind mismatched
#7230: GHC states the same kind mismatched
---+
Reporter: konn | Owner:
Type: bug| Status: new
Priority: normal | Component: Compiler
Version: 7.7| Keywords:
Os: MacOS X| Architecture: x86_64 (amd64)
Failure: Incorrect warning at compile-time | Testcase:
Blockedby: | Blocking:
Related: |
---+
Comment(by simonpj@…):
commit c32bb5d0c09a7e55197191f152c6875b398717cf
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Sun Sep 9 07:07:39 2012 +0100
Remember to zonk the skolems of an implication
Their kinds may contain kind unification variables!
This patch fixes Trac #7230.
compiler/typecheck/TcMType.lhs | 25 ++---
1 files changed, 18 insertions(+), 7 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7230#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] #7224: Polymorphic kind annotations on type classes don't always work as expected
#7224: Polymorphic kind annotations on type classes don't always work as
expected
---+
Reporter: slindley | Owner:
Type: bug| Status: new
Priority: normal | Component: Compiler (Type
checker)
Version: 7.6.1-rc1 | Keywords: kind polymorphism
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHC rejects valid program | Testcase:
Blockedby: | Blocking:
Related: |
---+
Comment(by simonpj@…):
commit 77b63e74454170bd658c6773b9d5c172920d5cc5
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Sep 10 13:13:24 2012 +0100
Two fixes to kind unification
* Don't unify a kind signature-variable with non-tyvar kind
* Don't allow a kind variable to appear in a type
(Trac #7224)
compiler/typecheck/TcHsType.lhs |9 +++--
compiler/typecheck/TcUnify.lhs | 20 ++--
2 files changed, 21 insertions(+), 8 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7224#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
[GHC] #7246: Callstack depends on way (prof, profasm, profthreaded
#7246: Callstack depends on way (prof, profasm, profthreaded
-+--
Reporter: nomeata | Owner:
Type: bug | Status: new
Priority: normal | Component: Profiling
Version: 7.6.1| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Testcase:
Blockedby: | Blocking:
Related: |
-+--
Consider the attached test case. The expected output is the that of the
```prof``` way, while for ```profasm``` and ```profthreaded```, I get this
result:
{{{
= callstack003(profthreaded) 19 of 21 [0, 1, 0]
cd . '/home/jojo/dokumente/Uni/info/ghc/inplace/bin/ghc-stage2'
-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-
db -rtsopts -fno-ghci-history -o callstack003 callstack003.hs -O -prof
-auto-all -threaded -fprof-auto-calls -fno-full-laziness -fno-state-hack
callstack003.comp.stderr 21
cd . ./callstack003 +RTS -p -RTS /dev/null callstack003.run.stdout
2callstack003.run.stderr
Actual stdout output differs from expected:
--- ./callstack003.stdout 2012-09-17 11:27:02.607458948 +0200
+++ ./callstack003.run.stdout 2012-09-17 12:20:33.988109494 +0200
@@ -1,8 +1,8 @@
-[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.doTwice
(callstack003.hs:10:15-17),Main.f (callstack003.hs:7:11-36)]
-[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.doTwice
(callstack003.hs:10:22-24),Main.f (callstack003.hs:7:11-36)]
-[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.doTwice
(callstack003.hs:10:15-17),Main.f (callstack003.hs:7:11-36)]
-[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.doTwice
(callstack003.hs:10:22-24),Main.f (callstack003.hs:7:11-36)]
-[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.doTwice
(callstack003.hs:10:15-17),Main.f (callstack003.hs:7:11-36)]
-[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.doTwice
(callstack003.hs:10:22-24),Main.f (callstack003.hs:7:11-36)]
-[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.doTwice
(callstack003.hs:10:15-17),Main.f (callstack003.hs:7:11-36)]
-[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.doTwice
(callstack003.hs:10:22-24),Main.f (callstack003.hs:7:11-36)]
+[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.f (callstack003.hs:7:11-36)]
+[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.f (callstack003.hs:7:11-36)]
+[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.f (callstack003.hs:7:11-36)]
+[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.f (callstack003.hs:7:11-36)]
+[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.f (callstack003.hs:7:11-36)]
+[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.f (callstack003.hs:7:11-36)]
+[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.f (callstack003.hs:7:11-36)]
+[Main.CAF (entire-module),Main.main
(callstack003.hs:9:8-21),Main.doTwice
(callstack003.hs:10:15-24),Main.f (callstack003.hs:7:11-36)]
*** unexpected failure for callstack003(profthreaded)
}}}
Not sure if this really hurts anyone, and the behavior of the call stack
WRT recursive calls is anyways not quite perfect yet (see #7240), this
makes adding good test cases a bit difficult.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7246
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] #7247: Testsuite: Print stdout diff even if stderr diff already fails
#7247: Testsuite: Print stdout diff even if stderr diff already fails --+- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal| Component: Test Suite Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- When doing test-driven development I find it handy to see the diff of stdout even when stderr already fails to match. The attached patch implements that. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7247 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] #7240: Stack trace truncated too much with indirect recursion
#7240: Stack trace truncated too much with indirect recursion
--+-
Reporter: nomeata | Owner: nomeata
Type: bug | Status: new
Priority: normal| Component: Profiling
Version: 7.4.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
Comment(by nomeata):
I started looking into this. Modifying ```checkLoop``` to only truncate if
there is a real loop at the top (e.g. ```a,b,c,b``` does not get
truncated yet, but ```a,b,c,b,c``` does get truncated to ```a,b,c```):
{{{
static CostCentreStack *
checkLoop (CostCentreStack *ccs, CostCentre *cc)
{
CostCentreStack *init_start, *top_seg, *bottom_seg;
init_start = ccs;
// Find previous instances of cc on the stack
while (init_start != EMPTY_STACK) {
if (init_start-cc == cc) {
// Compare the stack from here with the the top
top_seg = ccs;
bottom_seg = init_start-prevStack;
while (bottom_seg != EMPTY_STACK top_seg-cc ==
bottom_seg-cc) {
// top_set != EMPTY_STACK as bottom_seg is definitely
below of
// it and not empty
top_seg = top_seg-prevStack;
bottom_seg = bottom_seg-prevStack;
}
if (top_seg == init_start) {
// We found that the segment above init_start equals the
segment below it,
// so we truncate to it.
return init_start;
}
// Otherwise, we try to find a larger repeating initial
segment.
}
init_start = init_start-prevStack;
}
return NULL;
}
}}}
The problem is that it does not play well with ```enterFunCCS```. I have
an example program with some recursion, where the untruncated version
would be ```CAF,main,r,g,r,g,r,g,r,g,r,g,s,f```, and one would expect,
with the above code, that this gets compactified to
```CAF,main,r,g,s,f```. But what I observe is
```CAF,main,r,g,r,s,f```.
Judging from the traces, this is due to ```enterFunCCC```. Where in the
untruncating code it is called with ccsfun=```CAF,main,r,g,r,g``` and
rCCCS=```CAF,main,r,g,r``` (yielding ```CAF,main,r,g,r,g```), now it
receives the shortened ccsfun=```CAF,main,r,g``` and adds the ```r```
back in, yielding ``CAF,main,r,g,r```. On this then ```s``` and ```f```
are pushed.
I wonder if such an effect can also occur with the current, simpler
truncating routine.
BTW, have you considered not truncating upon push at all, and then
simplifying the stack trace on display? This would not lose any
information and the ```enterFunCCS``` logic would work just fine. But
maybe the overhead is too large? In that case, would a RTS flag (“precise
recursive call stack”) be useful?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7240#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] #7240: Stack trace truncated too much with indirect recursion
#7240: Stack trace truncated too much with indirect recursion --+- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal| Component: Profiling Version: 7.4.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- Comment(by nomeata): (I put my WIP code on http://git.nomeata.de/?p=ghc.git;a=shortlog;h=refs/heads/rec-stacktrace resp. https://github.com/nomeata/ghc/commits/rec-stacktrace) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7240#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] #7210: Bang in front of type name crashes GHC
#7210: Bang in front of type name crashes GHC -+-- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.6.1-rc1 Resolution: fixed | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Comment(by simonpj): Paolo: did you add a regression test? It'd be good to add it to the test case field of the ticket. Thanks Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7210#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] #7248: Error building integer-gmp using stage1 HEAD on OS X
#7248: Error building integer-gmp using stage1 HEAD on OS X -+-- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: MacOS X | Architecture: x86 Failure: Building GHC failed | Testcase: Blockedby: | Blocking: Related: | -+-- When building HEAD I get the following error: make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] libraries/integer-gmp/dist-install/build/GHC/Integer/Type.o /var/folders/ka/kaF7CETOGrynlpfcm3Ojdk++06g/-Tmp-/ghc91903_0/ghc91903_0.split__51.s:29:0: non-relocatable subtraction expression, _integerzmgmp_GHCziIntegerziType_S3Dk_srt minus _c3Co_info /var/folders/ka/kaF7CETOGrynlpfcm3Ojdk++06g/-Tmp-/ghc91903_0/ghc91903_0.split__51.s:29:0: symbol: _integerzmgmp_GHCziIntegerziType_S3Dk_srt can't be undefined in a subtraction expression /var/folders/ka/kaF7CETOGrynlpfcm3Ojdk++06g/-Tmp-/ghc91903_0/ghc91903_0.split__51.s:14:0: non-relocatable subtraction expression, _integerzmgmp_GHCziIntegerziType_S3Dk_srt minus _integerzmgmp_GHCziIntegerziType_negateInteger_info /var/folders/ka/kaF7CETOGrynlpfcm3Ojdk++06g/-Tmp-/ghc91903_0/ghc91903_0.split__51.s:14:0: symbol: _integerzmgmp_GHCziIntegerziType_S3Dk_srt can't be undefined in a subtraction expression make[1]: *** [libraries/integer-gmp/dist-install/build/GHC/Integer/Type.o] Error 1 make: *** [all] Error 2 Indeed, the symbol/label is not defined in the generated assembly (no .globl declaration) When building with object splitting disabled (SplitObjs = NO in build.mk) the error does not occur. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7248 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] #7239: GHC panic: MkExternalCore died: make_lit
#7239: GHC panic: MkExternalCore died: make_lit
--+-
Reporter: audunska | Owner:
Type: bug| Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.4.1
Keywords: panic, MkExternalCore | Os: Linux
Architecture: x86_64 (amd64) | Failure: Compile-time crash
Difficulty: Unknown|Testcase:
Blockedby: |Blocking:
Related: |
--+-
Changes (by simonpj):
* difficulty: = Unknown
Old description:
Compiling the attached example with -fext-core crashes ghc with the
following text:
$ ghc -fext-core min.hs
[1 of 1] Compiling Main ( min.hs, min.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.1 for x86_64-unknown-linux):
MkExternalCore died: make_lit
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Replacing the data declaration with a newtype or a library type such as
Complex or Ratio gives the same crash. An empty .hcr file is created.
Replacing the main action with return () or removing one of the type
synonym declarations makes the crash go away.
This is using the ghc package distributed with ubuntu 12.04.
New description:
Compiling the attached example with -fext-core crashes ghc with the
following text:
{{{
$ ghc -fext-core min.hs
[1 of 1] Compiling Main ( min.hs, min.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.1 for x86_64-unknown-linux):
MkExternalCore died: make_lit
}}}
Replacing the data declaration with a newtype or a library type such as
`Complex` or `Ratio` gives the same crash. An empty `.hcr` file is
created.
Replacing the main action with return () or removing one of the type
synonym declarations makes the crash go away.
This is using the ghc package distributed with ubuntu 12.04.
--
Comment:
Fixed by
{{{
commit 7b8a17ad3c0792f06ffa991e9e587f5458610a3c
Author: Simon Peyton Jones simo...@microsoft.com
Date: Sat Sep 15 23:12:23 2012 +0100
Print literal integers in External Core.
---
compiler/coreSyn/MkExternalCore.lhs |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/compiler/coreSyn/MkExternalCore.lhs
b/compiler/coreSyn/MkExternalCore.lhs
index d05da2a..2103708 100644
--- a/compiler/coreSyn/MkExternalCore.lhs
+++ b/compiler/coreSyn/MkExternalCore.lhs
@@ -229,7 +229,8 @@ make_lit dflags l =
MachWord64 i - C.Lint i t
MachFloat r - C.Lrational r t
MachDouble r - C.Lrational r t
-_ - error MkExternalCore died: make_lit
+LitInteger i _ - C.Lint i t
+_ - pprPanic MkExternalCore died: make_lit (ppr l)
where
t = make_ty dflags (literalType l)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7239#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] #367: Infinite loops can hang Concurrent Haskell
#367: Infinite loops can hang Concurrent Haskell
--+-
Reporter: simonpj | Owner: ezyang
Type: bug | Status: new
Priority: lowest | Milestone: _|_
Component: Compiler |Version: 6.4.1
Resolution: None | Keywords: scheduler
allocation
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by ezyang):
* owner: = ezyang
Comment:
It turns out the stupid implementation is actually pretty fast.
{{{diff --git a/compiler/codeGen/StgCmmHeap.hs
b/compiler/codeGen/StgCmmHeap.hs
index fb37391..a70d132 100644
--- a/compiler/codeGen/StgCmmHeap.hs
+++ b/compiler/codeGen/StgCmmHeap.hs
@@ -557,15 +557,22 @@ do_checks checkStack alloc do_gc = do
hp_oflo = CmmMachOp (mo_wordUGt dflags)
[CmmReg hpReg, CmmReg (CmmGlobal HpLim)]
+-- Yielding if HpLim == 0
+yielding = CmmMachOp (mo_wordEq dflags)
+[CmmReg (CmmGlobal HpLim), CmmLit (zeroCLit
dflags)]
+
alloc_n = mkAssign (CmmGlobal HpAlloc) alloc_lit
gc_id - newLabelC
when checkStack $ do
emit = mkCmmIfGoto sp_oflo gc_id
- when (alloc /= 0) $ do
- emitAssign hpReg bump_hp
- emit = mkCmmIfThen hp_oflo (alloc_n * mkBranch gc_id)
+ if (alloc /= 0)
+then do
+ emitAssign hpReg bump_hp
+ emit = mkCmmIfThen hp_oflo (alloc_n * mkBranch gc_id)
+else do
+ emit = mkCmmIfThen yielding (alloc_n * mkBranch gc_id)
emitOutOfLine gc_id $
do_gc -- this is expected to jump back somewhere
}}}
A totally unscientific benchmark on
{{{
module Main where
import qualified Data.Vector as U
main = U.sum (U.enumFromTo 1 (10 :: Int)) `seq` return ()
}}}
yields this C--
{{{
Main.main1_entry()
{ [(c1Zm,
Main.main1_info:
const 65539;
const 0;
const 15;),
(c1Zn,
block_c1Zn_info:
const 0;
const 32;)]
}
c1Zm:
if (Sp - 12 SpLim) goto c1Zv;
if (HpLim == 0) goto c1Zu;
I32[Sp - 8] = 0;
I32[Sp - 12] = 1;
I32[Sp - 4] = c1Zn;
Sp = Sp - 12;
jump Main.main_$s$wfoldlM'_loop_info; // []
c1Zu:
HpAlloc = 0;
goto c1Zv;
c1Zv:
R1 = Main.main1_closure;
jump stg_gc_fun; // [R1]
c1Zn:
if (HpLim == 0) goto c1ZC;
R1 = GHC.Tuple.()_closure+1;
Sp = Sp + 4;
jump I32[Sp]; // [R1]
c1ZC:
HpAlloc = 0;
R1 = R1;
jump stg_gc_unbx_r1; // [R1]
}}}
which is only about 10% slower.
Unfortunately, if you want to guarantee things don't hang, it's not enough
to compile the untrusted code like this; all the other code needs to have
this transformation applied too. So we should probably have a -yielding
flag (like -threaded or -profiling) which allows us to compile yielding
versions of all relevant code. Unfortunately, the number of combinations
of such flags exponentially increases...
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/367#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] #367: Infinite loops can hang Concurrent Haskell
#367: Infinite loops can hang Concurrent Haskell
--+-
Reporter: simonpj | Owner: ezyang
Type: bug | Status: new
Priority: lowest | Milestone: _|_
Component: Compiler |Version: 6.4.1
Resolution: None | Keywords: scheduler
allocation
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by ezyang):
Diff botched, here is a formatted one:
{{{
ezyang@javelin:~/Dev/ghc-master$ git show
commit 5a9aee5e1d5a4d140f451aef6c57ab065c428966
Author: Edward Z. Yang ezy...@mit.edu
Date: Mon Sep 17 18:28:49 2012 +0200
Better implementation for fixing #367.
Signed-off-by: Edward Z. Yang ezy...@mit.edu
diff --git a/compiler/codeGen/StgCmmHeap.hs
b/compiler/codeGen/StgCmmHeap.hs
index fb37391..a70d132 100644
--- a/compiler/codeGen/StgCmmHeap.hs
+++ b/compiler/codeGen/StgCmmHeap.hs
@@ -557,15 +557,22 @@ do_checks checkStack alloc do_gc = do
hp_oflo = CmmMachOp (mo_wordUGt dflags)
[CmmReg hpReg, CmmReg (CmmGlobal HpLim)]
+-- Yielding if HpLim == 0
+yielding = CmmMachOp (mo_wordEq dflags)
+[CmmReg (CmmGlobal HpLim), CmmLit (zeroCLit
dflags)]
+
alloc_n = mkAssign (CmmGlobal HpAlloc) alloc_lit
gc_id - newLabelC
when checkStack $ do
emit = mkCmmIfGoto sp_oflo gc_id
- when (alloc /= 0) $ do
- emitAssign hpReg bump_hp
- emit = mkCmmIfThen hp_oflo (alloc_n * mkBranch gc_id)
+ if (alloc /= 0)
+then do
+ emitAssign hpReg bump_hp
+ emit = mkCmmIfThen hp_oflo (alloc_n * mkBranch gc_id)
+else do
+ emit = mkCmmIfThen yielding (alloc_n * mkBranch gc_id)
emitOutOfLine gc_id $
do_gc -- this is expected to jump back somewhere
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/367#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] #7248: NewCodeGen does not create enough SRT labels when using SplitObjs (was: Error building integer-gmp using stage1 HEAD on OS X)
#7248: NewCodeGen does not create enough SRT labels when using SplitObjs -+-- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (NCG) Version: 7.7 | Keywords: SplitObjs NCG SRT Os: MacOS X | Architecture: x86 Failure: Building GHC failed | Testcase: Blockedby: | Blocking: Related: | -+-- Changes (by darchon): * keywords: = SplitObjs NCG SRT * component: Compiler = Compiler (NCG) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7248#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] #367: Infinite loops can hang Concurrent Haskell
#367: Infinite loops can hang Concurrent Haskell
--+-
Reporter: simonpj | Owner: ezyang
Type: bug | Status: new
Priority: lowest | Milestone: _|_
Component: Compiler |Version: 6.4.1
Resolution: None | Keywords: scheduler
allocation
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by ezyang):
Code bloat is pretty big across the board, but runtime performance hit is
about what I expected.
{{{
NoFib Results
Program SizeAllocs Runtime Elapsed TotalMem
anna +21.8% +0.0% 0.14 0.14 +0.0%
ansi +21.8% +0.0% 0.00 0.00 +0.0%
atom +21.9% +0.0% +0.8% +0.3% +0.0%
awards +21.9% +0.0% 0.00 0.00 +0.0%
banner +21.7% +0.0% 0.00 0.00 +0.0%
bernouilli +21.9% +0.0% -2.1% -1.8% +0.0%
boyer +21.8% +0.0% 0.05 0.05 +0.0%
boyer2 +21.8% +0.0% 0.01 0.01 +0.0%
bspt +21.6% +0.0% 0.02 0.02 +0.0%
cacheprof +21.3% +0.1% +4.2% +4.0% +0.0%
calendar +21.9% +0.0% 0.00 0.00 +0.0%
cichelli +21.8% +0.0% 0.11 0.11 +0.0%
circsim +21.9% +0.0% +2.1% +2.0% +0.0%
clausify +21.9% +0.0% 0.05 0.05 +0.0%
comp_lab_zift +21.9% +0.0% +2.2% +1.1% +0.0%
compress +21.8% +0.0% +3.6% +4.5% +0.0%
compress2 +21.8% +0.0% +0.0% +0.0% +0.0%
constraints +22.0% +0.0% +0.4% +0.4% +0.0%
cryptarithm1 +21.9% +0.0% +1.4% +1.3% +0.0%
cryptarithm2 +21.9% +0.0% 0.02 0.02 +0.0%
cse +21.8% +0.0% 0.00 0.00 +0.0%
eliza +21.5% +0.0% 0.00 0.00 +0.0%
event +21.9% +0.0% 0.17 0.17 +0.0%
exp3_8 +21.9% +0.0% +0.0% +0.0% +0.0%
expert +21.9% +0.0% 0.00 0.00 +0.0%
fem +22.1% +0.0% 0.03 0.03 +0.0%
fft +21.6% +0.0% 0.05 0.05 +0.0%
fft2 +21.6% +0.0% 0.08 0.08 +0.0%
fibheaps +21.9% +0.0% 0.04 0.04 +0.0%
fish +21.8% +0.0% 0.03 0.03 +0.0%
fluid +21.8% +0.0% 0.01 0.01 +0.0%
fulsom +21.7% +0.0% +2.5% +2.5% -0.9%
gamteb +21.7% +0.0% 0.06 0.06 +0.0%
gcd +21.9% +0.0% 0.04 0.04 +0.0%
gen_regexps +21.9% +0.0% 0.00 0.00 +0.0%
genfft +21.8% +0.0% 0.05 0.05 +0.0%
gg +21.7% +0.0% 0.02 0.02 +0.0%
grep +21.8% +0.0% 0.00 0.00 +0.0%
hidden +22.0% +0.0%+15.0%+14.8% +0.0%
hpg +21.7% +0.0% 0.16 0.16 +0.0%
ida +21.9% +0.0% 0.13 0.13 +0.0%
infer +21.8% +0.0% 0.08 0.08 +0.0%
integer +21.9% +0.0%+13.9%+13.9% +0.0%
integrate +21.9% +0.0% -9.1% -8.1% +0.0%
knights +21.9% +0.0% 0.01 0.01 +0.0%
lcss +21.9% +0.0% +0.2% +0.3% +0.0%
life +21.9% +0.0% +5.7% +5.2% +0.0%
lift +21.8% +0.0% 0.00 0.00 +0.0%
listcompr +21.8% +0.0% 0.11 0.11 +0.0%
listcopy +21.8% +0.0% 0.12 0.12 +0.0%
maillist +21.9% +0.0% 0.10 0.10
