Re: [GHC] #7313: Impossible happened : CLabel.toInfoLbl stg_newMVarzh (was: arm-linux: impossible happened : CLabel.toInfoLbl stg_newMVarzh)
#7313: Impossible happened : CLabel.toInfoLbl stg_newMVarzh
-+--
Reporter: erikd| Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.7 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Building GHC failed | Testcase:
Blockedby: | Blocking:
Related: |
-+--
Comment(by erikd):
It seems the code that's needed looks something like:
{{{
toEntryLbl (CmmLabel m str CmmCode) = ?
}}}
Replacing ? with the obvious `CmmLabel m str CmmCode` results in the
following when the stage2 compiler is run
{{{
ghc-stage2: internal error: scavenge_stack: weird activation record found
on stack: 65310
(GHC version 7.7.20121022 for arm_unknown_linux)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7313#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] #7357: GHC.exe gives an internal error while linking vector's Monadic.hs
#7357: GHC.exe gives an internal error while linking vector's Monadic.hs ---+ Reporter: kapilash| Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler| Version: 7.6.1 Keywords: | Os: Windows Architecture: x86_64 (amd64) | Failure: Compile-time crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * owner: = igloo * difficulty: = Unknown * milestone: = 7.8.1 Comment: Thanks for the report. I'll take a look. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7357#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] #7357: GHC.exe gives an internal error while linking vector's Monadic.hs
#7357: GHC.exe gives an internal error while linking vector's Monadic.hs
---+
Reporter: kapilash| Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 7.8.1
Component: Compiler| Version: 7.6.1
Keywords: | Os: Windows
Architecture: x86_64 (amd64) | Failure: Compile-time crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Description changed by igloo:
Old description:
'''This is the command line output when building vector 0.10.0.1'''
'''c:\local\vector-0.10.0.1'''cabal build
Building vector-0.10.0.1...
Preprocessing library vector-0.10.0.1...
[ 1 of 19] Compiling Data.Vector.Storable.Internal (
Data\Vector\Storable\Intern
al.hs, dist\build\Data\Vector\Storable\Internal.o )
[ 2 of 19] Compiling Data.Vector.Fusion.Util (
Data\Vector\Fusion\Util.hs, dist\
build\Data\Vector\Fusion\Util.o )
[ 3 of 19] Compiling Data.Vector.Fusion.Stream.Size (
Data\Vector\Fusion\Stream\
Size.hs, dist\build\Data\Vector\Fusion\Stream\Size.o )
Data\Vector\Fusion\Stream\Size.hs:25:10: Warning:
No explicit method or default declaration for `*'
In the instance declaration for `Num Size'
Data\Vector\Fusion\Stream\Size.hs:25:10: Warning:
No explicit method or default declaration for `abs'
In the instance declaration for `Num Size'
Data\Vector\Fusion\Stream\Size.hs:25:10: Warning:
No explicit method or default declaration for `signum'
In the instance declaration for `Num Size'
[ 4 of 19] Compiling Data.Vector.Internal.Check (
Data\Vector\Internal\Check.hs,
dist\build\Data\Vector\Internal\Check.o )
[ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
Data\Vector\Fusion\Stre
am\Monadic.hs, dist\build\Data\Vector\Fusion\Stream\Monadic.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc.exe: internal error:
R_X86_64_PC32: Hig
h bits are set in 7fcb3ea95a0 for WaitForSingleObject
(GHC version 7.6.1 for x86_64_unknown_mingw32)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
New description:
'''This is the command line output when building vector 0.10.0.1'''
{{{
c:\local\vector-0.10.0.1cabal build
Building vector-0.10.0.1...
Preprocessing library vector-0.10.0.1...
[ 1 of 19] Compiling Data.Vector.Storable.Internal (
Data\Vector\Storable\Intern
al.hs, dist\build\Data\Vector\Storable\Internal.o )
[ 2 of 19] Compiling Data.Vector.Fusion.Util ( Data\Vector\Fusion\Util.hs,
dist\
build\Data\Vector\Fusion\Util.o )
[ 3 of 19] Compiling Data.Vector.Fusion.Stream.Size (
Data\Vector\Fusion\Stream\
Size.hs, dist\build\Data\Vector\Fusion\Stream\Size.o )
Data\Vector\Fusion\Stream\Size.hs:25:10: Warning:
No explicit method or default declaration for `*'
In the instance declaration for `Num Size'
Data\Vector\Fusion\Stream\Size.hs:25:10: Warning:
No explicit method or default declaration for `abs'
In the instance declaration for `Num Size'
Data\Vector\Fusion\Stream\Size.hs:25:10: Warning:
No explicit method or default declaration for `signum'
In the instance declaration for `Num Size'
[ 4 of 19] Compiling Data.Vector.Internal.Check (
Data\Vector\Internal\Check.hs,
dist\build\Data\Vector\Internal\Check.o )
[ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
Data\Vector\Fusion\Stre
am\Monadic.hs, dist\build\Data\Vector\Fusion\Stream\Monadic.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc.exe: internal error:
R_X86_64_PC32: Hig
h bits are set in 7fcb3ea95a0 for WaitForSingleObject
(GHC version 7.6.1 for x86_64_unknown_mingw32)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7357#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] #6053: packages in GHC should have different versions from hackage if the packages differ
#6053: packages in GHC should have different versions from hackage if the packages differ ---+ Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: libraries/unix|Version: 7.5 Resolution: invalid | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonmar): I definitely think we should change the policy - in fact I typically bump a library as soon as I change it, to avoid this problem. Is the policy written down anywhere? It wouldn't be hard to change, right? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6053#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] #2786: Blackhole loops are not detected and reported in GHCi
#2786: Blackhole loops are not detected and reported in GHCi -+-- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal| Milestone: _|_ Component: GHCi | Version: 6.8.3 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): I looked into this a bit today. One problem is that now GHCi is dynamically linked, we always retain all CAFs (because we set `keepCAFs` to true). This means that any loop that goes through a CAF won't be detected as a black hole, because the CAF is inherently live. I suspect this isn't the only reason that we don't get blackhole exceptions in GHC, though. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2786#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] #7295: bad code for Double literals
#7295: bad code for Double literals
-+--
Reporter: jwlato| Owner: igloo
Type: bug | Status: patch
Priority: high | 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 jwlato@…):
commit 771d376bb6d2ab524741c6d0732718ac2613d2a1
{{{
Author: John Lato jwl...@gmail.com
Date: Mon Oct 8 12:54:55 2012 +0800
add GHC.Float.rationalToFloat, rationalToDouble (fixes #7295)
Adds better support for constant folding of Float/Double literals.
- add rationalToFloat, rationalToDouble with associated Name/Id's in
PrelNames.
- add a matching rule in PrelRules for rationalTo* functions.
compiler/prelude/PrelNames.lhs | 13 +
compiler/prelude/PrelRules.lhs | 29 +
2 files changed, 42 insertions(+), 0 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7295#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] #7295: bad code for Double literals
#7295: bad code for Double literals ---+ Reporter: jwlato| Owner: igloo Type: bug | Status: closed Priority: high | 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: patch = closed * resolution: = fixed Comment: Thanks for the patches; I've applied them. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7295#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] #7311: -odir option changes .o and .hi names of main source file to Main.hi/o
#7311: -odir option changes .o and .hi names of main source file to Main.hi/o
---+
Reporter: slyfox| Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Compiler |Version: 7.6.1
Resolution: wontfix | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by simonmar):
* status: new = closed
* difficulty: = Unknown
* resolution: = wontfix
Comment:
This is the intended behaviour, and it is documented:
[http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-
compilation.html#output-files].
Consider this:
{{{
$ ghc -odir out ../src/foo.hs
}}}
where do you want the object file to go?
If you're using `-odir`, why not put the output files in separate
directories?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7311#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] #7316: GHC segfaults on ARM
#7316: GHC segfaults on ARM -+-- Reporter: laney | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: arm | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * cc: bgamari (added) * difficulty: = Unknown * priority: normal = high * milestone: = 7.6.2 Comment: @bgamari smells like a problem with the ARM linker, any chance you could investigate? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7316#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] #7317: Segmentation fault in RTS' STM code on git master
#7317: Segmentation fault in RTS' STM code on git master
---+
Reporter: bgamari | Owner:
Type: bug | Status: closed
Priority: normal| Milestone: 7.8.1
Component: Runtime System|Version: 7.7
Resolution: fixed | Keywords: rts, stm, segv
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by simonmar):
* status: new = closed
* difficulty: = Unknown
* resolution: = fixed
* milestone: = 7.8.1
Comment:
I believe I just fixed this, in
{{{
commit 412af8c2eb2f2c689f77fa9e061d45eaa37110f1
Author: Simon Marlow marlo...@gmail.com
Date: Mon Oct 22 11:43:18 2012 +0100
Foreign calls can clobber heap stack memory too
We were making an aggressive assumption that foreign calls cannot
clobber heap or stack memory, which for the majority of foreign calls
is true, but we violate the assumption in the implementation of
primops in the RTS. This was causing crashes in some STM tests.
}}}
Please re-open the ticket if you still encounter problems.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7317#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] #7319: +RTS -xc sometimes results in segfault
#7319: +RTS -xc sometimes results in segfault -+-- Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 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): * priority: normal = high * difficulty: = Unknown * component: Compiler = Runtime System * milestone: = 7.6.2 Comment: Could you compile with `-debug` and try gdb again please? You should get a more informative backtrace. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7319#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] #7320: GHC crashes when building on 32-bit Linux in a Linode
#7320: GHC crashes when building on 32-bit Linux in a Linode ---+ Reporter: benl| Owner: simonmar Type: bug | Status: new Priority: high| Milestone: 7.6.2 Component: Runtime System | Version: 7.6.1 Keywords: | Os: Linux Architecture: x86 | Failure: Compile-time crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * cc: tibbe (added) * component: Compiler = Runtime System * priority: normal = high * difficulty: = Unknown * milestone: = 7.6.2 * owner: = simonmar Comment: This rings a bell - it sounds similar to @tibbe's problems on his VPS. I'll need to debug it when I have time. @tibbe set me up an account on his VPS but unfortunately it now seems to have gone away... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7320#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] #6019: 'threadDelay maxBound' results in 'internal error: select failed'
#6019: 'threadDelay maxBound' results in 'internal error: select failed' -+-- Reporter: shahn | Owner: simonmar Type: bug | Status: merge Priority: normal | Milestone: 7.6.2 Component: Runtime System |Version: 7.4.1 Resolution: fixed | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: rts/7087| Blockedby: Blocking: |Related: -+-- Changes (by simonmar): * status: closed = merge * milestone: 7.6.1 = 7.6.2 Comment: We should have merged this one; see #7325 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6019#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] #7325: threadDelay mistreats minBound and maxBound in some configurations
#7325: threadDelay mistreats minBound and maxBound in some configurations -+-- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Runtime System| Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * priority: normal = high * difficulty: = Unknown * milestone: = 7.6.2 Comment: See #6019 for the `maxBound` problem. I haven't investigated the `minBound` problem yet. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7325#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] #5070: dph and new code generator don't play nicely with each other
#5070: dph and new code generator don't play nicely with each other --+- Reporter: ezyang | Owner: benl Type: bug| Status: new Priority: low| Milestone: 7.6.2 Component: Data Parallel Haskell | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown|Testcase: Blockedby: 5065 |Blocking: Related: | --+- Changes (by simonmar): * difficulty: = Unknown * blockedby: 5065, 7330 = 5065 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5070#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] #5070: dph and new code generator don't play nicely with each other
#5070: dph and new code generator don't play nicely with each other --+- Reporter: ezyang | Owner: benl Type: bug | Status: closed Priority: low | Milestone: 7.8.1 Component: Data Parallel Haskell|Version: 7.0.3 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: 5065 Blocking: |Related: --+- Changes (by simonmar): * status: new = closed * resolution: = fixed * milestone: 7.6.2 = 7.8.1 Comment: As far as I know, DPH and the new code generator now get along just fine. At least, the tests all pass, so I'm closing this ticket. Also the ticket is on the wrong milestone, because the new codegen was not working in 7.6. Please re-open if you find a problem in HEAD. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5070#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] #7302: perf-disruptor2-multicast: internal error: evacuate: strange closure type 66562
#7302: perf-disruptor2-multicast: internal error: evacuate: strange closure type 66562 -+-- Reporter: aristidb| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System |Version: 7.4.2 Resolution: worksforme | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = worksforme Comment: Thanks, I'm closing the ticket for now, you can re-open if on closer inspection it does appear to be a GHC bug. Feel free to email me to help out with debugging. You might want to check out our debugging resources at [wiki:Debugging]. The first thing you want to do is narrow down the problem as much as possible by simplifying the test case and removing extraneous code and dependencies. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7302#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] #7323: decoding GADTs gives internal error: stg_ap_v_ret
#7323: decoding GADTs gives internal error: stg_ap_v_ret ---+ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler| Version: 7.7 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: yes Blockedby: |Blocking: Related: | ---+ Comment(by heisenbug): It turns out that simply mixing GADTs + unsafeCoerce triggers the bug. (see freshly attached.. crash.hs) The order of the GADT constructors (being defined) seems to matter, swapping them changes a crash to some (apparently) undefined behaviour (neither output, nor pattern match failure). I suspect that unsafeCoerce does not preserve pointer tagging. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7323#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] #4415: ghci crash on Windows 7 64bits when press Ctrl-L
#4415: ghci crash on Windows 7 64bits when press Ctrl-L -+-- Reporter: isomorphic | Owner: igloo Type: bug | Status: closed Priority: highest | Milestone: 7.6.2 Component: GHCi|Version: 6.12.3 Resolution: fixed | Keywords: windows 7 Os: Windows | Architecture: x86_64 (amd64) Failure: GHCi crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by igloo): * status: patch = closed * resolution: = fixed Comment: I couldn't get it to crash in any sort of terminal on Windows 7, so I believe this is fixed. Thanks Judah! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4415#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] #7323: decoding GADTs gives internal error: stg_ap_v_ret
#7323: decoding GADTs gives internal error: stg_ap_v_ret
+---
Reporter: heisenbug | Owner:
Type: bug| Status: closed
Priority: normal | Milestone: 7.8.1
Component: Compiler |Version: 7.7
Resolution: invalid| Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Runtime crash | Difficulty: Unknown
Testcase: yes| Blockedby:
Blocking: |Related:
+---
Changes (by igloo):
* status: new = closed
* resolution: = invalid
Comment:
`int-e` in #ghc diagnosed this:
{{{
GHC correctly infers that when it gets a value
of type forall a. TypedPair a, then there is no constructor
that can match.
And it happily creates a case statement without alternatives,
relying on the value to be bottom. The code, however, produces
a non-bottom value of the type. What will happen then is
unpredictable. (Interestingly, ghc 7.4.1 created a fresh
bottom value instead, which is arguably more friendly.)
}}}
{{{
Main.main :: GHC.Types.IO ()
[GblId, Str=DmdType b]
Main.main =
case Unsafe.Coerce.unsafeCoerce
@ (Main.TypedPair GHC.Types.Int)
@ (Main.TypedPair (GHC.Prim.Any *))
Main.$WTPInt
of _ {
}
}}}
This therefore looks like it isn't a bug - just an invalid use of
`unsafeCoerce`.
Thanks for taking the time to make such a small testcase, though. And
thanks too to `int-e` for the diagnosis.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7323#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] #7323: decoding GADTs gives internal error: stg_ap_v_ret
#7323: decoding GADTs gives internal error: stg_ap_v_ret
+---
Reporter: heisenbug | Owner:
Type: bug| Status: closed
Priority: normal | Milestone: 7.8.1
Component: Compiler |Version: 7.7
Resolution: invalid| Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Runtime crash | Difficulty: Unknown
Testcase: yes| Blockedby:
Blocking: |Related:
+---
Comment(by int-e):
Interestingly, ghc 7.4.1 used to produce a {{{runTimeError Impossible
case alternative}}} for such cases rather than relying on the given value
to be bottom. Is this the result of an optimization (getting rid of
unreachable default branches in case, say) or an actual regression?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7323#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] #7316: GHC segfaults on ARM
#7316: GHC segfaults on ARM -+-- Reporter: laney | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: arm | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by bgamari): Replying to [comment:2 simonmar]: @bgamari smells like a problem with the ARM linker, any chance you could investigate? Of course. I've recently been having a hard time getting GHC to build on my test machine apparently due to inconsistent compiler options being used by by LLVM and GCC. Nevertheless, I'll take a look at this as soon as the compiler issue is sorted out. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7316#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] #7358: ghc: panic! (The 'impossible' happened) from RnSource.lhs
#7358: ghc: panic! (The 'impossible' happened) from RnSource.lhs +--- Reporter: jeffshaw| Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Testcase: Blockedby: | Blocking: Related: | +--- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7358 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] #7358: ghc: panic! (The 'impossible' happened) from RnSource.lhs
#7358: ghc: panic! (The 'impossible' happened) from RnSource.lhs +--- Reporter: jeffshaw| Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Testcase: Blockedby: | Blocking: Related: | +--- Comment(by jeffshaw): ghc: panic! (the 'impossible' happened) (GHC version 7.4.2 for x86_64-unknown-linux): compiler/rename/RnSource.lhs:430:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars, _, SrcLoc.L _ cls, _) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Here is the source code that creates this error: instance A a = B a = C a where c = a -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7358#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] #7358: ghc: panic! (The 'impossible' happened) from RnSource.lhs
#7358: ghc: panic! (The 'impossible' happened) from RnSource.lhs +--- Reporter: jeffshaw| Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Testcase: Blockedby: | Blocking: Related: | +--- Comment(by jeffshaw): More minimal example: instance A = A = A where a = a -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7358#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] #7359: unix-2.6.0.0 fails to install on mac os x
#7359: unix-2.6.0.0 fails to install on mac os x
+---
Reporter: AndreasVoellmy | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/unix
Version: 7.4.1 | Keywords:
Os: MacOS X | Architecture: x86_64 (amd64)
Failure: Other | Testcase:
Blockedby: | Blocking:
Related: |
+---
Some package I am trying to build with cabal causes cabal to try to
install unix-2.6.0.0 . This fails with the following errors:
{{{
[35 of 38] Compiling System.Posix.Signals (
dist/build/System/Posix/Signals.hs, dist/build/System/Posix/Signals.o )
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pmgn/T/ghc30459_0/ghc30459_0.c:
In function ‘ghc_wrapper_dtUw_sigismember’:
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pmgn/T/ghc30459_0/ghc30459_0.c:8:0:
warning: dereferencing ‘void *’ pointer
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pmgn/T/ghc30459_0/ghc30459_0.c:8:0:
error: void value not ignored as it ought to be
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pmgn/T/ghc30459_0/ghc30459_0.c:
In function ‘ghc_wrapper_dtUF_sigfillset’:
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pmgn/T/ghc30459_0/ghc30459_0.c:10:0:
warning: dereferencing ‘void *’ pointer
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pmgn/T/ghc30459_0/ghc30459_0.c:10:0:
error: invalid use of void expression
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pmgn/T/ghc30459_0/ghc30459_0.c:
In function ‘ghc_wrapper_dtUR_sigdelset’:
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pmgn/T/ghc30459_0/ghc30459_0.c:12:0:
warning: dereferencing ‘void *’ pointer
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pmgn/T/ghc30459_0/ghc30459_0.c:12:0:
error: invalid use of void expression
Failed to install unix-2.6.0.0
}}}
This seems to be a recent problem for me, so it may be due to some
software updates for mac os x. I am running os x version 10.8.2 build
12c60. I have XCode version 4.5.1 with the Command Line Tools
installed. I installed ghc from the haskell-platform after updating the
os x and xcode (and command line tools).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7359
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] #7359: unix-2.6.0.0 fails to install on mac os x
#7359: unix-2.6.0.0 fails to install on mac os x
+---
Reporter: AndreasVoellmy | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/unix
Version: 7.4.1 | Keywords:
Os: MacOS X | Architecture: x86_64 (amd64)
Failure: Other | Testcase:
Blockedby: | Blocking:
Related: |
+---
Comment(by AndreasVoellmy):
Additional piece of info on my configuration:
{{{
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with:
/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~67/src/configure --disable-
checking --enable-werror
--prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-
prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-
slibdir=/usr/lib --build=i686-apple-darwin11 --enable-
llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~67/dst-
llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11-
--host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-
include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7359#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] #7358: ghc: panic! (The 'impossible' happened) from RnSource.lhs
#7358: ghc: panic! (The 'impossible' happened) from RnSource.lhs
---+
Reporter: jeffshaw|Owner:
Type: bug | Status: closed
Priority: normal |Component: Compiler
Version: 7.4.2 | Resolution: duplicate
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Compile-time crash
Testcase: |Blockedby:
Blocking: | Related:
---+
Changes (by michalt):
* status: new = closed
* resolution: = duplicate
Comment:
Thanks for reporting. It seems to be a duplicate of #5951, which is
already fixed. With current HEAD you get something like:
{{{
[1 of 1] Compiling Test ( Test.hs, Test.o )
Test.hs:6:10: Malformed instance: A = A = A
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7358#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] #7358: ghc: panic! (The 'impossible' happened) from RnSource.lhs
#7358: ghc: panic! (The 'impossible' happened) from RnSource.lhs ---+ Reporter: jeffshaw|Owner: Type: bug | Status: closed Priority: normal |Component: Compiler Version: 7.4.2 | Resolution: duplicate Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Compile-time crash Testcase: |Blockedby: Blocking: | Related: ---+ Comment(by jeffshaw): Sorry, I saw 5951, but missed that its version had changed from 7.4.1. Thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7358#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] #7191: hsc2hs can't treat absolute path correctly on Windows.
#7191: hsc2hs can't treat absolute path correctly on Windows.
-+--
Reporter: shelarcy | Owner: igloo
Type: bug | Status: merge
Priority: normal| Milestone: 7.6.2
Component: hsc2hs| Version: 7.4.1
Keywords:| Os: Windows
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by igloo):
* status: patch = merge
Comment:
Applied, thanks.
Please merge to 7.6.
commit 2f1d9d3009d6193cc664d85ec24de20ce0380db4
{{{
Author: shelarcy shela...@gmail.com
Date: Wed Oct 3 13:33:48 2012 +0900
Use filepath's function instead of own (fixes #7191)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7191#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] #7258: Compiling DynFlags is jolly slow
#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: simonpj 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 igloo): * owner: igloo = simonpj Comment: Simon, I think the conclusion was that you'd look into this. Please bounce it back to me if you'd like me to investigate further. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7258#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] #3132: cgCase of PrimAlts needs care in new codegen
#3132: cgCase of PrimAlts needs care in new codegen ---+ Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (NCG)|Version: 6.11 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: x86 Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: 4258 Blocking:|Related: ---+ Comment(by michalt): I haven't looked into this ticket (just found it by accident), but isn't it fixed? Test 3132 is enabled by default and compiles just fine with current master... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3132#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] #7355: panic when bang is misplaced: tc_hs_type: bang
#7355: panic when bang is misplaced: tc_hs_type: bang -+-- Reporter: elaforge| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.6.1 Resolution: duplicate | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = duplicate Comment: Looks like a dup of #7210. Please re-open if not. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7355#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] #7360: Case-of-identical-alts optimisation fails abjectly
#7360: Case-of-identical-alts optimisation fails abjectly
-+--
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:|
-+--
Herbert Valerio Riedel writes: I've been trying to improve/fix a minor
optimization sub-optimality w.r.t to the following code (code like that
results from the generics-based NFData deriver[1]):
{{{
data Foo = Foo1 | Foo2 | Foo3 !Int
rnf1 :: Foo - ()
rnf1 x = case x of
Foo1 - ()
Foo2 - ()
Foo3 {} - ()
}}}
which the current GHC 7.6.1 translates to the following core
expression:
{{{
NFDataTest2.rnf1 =
\ x_aeG -
case x_aeG of _ {
__DEFAULT - GHC.Tuple.();
NFDataTest2.Foo3 ds_deT - GHC.Tuple.()
}
}}}
...whereas I'd have expected it to to compile it to a collapsed
`__DEFAULT`-only case, i.e.
{{{
NFDataTest2.rnf1 =
\ x_aeG - case x_aeG of _ { __DEFAULT - GHC.Tuple.() }
}}}
Now I've been hunting it down to the function `SimplUtils.mkCase1` [2],
which according to the source-code comments, is supposed to merge
identical alternatives, i.e.:
{{{
| 3. Merge identical alternatives.
| If several alternatives are identical, merge them into
| a single DEFAULT alternative. I've occasionally seen this
| making a big difference:
|
| case e of = case e of
| C _ - f x D v - v
| D v - v DEFAULT - f x
| DEFAULT - f x
}}}
...and the `mkCase1` function itself reads as follows:
{{{
mkCase1 dflags scrut case_bndr alts_ty ((_con1,bndrs1,rhs1) :
con_alts)
| all isDeadBinder bndrs1 -- Remember the
default
, length filtered_alts length con_alts -- alternative comes
first
-- Also Note [Dead binders]
= do { tick (AltMerge case_bndr)
; mkCase2 dflags scrut case_bndr alts_ty alts' }
where
alts' = (DEFAULT, [], rhs1) : filtered_alts
filtered_alts = filter keep con_alts
keep (_con,bndrs,rhs) = not (all isDeadBinder bndrs rhs
`cheapEqExpr` rhs1)
}}}
Now the problem seems to be, that `isDeadBinder` returns `False`; so I
hacked up `mkCase1` and inserted a `occurAnalyseExpr` on artificially
constructed single-alternative 'Case' values before applying
`isDeadBinder`, and then it would return `True` and simplify the case
expression as expected.
So now my question is, why isn't the occurrence information available for
the case-alternative's binders (the occInfo is set to `NoOccInfo`) at
`mkCase1`-time? When is occurence analysis performed relative to the
simplifier?
* [1]: [http://hackage.haskell.org/package/deepseq-generics]
* [2]:
[http://www.haskell.org/ghc/docs/7.6.1/html/libraries/ghc-7.6.1/src/SimplUtils.html#mkCase1]
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7360
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] #7360: Case-of-identical-alts optimisation fails abjectly
#7360: Case-of-identical-alts optimisation fails abjectly
-+--
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:|
-+--
Comment(by simonpj):
I was very surprised to see this but you are absolutely right. The reason
the occurrence info does not show the alternative's binders as dead shows
up in `Simplify.simplAlt`. Look at the call to `zapBndrOccInfo`,
controlled by the boolean `keep_occ_info`. Notice that `keep_occ_info` is
false if the scrutinee is a variable, which it usually is. This is
enough to defeat the optimisation.
The reason is described in `Note [zapOccInfo]` in `Simplify.lhs`. If we
have
{{{
case x of { C a b - case x of { C p q - p } }
}}}
Now, `a` and `b` are not mentioned, and are hence dead. But if we were to
optimise the inner case, we'd reduce
{{{
case x of { C p q - p } ===a
}}}
and now `a` is alive. Moreover `mkCase1` is applied use '''after''' the
alternative has been simplified, so now it in fact looks like
{{{
case x of { C a b - a }
}}}
That's why a's occurrence info is zapped: it might not be dead any more.
But in fact the occurrence analyser goes to great trouble (the binder-
swap optimisation) to ensure that if the scrutinee is a variable, we
replace its uses in the alternatives with the case-binder. So the
occurrence analyser will produce this
{{{
case x of y { C a b - case y of { C p q - p } }
}}}
So we really don't need to take the scrutinee into account.
I think I see how to ''both'' simplify the code ''and'' make the
optimisation work again. I need enough time to do some comparative nofib
runs to make sure I hvae not messed up, though.
Thanks for pointing this out.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7360#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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf --+- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Testcase: Blockedby:| Blocking: Related:| --+- I'm experiencing a segmentation fault in previously working code compiled with GHC master (5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf). This occurs with several executables in bayes-stack[1] (BenchLDA and RunST). The easiest reproduction case is BenchLDA, which can be run without any external data (although doesn't get built by the cabal file). In the case of BenchLDA, gdb says that the crash is occurring in c6FD_info which seems to fall within BayesStack.Models.Topic.Types, although -ddump-simpl doesn't seem to give any hints as to which function this is. [1] http://github.com/bgamari/bayes-stack -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7361 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] #7352: this type signature in a case alternative does not typecheck and requires ScopedTypeVariables
#7352: this type signature in a case alternative does not typecheck and requires
ScopedTypeVariables
-+--
Reporter: atnnn |Owner: atnnn
Type: bug | Status: closed
Priority: normal|Component: Compiler (Type checker)
Version: 7.6.1 | Resolution: invalid
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Testcase:|Blockedby:
Blocking:| Related:
-+--
Changes (by atnnn):
* status: new = closed
* resolution: = invalid
Comment:
This is not a bug, just the normal behaviour of GADTs
{{{
{-# LANGUAGE GADTs #-}
data G a where
G :: {unG :: a} - G [a]
test4 (G True) = ()
}}}
test4 fails with
{{{
Could not deduce (a ~ Bool)
from the context (t ~ [a])
}}}
Here is a workaround that works
{{{
test5 g | True - unG g = ()
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7352#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
