Re: [GHC] #7505: Commentary shipped with GHC sources is outdated
#7505: Commentary shipped with GHC sources is outdated -+-- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Documentation | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Documentation bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): Replying to [comment:3 jstolarek]: If I verified that everything in the commentary is in the wiki would you agree to remove it from the source distribution? Absolutely! Or at the least, we can remove the parts that have moved to the wiki. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7505#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] #4259: Relax restrictions on type family instance overlap
#4259: Relax restrictions on type family instance overlap +--- Reporter: lilac| Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: 6.12.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: |Testcase: Blockedby: |Blocking: Related: | +--- Changes (by liyang): * cc: hackage.haskell.org@… (added) Comment: Is milestone of 7.6.2 still correct, or is this only going into 7.8? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4259#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] #7505: Commentary shipped with GHC sources is outdated
#7505: Commentary shipped with GHC sources is outdated -+-- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Documentation | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Documentation bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by jstolarek): I just noticed that there is yet another version of the old commentary [http://darcs.haskell.org/ghc/docs/comm/ here]. It is linked to from the bottom of the [http://hackage.haskell.org/trac/ghc/wiki/Commentary Commentary] page. This version of comm is not shipped with the sources. Somebody already started to verify which information is in the wiki and which is not. This should make the task easier. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7505#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] #7564: GHC fails without an error when building text-0.11.2.3
#7564: GHC fails without an error when building text-0.11.2.3 -+-- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.6.1 Resolution: duplicate | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = duplicate Comment: looks like a dup of #7565 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7564#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): The `ByteArray#` code seems to come from `vector`, because the `ByteArray#` is inside an `MVector` constructor (from `Data.Vector.Primitive.Mutable`). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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] #7534: allocateRegsAndSpill: Cannot read from uninitialized register
#7534: allocateRegsAndSpill: Cannot read from uninitialized register --+- Reporter: erikd | Owner: simonmar Type: bug| Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Linux Architecture: powerpc64 | Failure: Building GHC failed Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by simonmar): * status: new = infoneeded Comment: More info needed to make progress on this one, the repro case only happens on PPC/Linux. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7534#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] #7501: Some GHCi options are undocummented
#7501: Some GHCi options are undocummented -+-- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Documentation | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * difficulty: = Unknown Comment: `:check` has been around for a long time (I traced it back to 2005), I think it is only for debugging, and we don't want to document it. I'll add docs for `:showi`, I think that was an oversight. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7501#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] #7561: Unnecessary Heap Allocations - Slow Performance
#7561: Unnecessary Heap Allocations - Slow Performance
---+
Reporter: wurmli | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Build System| Version: 7.6.1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by simonpj):
* difficulty: = Unknown
Old description:
Using the vector library operations that should in principle take place
locally and fast, are slow and build a large heap. While trying to
analyse what is going on a strange effect showed. Compiling the attached
small program with heap profiling support produced an executable that
runs fast and uses the heap as expected, whereas built without profiling
support it is slow. The effect shows on linux architectures amd64 and
i386, using ghc 7.6.1 and 7.4.1, respectively.
1) With profiling support
ghc --make -rtsopts -threaded -O2 -prof -fprof-auto heapAllocVec2.hs
./heapAllocVec2 +RTS -s -RTS 3628800
produces
fromList [3628800]
667,829,536 bytes allocated in the heap
125,768 bytes copied during GC
65,560 bytes maximum residency (2 sample(s))
20,096 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
...
Total time0.34s ( 0.35s elapsed)
2) Without profiling support
ghc --make -rtsopts -threaded -O2 heapAllocVec2.hs
./heapAllocVec2 +RTS -s -RTS 3628800
fromList [3628800]
26,098,406,816 bytes allocated in the heap
22,674,848 bytes copied during GC
47,184 bytes maximum residency (2 sample(s))
22,448 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
...
Total time 10.99s ( 11.06s elapsed)
New description:
Using the vector library operations that should in principle take place
locally and fast, are slow and build a large heap. While trying to analyse
what is going on a strange effect showed. Compiling the attached small
program with heap profiling support produced an executable that runs fast
and uses the heap as expected, whereas built without profiling support it
is slow. The effect shows on linux architectures amd64 and i386, using ghc
7.6.1 and 7.4.1, respectively.
1) With profiling support
{{{
ghc --make -rtsopts -threaded -O2 -prof -fprof-auto heapAllocVec2.hs
./heapAllocVec2 +RTS -s -RTS 3628800
produces
fromList [3628800]
667,829,536 bytes allocated in the heap
125,768 bytes copied during GC
65,560 bytes maximum residency (2 sample(s))
20,096 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
...
Total time0.34s ( 0.35s elapsed)
}}}
2) Without profiling support
{{{
ghc --make -rtsopts -threaded -O2 heapAllocVec2.hs
./heapAllocVec2 +RTS -s -RTS 3628800
fromList [3628800]
26,098,406,816 bytes allocated in the heap
22,674,848 bytes copied during GC
47,184 bytes maximum residency (2 sample(s))
22,448 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
...
Total time 10.99s ( 11.06s elapsed)
}}}
--
Comment:
I think your point is: profiling interferes with optimisation. And so it
does. I don't know how to fix that I'm afraid.
Or are you sayig that a non-profiled program is unexpectedly slow?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7561#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] #7562: Parse error with {-# UNPACK #-} Int
#7562: Parse error with {-# UNPACK #-} Int
-+--
Reporter: nomeata | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
This code (note the missing !) causes a parser error:
{{{
module UnpackedFields where
data Pair2 = Pair2 {-# UNPACK #-} Int
}}}
I think a proper error message is more helpful. Also, the docs should
mention that -# UNPACK #- can only be used on strict fields.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7562
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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant -+-- Reporter: nomeata | Owner: simonmar Type: task | Status: infoneeded Priority: normal| Milestone: Component: Runtime System| Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * status: new = infoneeded Comment: Could you point me to the bit of the code you're talking about? I can't find it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7505: Commentary shipped with GHC sources is outdated
#7505: Commentary shipped with GHC sources is outdated -+-- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Documentation | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Documentation bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * difficulty: = Unknown Comment: This is the old commentary before we moved it to the wiki. I think there might still be bits that never got copied over, which is why it's still in the tree. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7505#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] #7522: segfault when ignoring invalid byte sequence when decoding UTF8//IGNORE
#7522: segfault when ignoring invalid byte sequence when decoding UTF8//IGNORE -+-- Reporter: ganesh| Owner: batterseapower Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * owner: = batterseapower * difficulty: = Unknown * priority: normal = high * milestone: = 7.6.2 Comment: I suggest Max might be the best person to look at this, he implemented the support for `//IGNORE`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7522#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant
-+--
Reporter: nomeata | Owner: simonmar
Type: task | Status: new
Priority: normal| Milestone:
Component: Runtime System| Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by nomeata):
* status: infoneeded = new
Comment:
Certainly:
Here, the first element of the instruction list is used to find
{{{nbcd}}}:
http://hackage.haskell.org/trac/ghc/browser/rts/Disassembler.c#L276
The interpreter ignores the value (unless debugging is on):
http://hackage.haskell.org/trac/ghc/browser/rts/Interpreter.c#L789
And here, in assembleBCO, the number of instruction is prepended to the
list of instructions:
http://hackage.haskell.org/trac/ghc/browser/compiler/ghci/ByteCodeAsm.lhs#L156
The assertion in line 161 supports the observation that the information is
duplicated and the size of the ByteArray is correct.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7563: Passing -C flag causes the 'impossible' to happen
#7563: Passing -C flag causes the 'impossible' to happen
--+-
Reporter: jstolarek | Owner:
Type: bug| Status: new
Priority: normal | Component: Driver
Version: 7.7| Keywords:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
Failure: Incorrect warning at compile-time | Blockedby:
Blocking: |Related:
--+-
Passing -C flag to GHC causes compiler panic:
{{{
addFlag by -C on the commandline: Warning:
The -fvia-C flag does nothing; it will be removed in a future GHC
release
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.7.20130108 for x86_64-unknown-linux):
pipeLoop: at phase As but I wanted to stop at phase HCc
}}}
Comment in main/DriverPipeline.hs, lines 665-668 suggests that this
behaviour might happen with native code generator. If C codegen is being
removed, then -C flag should perhaps be removed as well (also from the
documentation)?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7563
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] #7507: loop fusion not working for Int32, Int64 as it does for Int ?
#7507: loop fusion not working for Int32, Int64 as it does for Int ? +--- Reporter: j.waldmann | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Difficulty: Unknown Testcase: perf/should_run/T7507 | Blockedby: Blocking: |Related: +--- Comment(by simonmar): How does it affect code size? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7507#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] #7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5
#7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5
--+-
Reporter: PHO | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: libraries/base |Version: 7.7
Resolution: | Keywords:
Os: MacOS X | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by simonmar):
* status: patch = new
* difficulty: = Unknown
Comment:
I'm suspicious of this fix. If configure is finding the wrong type for
`st_ino`, then that looks like a bug in autoconf. The configure script
for base already has this:
{{{
# Enable large file support. Do this before testing the types ino_t,
off_t, and
# rlim_t, because it will affect the result of that test.
AC_SYS_LARGEFILE
}}}
If this isn't working properly, we need to find out why and inform the
autoconf folks if necessary.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7537#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7539: Hard ghc api crash when calling runStmt on code which has not been compiled
#7539: Hard ghc api crash when calling runStmt on code which has not been compiled -+-- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): I wouldn't be surprised if the GHC API assumes `LinkInMemory` when using interactive evaluation (`runStmt` and friends). So the easy workaround is don't do that, and we should add a test and an error message somewhere. I don't think `NoLink` or `LinkBinary` make much sense here anyway - or do you have a use case in mind? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7539#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] #7500: GHC: internal error: getMBlock: mmap: Operation not permitted
#7500: GHC: internal error: getMBlock: mmap: Operation not permitted +--- Reporter: guest | Owner: Type: bug| Status: new Priority: normal | Milestone: Component: Compiler |Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by simonmar): * status: closed = new * resolution: invalid = Comment: If this is a simple case of running out of memory, then we ought to emit the correct error message rather than a panic. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7500#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] #7539: Hard ghc api crash when calling runStmt on code which has not been compiled
#7539: Hard ghc api crash when calling runStmt on code which has not been
compiled
-+--
Reporter: edsko | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by edsko):
In the layer around GHC we allow enabling or disabling code generation
(i.e., type check only). When disabled, we set `{ hscTarget = HscNothing,
ghcLink = NoLink }`. If then later the code is tried to run anyway, the
above crash can arise. (We guard against this at our layer now, but it
would still be nice if ghc would give us an error message rather than
segfault when we make a mistake).
So, yes, I agree, a check and an error message will suffice.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7539#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant -+-- Reporter: nomeata | Owner: simonmar Type: task | Status: new Priority: normal| Milestone: 7.8.1 Component: Runtime System| Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * milestone: = 7.8.1 Comment: Ah, I see. Yes, I think you're right, this field isn't necessary. It is probably there because the size of an `StgArrWords` used to be stored in units of words, but it was changed to be bytes. I'll remove it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7539: Hard ghc api crash when calling runStmt on code which has not been compiled
#7539: Hard ghc api crash when calling runStmt on code which has not been compiled -+-- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * milestone: = 7.8.1 Comment: Actually, looking at the code, it's a slight mystery to me why this doesn't work now. `LinkInMemory` doesn't cause any linking to happen, since the linking is all done on-demand in `runStmt`, so in fact it ought to work with `NoLink` and even `LinkBinary`. I'll leave the ticket open to look into it, but it's not urgent. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7539#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant
-+--
Reporter: nomeata | Owner: simonmar
Type: task | Status: new
Priority: normal| Milestone: 7.8.1
Component: Runtime System| Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by marlowsd@…):
commit 0c42e301337bdefa94d0c288bb6d689ac33baa4d
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Jan 9 11:51:58 2013 +
remove unnecessary size field in BCO (#7518)
compiler/ghci/ByteCodeAsm.lhs |8 ++--
rts/Interpreter.c |4 +---
2 files changed, 3 insertions(+), 9 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7501: Some GHCi options are undocummented
#7501: Some GHCi options are undocummented
-+--
Reporter: monoidal | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Documentation | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by marlowsd@…):
commit f838d2f3d4ee8876647f190da3b2c858c6a669d4
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Jan 9 09:29:42 2013 +
add docs for :showi language (#7501)
docs/users_guide/ghci.xml | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7501#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant -+-- Reporter: nomeata | Owner: simonmar Type: task | Status: merge Priority: normal| Milestone: 7.8.1 Component: Runtime System| Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * status: new = merge -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant ---+ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal| Milestone: 7.8.1 Component: Runtime System|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * owner: simonmar = * status: merge = new -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant ---+ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal| Milestone: 7.8.1 Component: Runtime System|Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7563: Passing -C flag causes the 'impossible' to happen
#7563: Passing -C flag causes the 'impossible' to happen
-+--
Reporter: jstolarek | Owner: igloo
Type: bug | Status: new
Priority: normal| Milestone: 7.8.1
Component: Driver| Version: 7.7
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Incorrect warning at
compile-time
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by simonmar):
* owner: = igloo
* difficulty: = Unknown
* milestone: = 7.8.1
Comment:
This was broken in the past, fixed by
9c685f44e873f01403fd83209487faa64aeb47fb, and then broken again by this
commit which left a TODO to fix it:
commit f917eeb824cfb7143dde9b12e501d4ddb0049b65
{{{
Author: Ian Lynagh i...@well-typed.com
Date: Tue Aug 7 01:27:44 2012 +0100
Add Unregisterised as a field in the settings file
To explicitly choose whether you want an unregisterised build you now
need to use the --enable-unregisterised/--disable-unregisterised
configure flags.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7563#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] #7561: Unnecessary Heap Allocations - Slow Performance
#7561: Unnecessary Heap Allocations - Slow Performance ---+ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler| Version: 7.6.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * cc: benl, rl@… (added) * component: Build System = Compiler * milestone: = 7.8.1 Comment: I just reproduced it with 7.4.1: the program does appear to run many times faster with profiling ''enabled'', which is indeed very suspicious. I suggest that someone familiar with `vector` has a look to see which optimisation or RULE is not happening. Roman or Ben perhaps? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7561#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant ---+ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal| Milestone: 7.8.1 Component: Runtime System|Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by nomeata): It seems you missed the code in Disassembler.c -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7561: Unnecessary Heap Allocations - Slow Performance
#7561: Unnecessary Heap Allocations - Slow Performance ---+ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler| Version: 7.6.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonpj): * cc: rl@… (removed) * cc: rleshchinskiy@… (added) Comment: Crumbs, I got that totally back to front. The PROFILED program runs faster! (I though it was the un-profiled one.) As Simon says that is deeply mysterious. I've changed Roman's email on the cc list to his gmail address. `vector` is his package. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7561#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] #7518: Instruction list length in bco-instrs redundant
#7518: Instruction list length in bco-instrs redundant
---+
Reporter: nomeata | Owner:
Type: task | Status: closed
Priority: normal| Milestone: 7.8.1
Component: Runtime System|Version: 7.6.1
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by marlowsd@…):
commit 343548da7274cd15aaeabe72c6b37bce78e9af9c
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Jan 9 14:46:03 2013 +
fix disassembler after removal of size field in bco-instrs (#7518)
rts/Disassembler.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7518#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by bgamari): Yes, this lends further support to the hypothesis that the it is mwc- random, not random-source, which is at fault. mwc-random uses an MVector to hold the RNG state. Sadly, I've still been unsuccessful at producing a testcase using only mwc-random. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by bgamari): Indeed, using bound-checked reads and writes in place of the unsafe varieties currently used in System.Random.MWC reveals that uniform1 is the culprit. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by bgamari): In particular, it appears to be the `M.read q i` in `uniformWord32` -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
-+--
Reporter: bgamari | Owner: simonmar
Type: bug | Status: infoneeded
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.7
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime crash
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by bgamari):
Well, it seems that `nextIndex` isn't wrapping correctly when used in
`uniformWord32`. Currently it is implemented as,
{{{
nextIndex :: Integral a = a - Int
nextIndex i = fromIntegral j
where j = fromIntegral (i+1) :: Word8
}}}
If I trace the index values over iterations of `uniformWord32`, I find
that they grow beyond 256, resulting in the crash.
If I implement `nextIndex` with a simple `mod`, on the other hand, things
work fine,
{{{
nextIndex :: Integral a = a - Int
nextIndex i = fromIntegral $ (i + 1) `mod` 256
}}}
Simon, is it possible that the optimizer could be now optimizing out the
cast?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:29
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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): Great analysis, thanks. We do indeed seem to have lost the narrowing in `nextIndex`, and it happens in Core, so nothing to do with the code generator. I'll dig a bit deeper and see if I can find out where we went wrong. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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
Re: [GHC] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): Got it - bogus rules for `narrow8Int#` and friends in `PrelRules`. Fix coming. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
-+--
Reporter: bgamari | Owner: simonmar
Type: bug | Status: infoneeded
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.7
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime crash
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by marlowsd@…):
commit 3af022f3ae6ff3adceb2318cf50549d954e8bbe7
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Jan 9 16:52:16 2013 +
Fix some incorrect narrowing rules (#7361)
e.g. narrow8Int# subsumes narrow16Int#, not the other way around.
compiler/prelude/PrelRules.lhs | 24
1 files changed, 12 insertions(+), 12 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:32
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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf ---+ Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler |Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: infoneeded = closed * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:33 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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf ---+ Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler |Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by bgamari): Thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#comment:34 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] #7564: GHC fails without an error when building text-0.11.2.3
#7564: GHC fails without an error when building text-0.11.2.3 ---+ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: |Related: ---+ I wanted to install GHC-7.6.1 on my server system. It is a CentOS 6. I have downloaded the ghc binary for linux x86_64, installed via make install Then I wanted to install cabal-install from the hackage. I executed bootstrap.sh, and all went ok until it arrived at the text package. GHC stopped there without any error or message. So I downloaded text manually and executed ./Setup compile -v3. I have attached the resulting logs. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7564 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] #7565: GHC fails without an error when building text-0.11.2.3
#7565: GHC fails without an error when building text-0.11.2.3 -+-- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking:|Related: -+-- Coming from [here](https://github.com/haskell/cabal/issues/1173). I installed GHC-7.6.1 from the binary package, on my CentOS 6 webspace. Then I wanted to install `cabal-install`, but the compilation failed at the `text` package without a message. They told me it is an error with GHC, so I try to submit here. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7565 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] #7505: Commentary shipped with GHC sources is outdated
#7505: Commentary shipped with GHC sources is outdated -+-- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Documentation | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Documentation bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by jstolarek): If I verified that everything in the commentary is in the wiki would you agree to remove it from the source distribution? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7505#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] #5777: core lint error with arrow notation and GADTs
#5777: core lint error with arrow notation and GADTs
-+--
Reporter: benmos| Owner:
Type: bug | Status: new
Priority: normal| Milestone: 7.6.2
Component: Compiler | Version: 7.4.2
Keywords: arrows, GADTs | Os: MacOS X
Architecture: Unknown/Multiple | Failure: Compile-time crash
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by altaic):
* version: 7.4.1-rc1 = 7.4.2
* architecture: x86 = Unknown/Multiple
Comment:
This also happens on GHC 7.4.2 x86_64.
{{{
$ ghc --make Test3.hs
[1 of 1] Compiling Main ( Test3.hs, Test3.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.2 for x86_64-apple-darwin):
cgLookupPanic (probably invalid Core; try -dcore-lint)
( $dArrow{v amL} [lid] :: base:Control.Arrow.Arrow{tc r4n}
ghc-prim:GHC.Prim.(-){(w) tc 3D} )
static binds for:
local binds for:
( main:Main.arrif{v rci} [gid[ClassOp]] :: forall (( f{tv acm} [tv] ::
ghc-prim:GHC.Prim.*{(w) tc 34d}
- ghc-prim:GHC.Prim.*{(w) tc 34d} ) :: ghc-prim:GHC.Prim.*{(w) tc 34d}
- ghc-prim:GHC.Prim.*{(w) tc 34d}).
main:Main.ArrowInit{tc rch}
( f{tv acm} [tv] :: ghc-
prim:GHC.Prim.*{(w) tc 34d}
-
ghc-prim:GHC.Prim.*{(w) tc 34d} ) =
forall ( b{tv acn} [tv] ::
ghc-prim:GHC.Prim.*{(w) tc 34d} ).
( f{tv acm} [tv] :: ghc-
prim:GHC.Prim.*{(w) tc 34d}
- ghc-
prim:GHC.Prim.*{(w) tc 34d} ) ( b{tv acn} [tv] :: ghc-prim:GHC.Prim.*{(w)
tc 34d} )
- ghc-
prim:GHC.Tuple.(){(w) tc 40} )
( main:Main.$WBoolVal{v rcH} [gid[DataConWrapper]] ::
main:Main.Value{tc rcj}
ghc-
prim:GHC.Types.Bool{(w) tc 3c} )
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5777#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7475: Mysterious Data.Word Segmentation Fault in GHCi
#7475: Mysterious Data.Word Segmentation Fault in GHCi --+- Reporter: VKS| Owner: Type: bug| Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: ghci, data.word, segfault | Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown|Testcase: Blockedby: 3658 |Blocking: Related: | --+- Comment(by altaic): This doesn't appear to happen with 7.4.2 or in HEAD (7.7.20130109), both x86_64. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7475#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
#7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion --+- Reporter: shachaf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.6.1 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: perf/should_runt/T7436 | Blockedby: Blocking: |Related: --+- Changes (by liyang): * cc: hackage.haskell.org@… (added) Comment: Since this issue affects a large number of users and doesn't seem too contentious, could this fix be included in 7.6.2? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7436#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] #7557: Default implementation for a type class function missing when profiling is enabled
#7557: Default implementation for a type class function missing when profiling
is
enabled
-+--
Reporter: JohnWiegley | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
I tried to reduce this to a simpler case, but was unable to produce the
bug.
At the following line you'll see the function `loadObject'` defined for
the type class `Updatable`:
https://github.com/fpco/gitlib/blob/master/gitlib/Data/Git/Internal.hs#L115
And on this line I create an instance of the `Updatable` type class, with
no override for this function:
https://github.com/fpco/gitlib/blob/master/gitlib/Data/Git/Blob.hs#L47
All is well until I build with profiling, as follows:
{{{
cabal configure \
--enable-tests \
--enable-benchmarks \
--enable-library-profiling \
--enable-executable-profiling \
--ghc-option=-rtsopts \
--ghc-option=-prof \
--ghc-option=-fprof-auto\
--ghc-option=-fprof-auto-calls
cabal build
}}}
When built with profiling, the linker thinks that Blob.hs is trying to
call another version of `loadObject'`,
`_gitlibzm0zi5zi3_DataziGitziInternal_loadObjectzq_C1h_cc`, which is not
defined anywhere. The default implementation in the type class definition
is named `_gitlibzm0zi5zi3_DataziGitziInternal_loadObjectzq_C1g_cc`.
The happens with both 7.4.2 and 7.6.1.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7557
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] #7454: Missing warning about redundant import of classes/types whose members are used
#7454: Missing warning about redundant import of classes/types whose members are
used
-+--
Reporter: EyalLotem | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
Comment(by simonpj@…):
commit a8ea80f19974abc4f1b18734013873292116fff5
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Jan 7 17:50:57 2013 +
Rearrange the computation of unused imports; fixes Trac #7454
compiler/rename/RnNames.lhs | 44
+-
1 files changed, 30 insertions(+), 14 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7454#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] #7454: Missing warning about redundant import of classes/types whose members are used
#7454: Missing warning about redundant import of classes/types whose members are
used
-+--
Reporter: EyalLotem | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
Comment(by simonpj@…):
commit afe9a3b0f1a28c364e8574c7d26962f89dd9806e
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Jan 7 17:52:08 2013 +
Remove two unused imports, detected by the fix to Trac #7454
compiler/basicTypes/Id.lhs |2 +-
compiler/typecheck/Inst.lhs |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7454#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] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure ---+ Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonmar): You can't do an atomic non-blocking read, e.g. if another thread happened to read from the console and grabbed the character after you had called `fdReady` but before calling `read`, then the `read` would block. It is unlikely to happen, because someone would have to use raw `System.Win32` operations to get separate access to the console or whatever, but it's possible. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4144#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
[GHC] #7558: Terrible error message when given and wanted are both insoluble
#7558: Terrible error message when given and wanted are both insoluble
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
In fixing the ambiguity check I came across this tricky program
{{{
data T a b where
MkT :: (a~Maybe b) = a - Maybe b - T a b
f :: T a a - Bool
f (MkT x y) = [x,y] `seq` True
}}}
We get an error message
{{{
Frozen2.hs:12:18:
Could not deduce (a ~ Maybe a)
from the context (a ~ Maybe a)
bound by a pattern with constructor
MkT :: forall a b. a ~ Maybe b = a - Maybe b - T a b,
in an equation for `f'
at Frozen2.hs:12:4-10
`a' is a rigid type variable bound by
the type signature for f :: T a a - Bool at Frozen2.hs:11:6
Relevant bindings include
f :: T a a - Bool (bound at Frozen2.hs:12:1)
x :: a (bound at Frozen2.hs:12:8)
y :: Maybe a (bound at Frozen2.hs:12:10)
In the expression: y
In the first argument of `seq', namely `[x, y]'
In the expression: [x, y] `seq` True
}}}
This error message is nonsense! It arises becuase the insolubles get
both a given insoluble `(a~T a)` and a wanted insoluble with the same
type.
This can also arise, rather more easily, with the new ambiguity check, via
an inaccessible context
{{{
foo :: forall a. (a ~ T a) = a - a
}}}
It's a bit obscure, but it needs fixing.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7558
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] #7556: build/fold causes with ByteString unpack causes huge memory leak
#7556: build/fold causes with ByteString unpack causes huge memory leak --+- Reporter: glguy | Owner: duncan Type: bug| Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Comment(by duncan): Crikey that's some old code. It's also totally wrong, as are the implementations of `foldl` and `foldr`. Patch in the works. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7556#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] #7454: Missing warning about redundant import of classes/types whose members are used
#7454: Missing warning about redundant import of classes/types whose members are used ---+ Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: rename/should_fail/T7454 | Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = fixed * testcase: = rename/should_fail/T7454 Comment: Thanks! Fixed by above patch. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7454#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] #7402: Warn about possible missing -XScopedTypeVariables on errors.
#7402: Warn about possible missing -XScopedTypeVariables on errors. ---+ Reporter: Aninhumer | Owner: Type: feature request | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = fixed Comment: Good point. I've tightened up the ambiguity check for instance declarations. Now you'll get an ambiguous declaration error from the above. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7402#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
-+--
Reporter: bgamari | Owner: simonmar
Type: bug | Status: infoneeded
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.7
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime crash
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by simonmar):
* status: new = infoneeded
Comment:
I reproduced it again today, but the bug still eludes me. The code is
reading and writing beyond the end of a `ByteArray#`, and I can't tell
whether this is a codegen bug or a library bug that has gone unnoticed so
far.
The crash still happens with `-fno-cmm-sink` and with `-fllvm`, which
eliminates the two things that I would be most suspicious of (the Cmm
sinking pass and the native code generator).
The code that writes over the end of the array is
`Data.Random.Source.MWC.$wa`. This function is large and complicated and
the code is TH-generated, so I'm a bit lost here. I tried to follow the
code and couldn't see any codegen bugs though.
The erroneous access happens on the 3rd call, where the arguments are a
normal-looking `MVector`:
{{{
(gdb) p4 0x2c40bde9
0x2c40be00: 0x102
0x2c40bdf8: 0x0
0x2c40bdf0: 0x2c405628
0x2c40bde8: 0x4cc3d0
vectorzm0zi10zi0zi1_DataziVectorziPrimitiveziMutable_MVector_con_info
}}}
and an `Int#` value 1.
Maybe someone familiar with `random-source` could add some debugging tests
and try to narrow down the failure?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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] #7556: build/fold causes with ByteString unpack causes huge memory leak
#7556: build/fold causes with ByteString unpack causes huge memory leak
--+-
Reporter: glguy| Owner: duncan
Type: bug | Status: closed
Priority: normal | Milestone: 7.8.1
Component: libraries (other)|Version: 7.6.1
Resolution: fixed| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by duncan):
* status: new = closed
* resolution: = fixed
Comment:
Fixed in bytestring head, will be in next point releases.
{{{
Tue Jan 8 16:43:21 GMT 2013 Duncan Coutts dun...@community.haskell.org
* Re-implement the foldr and foldl functions and fix unpack fusion
They were just wrong. The old foldr and foldl were doing strict
accumulation when they should be lazy.
Also, the fusion for (List.foldr f z . BS.unpack) was using a
tail-recursive variant on foldr (though not strictly accumulating)
which meant it would build up a huge chain of thunks when it should
be lazy and run in linear space. See ghc ticket 7556
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7556#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by bgamari): I've let the maintainer (James Cook) know. He's been quite responsive in the past so I suspect I'll hear back shortly. Thanks again for your time! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by bgamari): I'm not sure why this didn't occur to me earlier, but it seems much more likely that mwc-random is the culprit here (I'm fairly certain that mwc- random uses ByteArray#s whereas random-source does not). So far my attempts at producing a crashing bit of code (or even one producing valgrind errors) using only mwc-random have turned up nothing, but I'll keep trying. I've let bos know. Perhaps we'll hear from him soon. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf -+-- Reporter: bgamari | Owner: simonmar Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by bos): * cc: bos@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361#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
[GHC] #7559: `./configure --with-macosx-deployment-target=` doesn't work
#7559: `./configure --with-macosx-deployment-target=` doesn't work
-+--
Reporter: altaic| Owner:
Type: bug | Status: new
Priority: normal| Component: Build System
Version: 7.6.1 | Keywords:
Os: MacOS X | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
This is tested on HEAD with OS X 10.8.2 using Xcode 4.5.2.
Any version X in `./configure --with-macosx-deployment-target=X` results
in configure failing with:
{{{ checking Mac OS X deployment target... configure: error: Unknown
deployment target X }}}
Examining configure reveals that the option appears to have bit rotted
since SDK paths all point to /Developer/..., whereas these days it
should point inside the Xcode application bundle.
The SDK path should be gotten by appending
/Platforms/MacOSX.platform/Developer/SDKs/MacOSXversion.sdk to the
output of `xcode-select --print-path`, resulting in something like
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk.
If continuing support for systems with old versions of Xcode is desirable,
we should first try generating a path using `xcode-select`, and if that
fails we should fall back to trying /Developer/
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7559
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] #5928: INLINABLE fails to specialize in presence of simple wrapper
#5928: INLINABLE fails to specialize in presence of simple wrapper ---+ Reporter: tibbe | Owner: tibbe Type: bug | Status: new Priority: normal| Milestone: 7.6.2 Component: Compiler |Version: 7.4.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * owner: = tibbe Comment: Thanks for running with this, Johan. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5928#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] #7332: Kind-defaulting omitted leads to deeply obscure type error
#7332: Kind-defaulting omitted leads to deeply obscure type error ---+ Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.6.2 Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: polykinds/T7332 | Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * status: new = closed * resolution: = fixed Comment: I think it's Too Bad for 7.6, I'm afraid. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7332#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5366: UNPACK is paranoid about a phantom type argument
#5366: UNPACK is paranoid about a phantom type argument -+-- Reporter: ekmett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler|Version: 7.0.3 Resolution: fixed | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: simplCore/should_compile/T5366 | Blockedby: Blocking: |Related: -+-- Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = fixed * testcase: = simplCore/should_compile/T5366 Comment: Fixed in HEAD; see the commit for Trac #3990 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5366#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] #7402: Warn about possible missing -XScopedTypeVariables on errors.
#7402: Warn about possible missing -XScopedTypeVariables on errors. ---+ Reporter: Aninhumer | Owner: Type: feature request | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonpj): Actually I was mixed up. The ambiguity fix would reject this instance, but the original question was about scoped type variables. The trouble is that this is a perfectly legal program ''without'' scoped type variables, with the 'n' meaning forall n. n. I'm not sure how to improve this. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7402#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] #5928: INLINABLE fails to specialize in presence of simple wrapper
#5928: INLINABLE fails to specialize in presence of simple wrapper ---+ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.6.2 Component: Compiler |Version: 7.4.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by tibbe): * owner: tibbe = Comment: I did some work here a while ago. From what I remember, these were the results: I tried to move the specialise pass later, after the main simplifier phases. That had a negative effect on the benchmarks I ran and also resulted in fewer specialisations, as measured by some instrumentation I added. I also tried to add a new specialise pass, again after the main simplifier phases, while leaving the original one (which runs after simpl_gently) untouched. This fixed my some specific case I had, but from what I remember it didn't get some other cases. I remember thinking that that particular approach worked well enough. I think this needs more investigation, like trying to specialise as part of the simplifier, but I'm not working on it at the moment. I will unassign this ticket for now to reflect that. I will assign the ticket to me again if I ever pick this up again. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5928#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] #7279: warning for unused type variables in instance contexts; -fwarn-unreachable-type-variables?
a, Show b) = Eq (T a) In the instance declaration for `Eq (T a)' }}} -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7279#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] #7560: Panic in conflictInstErr when branched type family instances conflict
#7560: Panic in conflictInstErr when branched type family instances conflict
---+
Reporter: goldfire| Owner: goldfire
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.7 | Keywords: TypeFamilies
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: Compile-time crash | Blockedby:
Blocking: |Related:
---+
This code causes the panic:
{{{
{-# LANGUAGE TypeFamilies #-}
type family F a
type instance where
F Int = Int
F Bool = Bool
type instance where
F Int = Char
F Double = Double
}}}
Here is the output:
{{{
ghc: panic! (the 'impossible' happened)
(GHC version 7.7.20121221 for x86_64-apple-darwin):
conflictInstErr
details unavailable
}}}
Fix on the way...
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7560
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] #7560: Panic in conflictInstErr when branched type family instances conflict
#7560: Panic in conflictInstErr when branched type family instances conflict
---+
Reporter: goldfire| Owner: goldfire
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.7 | Keywords: TypeFamilies
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: Compile-time crash | Blockedby:
Blocking: |Related:
---+
Comment(by eir@…):
commit 851e4e7619200a11cfc9bda4bee6072b0245504b
{{{
Author: Richard Eisenberg e...@cis.upenn.edu
Date: Tue Jan 8 23:30:16 2013 -0500
Fix Trac #7560.
Code in conflictInstErr did not handle the case where some branches
of a branched family instance had an error and some didn't. It was
all or nothing. Now, if there are no conflicts for a given branch,
conflictInstErr just ignores the branch instead of panicking.
compiler/typecheck/FamInst.lhs |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7560#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] #7560: Panic in conflictInstErr when branched type family instances conflict
#7560: Panic in conflictInstErr when branched type family instances conflict -+-- Reporter: goldfire |Owner: goldfire Type: bug | Status: closed Priority: normal|Component: Compiler Version: 7.7 | Resolution: fixed Keywords: TypeFamilies | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time crash Blockedby:| Blocking: Related:| -+-- Changes (by goldfire): * status: new = closed * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7560#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] #7559: `./configure --with-macosx-deployment-target=` doesn't work
#7559: `./configure --with-macosx-deployment-target=` doesn't work -+-- Reporter: altaic| Owner: Type: bug | Status: patch Priority: normal| Component: Build System Version: 7.6.1 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking:|Related: -+-- Changes (by altaic): * status: new = patch Comment: Attached is a simple fix that pretty much does what I suggested in the bug report. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7559#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] #7561: Unnecessary Heap Allocations - Slow Performance
#7561: Unnecessary Heap Allocations - Slow Performance +--- Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.6.1| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: Runtime performance bug | Blockedby: Blocking: |Related: +--- Using the vector library operations that should in principle take place locally and fast, are slow and build a large heap. While trying to analyse what is going on a strange effect showed. Compiling the attached small program with heap profiling support produced an executable that runs fast and uses the heap as expected, whereas built without profiling support it is slow. The effect shows on linux architectures amd64 and i386, using ghc 7.6.1 and 7.4.1, respectively. 1) With profiling support ghc --make -rtsopts -threaded -O2 -prof -fprof-auto heapAllocVec2.hs ./heapAllocVec2 +RTS -s -RTS 3628800 produces fromList [3628800] 667,829,536 bytes allocated in the heap 125,768 bytes copied during GC 65,560 bytes maximum residency (2 sample(s)) 20,096 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) ... Total time0.34s ( 0.35s elapsed) 2) Without profiling support ghc --make -rtsopts -threaded -O2 heapAllocVec2.hs ./heapAllocVec2 +RTS -s -RTS 3628800 fromList [3628800] 26,098,406,816 bytes allocated in the heap 22,674,848 bytes copied during GC 47,184 bytes maximum residency (2 sample(s)) 22,448 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) ... Total time 10.99s ( 11.06s elapsed) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7561 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] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure ---+ Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonmar): In principle this is a good change, however I don't agree with the changes in semantics of `hGetBufNonBlocking` and `hGetBufSome`. As it stands right now, `hGetBuf`, `hGetBufNonBlocking` and `hGetBufSome` will all read the same amount of data, if the data is available without blocking. But in your version (unless I've misread it), `hGetBufNonBlocking` will read at most a buffer of data, which seems to me to be an abstraction violation - the buffer size is supposed to be invisible to callers of the `hGetBuf` family. Why make this change? It should be possible to loop and read more data in the same way as `hGetBuf`. The only other minor quibble I have with this patch is that the documentation for `readBuffered` and friends could be improved - it isn't clear what the purpose of the buffer argument is (without reading the code). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4144#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] #7534: allocateRegsAndSpill: Cannot read from uninitialized register
#7534: allocateRegsAndSpill: Cannot read from uninitialized register --+- Reporter: erikd | Owner: simonmar Type: bug| Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Linux Architecture: powerpc64 | Failure: Building GHC failed Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Comment(by simonmar): So the background is that this panic used to be commented out, but I enabled it recently because it makes debugging much easier (with the panic commented out, the compiler will happily generate completely bogus code that will crash at runtime). However, it adds another invariant, as mentioned in the comment: all register must be written before they are read (not an unreasonable assumption, I'm sure you'll agree) I presume this invariant is being violated somewhere. To debug it you'll need to use `-ddump-cmm` and find out where the bogus code comes from. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7534#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] #7400: Strange closure type 17 internal error
#7400: Strange closure type 17 internal error -+-- Reporter: ropoctl | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.6.2 Component: Runtime System |Version: 7.4.2 Resolution: invalid | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by igloo): * status: infoneeded = closed * resolution: = invalid Comment: No response from submitter, so closing -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7400#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] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
#7436: Derived Foldable and Traversable instances become extremely inefficient
due
to eta-expansion
-+--
Reporter: shachaf | Owner:
Type: bug | Status: patch
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by twanvl@…):
commit 49ca2a37bef18aa57235ff1dbbf1cc0434979b1e
{{{
Author: Twan van Laarhoven twa...@gmail.com
Date: Fri Nov 23 15:03:45 2012 +0100
Changed deriving of Functor, Foldable, Traversable to fix #7436. Added
foldMap to derived Foldable instance.
The derived instances will no longer eta-expand the function. I.e.
instead of
fmap f (Foo a) = Foo (fmap (\x - f x) a)
we now derive
fmap f (Foo a) = Foo (fmap f a)
Some superflous lambdas are generated as a result. For example
data X a = X (a,a)
fmap f (X x) = (\y - case y of (a,b) - (f a, f b)) x
The optimizer should be able to simplify this code, as it is just beta
reduction.
The derived Foldable instance now includes foldMap in addition to
foldr.
compiler/prelude/PrelNames.lhs|9 ++-
compiler/typecheck/TcGenDeriv.lhs | 178
++---
2 files changed, 114 insertions(+), 73 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7436#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] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
#7436: Derived Foldable and Traversable instances become extremely inefficient
due
to eta-expansion
--+-
Reporter: shachaf | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 7.6.1
Resolution: fixed| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: perf/should_runt/T7436 | Blockedby:
Blocking: |Related:
--+-
Changes (by simonpj):
* status: patch = closed
* testcase: = perf/should_runt/T7436
* resolution: = fixed
Comment:
Also:
{{{
commit 3d51f271e6819c52508956f2426c4c19dec0b2fb
Author: Twan van Laarhoven twa...@gmail.com
Date: Thu Jan 3 16:24:42 2013 +0100
Added note explaining the lambdas generated by functor deriving code,
and how it compares to the old deriving code which used eta expansion.
}}}
Thanks for the patches!
I added a test in `perf/should_run`. Interestingly the massive difference
is run-time, not in allocation or residency.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7436#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] #7552: ~/.haskeline does nothing in ghci
#7552: ~/.haskeline does nothing in ghci ---+ Reporter: beroal |Owner: Type: bug | Status: closed Priority: normal |Component: GHCi Version: 7.6.1 | Resolution: worksforme Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Other Blockedby: | Blocking: Related: | ---+ Changes (by judahj): * status: new = closed * resolution: = worksforme Comment: `maxHistorySize` takes a `Maybe Int` instead of an `Int`; see the docs for more details: http://trac.haskell.org/haskeline/wiki/UserPrefs Replacing the first line with `maxHistorySize: Just 1` should fix your issue. If not, please reopen this ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7552#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] #7281: GHC 7.4.2 build fails on Fedora17
#7281: GHC 7.4.2 build fails on Fedora17 --+- Reporter: PaulJohnson| Owner: judah.jacobson@… Type: bug| Status: new Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.4.2 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Building GHC failed Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Comment(by judahj): Replying to [comment:7 igloo]: I've applied this change as 6dde36fa0c347dbbb92affe932c5c79d030867db in GHC's 7.6 branch. Judah, could you apply it in the terminfo main repo please? Then I'll pull it into GHC HEAD. Done, thanks; apologies for the delay. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7281#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4211: LLVM: Stack alignment on OSX
#4211: LLVM: Stack alignment on OSX
--+-
Reporter: dterei | Owner: dterei
Type: task | Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler (LLVM) |Version: 6.13
Resolution: | Keywords:
Os: MacOS X | Architecture: x86
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by simonmar):
* status: infoneeded = new
Comment:
I'm slightly unhappy about the solution to this ticket. Since
a9ce36118f0de3aeb427792f8f2c5ae097c94d3f we now align the stack to 16+8
bytes on x86_64, which means that virtually every foreign call now looks
like
{{{
subq $8,%rsp
movl $0,%eax
call foo
addq $8,%rsp
}}}
since most calls on x86_64 pass arguments in registers, the 8 byte
adjustment is to keep the alignment constraint after the return address is
pushed. (The assignment to `%eax` is to keep the ABI happy just in case
the function we're calling is varargs, which is a separate issue).
Now I understand the reason this was done, but I hate having to emit those
two extra instructions around every call. I just wanted to record my
dissatisfaction in this ticket in case it inspires someone to find a
better solution :-)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4211#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] #7498: panic : Register allocator: out of stack slots (need 147)
#7498: panic : Register allocator: out of stack slots (need 147)
--+-
Reporter: erikd| Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.8.1
Component: Compiler |Version: 7.7
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: powerpc
Failure: Building GHC failed | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by marlowsd@…):
commit 03d360f289a1c7e93fedf8cfa274cbe5929cd32c
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Mon Jan 7 12:26:29 2013 +
Fix bugs in allocMoreStack (#7498, #7510)
There were four bugs here. Clearly I didn't test this enough to
expose the bugs - it appeared to work on x86/Linux, but completely by
accident it seems.
1. the delta was wrong by a factor of the slot size (as noted on
#7498)
2. we weren't correctly aligning the stack pointer (sp needs to be
16-byte aligned on x86/x86_64)
3. we were doing the adjustment multiple times in the case of a block
that was both a return point and a local branch target. To fix this I
had to add new shim blocks to adjust the stack pointer, and retarget
the original branches. See comment for details.
4. we were doing the adjustment for CALL instructions, which is
unnecessary and wrong; only JMPs should be preceded by a stack
adjustment.
(Someone with a PPC box will need to update the PPC version of
allocMoreStack to fix the above bugs, using the x86 version as a
guide.)
compiler/nativeGen/AsmCodeGen.lhs | 10 ++--
compiler/nativeGen/PPC/Instr.hs |7 +-
compiler/nativeGen/X86/Instr.hs | 124
+++--
3 files changed, 99 insertions(+), 42 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7498#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] #7510: Immediate seg-fault on 32-bit windows build
#7510: Immediate seg-fault on 32-bit windows build
-+--
Reporter: simonpj | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by marlowsd@…):
commit 03d360f289a1c7e93fedf8cfa274cbe5929cd32c
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Mon Jan 7 12:26:29 2013 +
Fix bugs in allocMoreStack (#7498, #7510)
There were four bugs here. Clearly I didn't test this enough to
expose the bugs - it appeared to work on x86/Linux, but completely by
accident it seems.
1. the delta was wrong by a factor of the slot size (as noted on
#7498)
2. we weren't correctly aligning the stack pointer (sp needs to be
16-byte aligned on x86/x86_64)
3. we were doing the adjustment multiple times in the case of a block
that was both a return point and a local branch target. To fix this I
had to add new shim blocks to adjust the stack pointer, and retarget
the original branches. See comment for details.
4. we were doing the adjustment for CALL instructions, which is
unnecessary and wrong; only JMPs should be preceded by a stack
adjustment.
(Someone with a PPC box will need to update the PPC version of
allocMoreStack to fix the above bugs, using the x86 version as a
guide.)
compiler/nativeGen/AsmCodeGen.lhs | 10 ++--
compiler/nativeGen/PPC/Instr.hs |7 +-
compiler/nativeGen/X86/Instr.hs | 124
+++--
3 files changed, 99 insertions(+), 42 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7510#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] #7510: Immediate seg-fault on 32-bit windows build
#7510: Immediate seg-fault on 32-bit windows build -+-- Reporter: simonpj | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): Could someone on Windows please test with this patch and close the ticket if all is well? Thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7510#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] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure ---+ Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by joeyadams): Thanks for the review. As it stands right now, hGetBuf, hGetBufNonBlocking and hGetBufSome will all read the same amount of data, if the data is available without blocking. I don't think this is the case anymore; see #5843 and commit [https://github.com/ghc/packages- base/commit/370fc0b455f6a03283fbd5c0baa5d08d9115379d 370fc0b]. The issue is that some devices don't support non-blocking I/O (e.g. file handles on Windows). Here's the problematic sequence: * Call `hWaitForInput`. It returns `True` when the buffer is not empty. * Call `hGetBufSome`, which we expect will not block. It first reads bytes from the buffer, then tries to do a non-blocking read. Since the non-blocking IO methods block on Windows, `hGetBufSome` blocks, even after it has read some data. So here are some of our options: * Change semantics of `hGetBufSome` so that it will only block if there is no input. However, there is no guarantee that `hGetBufSome` will return all immediately available bytes. * On Windows, simulate nonblocking and IODevice.ready by continuously issuing reads in a forked thread to a buffer, and having I/O functions read from that buffer. * Deprecate `hGetBufNonBlocking`, `hPutBufNonBlocking`, `hWaitForInput`, and the non-blocking `RawIO` and `BufferedIO` methods. Come up with an alternative design that does not require the system to support non- blocking operation. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4144#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] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure ---+ Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonmar): Ok, I see that `hGetBufSome` already has the behaviour that I claimed is erroneous. That's sad. I'd really like to declare this to be a bug in the Windows implementation of Handles, but perhaps that's impractical. I think it might be possible to implement non-blocking I/O on Windows, but you have to do it differently for every type of Handle (console, socket, com port etc.). We do have a working implementation of `hWaitForInput` (see `libraries/base/cbits/inputReady.c`) but it's horrible. Maybe deprecating the non-blocking APIs is the right way, since we are providing the ability to do asynchronous I/O using threads, and that's much nicer. But before we do that, we should look at how people are using these APIs. The only user of `hGetBufSome` that I know of, lazy bytestring, works just fine with the read a random amount of data semantics. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4144#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] #5391: Better deriving for Typeable
#5391: Better deriving for Typeable -+-- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty:|Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by aavogt): * cc: vogt.adam@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5391#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
[GHC] #7556: build/fold causes with ByteString unpack causes huge memory leak
#7556: build/fold causes with ByteString unpack causes huge memory leak +--- Reporter: glguy| Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.1| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: |Related: +--- module Main where import qualified Data.ByteString as B import Data.Word (Word8) -- works fast without optimizations -- with optimizations this has a space leak -- seems related to fold/build fusion in foldr/unpack main :: IO () main = do let b = B.replicate 1 1 print $ B.length b print $ example1 b -- fast print $ example2 b -- slow search :: [Word8] - Bool search [] = False search (x:xs) = x == 1 || search xs example1, example2 :: B.ByteString - Bool example1 = search . B.unpack example2 = foldr (\x xs - x == 1 || xs) False . B.unpack -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7556 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] #7556: build/fold causes with ByteString unpack causes huge memory leak
#7556: build/fold causes with ByteString unpack causes huge memory leak
+---
Reporter: glguy| Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 7.6.1| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Blockedby:
Blocking: |Related:
+---
Comment(by glguy):
{{{
module Main where
import qualified Data.ByteString as B
import Data.Word (Word8)
-- works fast without optimizations
-- with optimizations this has a space leak
-- seems related to fold/build fusion in foldr/unpack
main :: IO ()
main = do
let b = B.replicate 1 1
print $ B.length b
print $ example1 b -- fast
print $ example2 b -- slow
search :: [Word8] - Bool
search [] = False
search (x:xs) = x == 1 || search xs
example1, example2 :: B.ByteString - Bool
example1 = search . B.unpack
example2 = foldr (\x xs - x == 1 || xs) False . B.unpack
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7556#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] #7556: build/fold causes with ByteString unpack causes huge memory leak
#7556: build/fold causes with ByteString unpack causes huge memory leak
+---
Reporter: glguy| Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 7.6.1| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Blockedby:
Blocking: |Related:
+---
Changes (by shachaf):
* cc: shachaf@… (added)
Comment:
The issue is
[http://hackage.haskell.org/packages/archive/bytestring/0.10.2.0/doc/html/src
/Data-ByteString.html#unpackFoldr here]:
{{{
unpack ps = build (unpackFoldr ps)
{-# INLINE unpack #-}
--
-- Have unpack fuse with good list consumers
--
-- critical this isn't strict in the acc
-- as it will break in the presence of list fusion. this is a known
-- issue with seq and build/foldr rewrite rules, which rely on lazy
-- demanding to avoid bottoms in the list.
--
unpackFoldr :: ByteString - (Word8 - a - a) - a - a
unpackFoldr (PS fp off len) f ch = withPtr fp $ \p - do
let loop q n_ | q `seq` n `seq` False = undefined -- n.b.
loop _ (-1) acc = return acc
loop q nacc = do
a - peekByteOff q n
loop q (n-1) (a `f` acc)
loop (p `plusPtr` off) (len-1) ch
{-# INLINE [0] unpackFoldr #-}
{-# RULES
ByteString unpack-list [1] forall p .
unpackFoldr p (:) [] = unpackBytes p
}}}
When we use `foldr`, `foldr/build` fusion turns the whole expression into
an application of `unpackFoldr`, which is tail recursive and therefore not
sufficiently lazy -- but also not strict in the accumulator, so it builds
up a big thunk. In `example1`, fusion doesn't happen, so the fold happens
over `unpackBytes` instead, which generates list in small chunks that can
be processed lazily.
This looks like a `bytestring` bug to me.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7556#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] #7556: build/fold causes with ByteString unpack causes huge memory leak
#7556: build/fold causes with ByteString unpack causes huge memory leak --+- Reporter: glguy | Owner: duncan Type: bug| Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by igloo): * owner: = duncan * difficulty: = Unknown * component: libraries/base = libraries (other) * milestone: = 7.8.1 Comment: Thanks for the diagnosis. Duncan, could you take a look please? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7556#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] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure ---+ Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by joeyadams): For Windows, couldn't we implement non-blocking I/O correctly by first calling the `inputReady.c` function? That is, change `readRawBufferPtrNoBlock` and `writeRawBufferPtrNoBlock` to first call `fdReady` to make sure the operation won't block before proceeding. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4144#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7510: Immediate seg-fault on 32-bit windows build
#7510: Immediate seg-fault on 32-bit windows build ---+ Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Looks good here, thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7510#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] #4900: DEPENDS pragma
#4900: DEPENDS pragma ---+ Reporter: cdsmith | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.2 Component: Compiler |Version: Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: TH_Depends| Blockedby: Blocking:|Related: ---+ Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4900#comment:59 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] #5757: zero unexpected failures on all tier 1 platforms
#5757: zero unexpected failures on all tier 1 platforms
-+--
Reporter: simonmar | Owner:
Type: task | Status: new
Priority: highest | Milestone: 7.6.2
Component: Test Suite| Version: 7.2.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related: #5785 |
-+--
Comment(by nomeata):
I ran the testsuite of 7.6.2-rc1 on amd64 and found these issues:
{{{
OVERALL SUMMARY for test run started at Sun Jan 6 10:53:49 UTC 2013
3142 total tests, which gave rise to
12420 test cases, of which
10 caused framework failures
9558 were skipped
2798 expected passes
13 had missing libraries
34 expected failures
0 unexpected passes
17 unexpected failures
Unexpected failures:
codeGen/should_runcgrun025 [exit code non-0] (normal)
deriving/should_run T3087 [exit code non-0] (normal)
ghci/scripts ghci014 [bad stderr] (ghci)
perf/compiler T1969 [stat too good] (normal)
perf/compiler T6048 [stat not good enough] (optasm)
safeHaskell/check/pkg01 ImpSafeOnly01 [exit code non-0] (normal)
safeHaskell/check/pkg01 ImpSafeOnly02 [exit code non-0] (normal)
safeHaskell/check/pkg01 ImpSafeOnly03 [stderr mismatch] (normal)
safeHaskell/check/pkg01 ImpSafeOnly04 [exit code non-0] (normal)
safeHaskell/check/pkg01 ImpSafeOnly05 [stderr mismatch] (normal)
safeHaskell/check/pkg01 ImpSafeOnly06 [exit code non-0] (normal)
safeHaskell/check/pkg01 ImpSafeOnly07 [stderr mismatch] (normal)
safeHaskell/check/pkg01 ImpSafeOnly08 [stderr mismatch] (normal)
safeHaskell/check/pkg01 ImpSafeOnly09 [stderr mismatch] (normal)
safeHaskell/check/pkg01 ImpSafeOnly10 [exit code non-0] (normal)
safeHaskell/check/pkg01 safePkg01 [bad exit code] (normal)
typecheck/should_compile tc191 [exit code non-0] (normal)
}}}
I’m attaching the full build log. Maybe zero failures will happen for
7.6.2?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5757#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] #7553: ghc fails to terminate with -O2 or greater
#7553: ghc fails to terminate with -O2 or greater -+-- Reporter: erikd | Owner: Type: bug | Status: infoneeded Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * status: new = infoneeded * difficulty: = Unknown Comment: Can you give us a way to reproduce this please? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7553#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] #7554: Define __SSE__ when compiling with -msse
#7554: Define __SSE__ when compiling with -msse
-+--
Reporter: tibbe | Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
The hashable package needs to know if GHC was invoked with -msse4.1 so it
can call out to faster C code in that case. I'd like to propose that GHC
provides the following defines when running the preprocessor:
{{{
## If SSE is turned on at all:
#define __SSE__ 1
## Only with -msse2 and up:
#define __SSE2__ 1
## Only with -msse4.1 and up:
#define __SSE4_1__ 1
}}}
This behavior is consistent with GCC.
Note that on some platforms SSE2 might be enabled by default and so should
the defines.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7554
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] #7553: ghc fails to terminate with -O2 or greater
#7553: ghc fails to terminate with -O2 or greater -+-- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by erikd): * status: infoneeded = new Comment: I've attached a minimal cabal-ized project which triggers the hang. This hangs from me on x86-64-linux with both ghc-7.4.2 and 7.6.1. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7553#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] #7555: SpecConstr pass hangs
#7555: SpecConstr pass hangs
--+-
Reporter: daniel.is.fischer | Owner:
Type: bug| Status: new
Priority: normal | Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking: |Related:
--+-
From [http://stackoverflow.com/questions/14187413/small-code-snippet-
causes-ghc-to-not-terminate Stack Overflow]:
The code
{{{
{-# LANGUAGE BangPatterns #-}
{-# OPTIONS_GHC -O2 #-}
import qualified Data.Vector.Unboxed.Mutable as MV
import Data.Vector.Unboxed ((!))
import qualified Data.Vector.Unboxed as V
import Control.Monad (forM_)
similar :: V.Vector Char - Int
similar v = l + sum (map (similar' 1 1) checks)
where
(l,checks) = let h = V.head v in V.foldl'
(\(i,is) c - if c == h then (i+1,i:is) else (i+1,is)) (1,[])
(V.tail v)
similar' !r !n !i = if i l-1 v!(n) == v!(i+1) then similar' (r+1)
(n+1) (i+1)
else r
main :: IO ()
main = do
n - getLine
v - MV.replicate (read n) 0
forM_ [1..read n] $ \n' - do
v' - getLine
MV.unsafeWrite v (n'-1) (similar . V.fromList $ v')
V.unsafeFreeze v = V.mapM_ print
}}}
causes GHC to hang in the !SpecConstr pass.
Versions 7.0.* compiled it just fine, 7.2.* to 7.6.1 hang.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7555
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] #3333: GHCi doesn't load weak symbols
#: GHCi doesn't load weak symbols --+- Reporter: heatsink | Owner: hgolden Type: bug| Status: patch Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Keywords: weak, dynamic loading | Os: Linux Architecture: x86| Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by akio): * status: new = patch Comment: I implemented a support for ELF weak symbols on Linux. The implementation follows hgolden's design above, except that it doesn't support undefined weak symbols. The change is implemented in 3 patches: the first one simplifies the code, the second one implements the support, and the third one adds a special symbol !__dso_handle. This is not directly related to weak symbols, but is required to load C++ object files. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/#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] #7553: ghc fails to terminate with -O2 or greater
#7553: ghc fails to terminate with -O2 or greater -+-- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by igloo): Thanks. Possibly a duplicate of #7555. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7553#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] #7555: SpecConstr pass hangs
#7555: SpecConstr pass hangs --+- Reporter: daniel.is.fischer | Owner: Type: bug| Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by igloo): * difficulty: = Unknown Comment: Thanks for the report. Possibly a duplicate of #7553. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7555#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
