October 2013 - ghc-tickets

[GHC] #8139: ghc 7.6.3 fails to build on OS X 10.9
by GHC 01 Nov '13

01 Nov '13

#8139: ghc 7.6.3 fails to build on OS X 10.9 ----------------------------------+------------------------------------- Reporter: darinmorrison | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- ghc 7.6.3 does not compile on OS X 10.9 (as of DP5). There are a few issues that seem to be causing this: 1) gcc is no longer available and the clang compatibility patches of http://ghc.haskell.org/trac/ghc/ticket/7678 are not included in 7.6.3. 2) There is some sort of bug that causes mkdirhier.sh to fail in some cases. 3) There is another bug when compiling RtsProbes.d with DTrace. The problem seems to be triggered by the inclusion of stdint.h. #undef-ing HAVE_STDINT_H only for the compilation of RtsProbes.d (which then includes inttypes.h instead) seems to work for some reason. A better solution may be possible from someone who understands the DTrace machinery better. The issue has has been discussed here: https://github.com/mxcl/homebrew/issues/20546 I have come up with a tentative patch that fixes problems (2) and (3) here (and also pasted below): https://github.com/darinmorrison/homebrew/commit/611c76f6d6701c482559a64fe2… {{{ diff --git a/includes/HsFFI.h b/includes/HsFFI.h index dceabab..bc5e423 100644 --- a/includes/HsFFI.h +++ b/includes/HsFFI.h @@ -21,7 +21,7 @@ extern "C" { #include "stg/Types.h" /* get limits for integral types */ -#ifdef HAVE_STDINT_H +#if defined HAVE_STDINT_H && !defined RTS_PROBES_D /* ISO C 99 says: * "C++ implementations should define these macros only when * __STDC_LIMIT_MACROS is defined before <stdint.h> is included." diff --git a/rts/RtsProbes.d b/rts/RtsProbes.d index 40665ac..8963ca7 100644 --- a/rts/RtsProbes.d +++ b/rts/RtsProbes.d @@ -6,6 +6,8 @@ * * ---------------------------------------------------------------------------*/ +#define RTS_PROBES_D + #include "HsFFI.h" #include "rts/EventLogFormat.h" diff --git a/utils/mkdirhier/mkdirhier.sh b/utils/mkdirhier/mkdirhier.sh index 4c5d5f7..80762f4 100644 --- a/utils/mkdirhier/mkdirhier.sh +++ b/utils/mkdirhier/mkdirhier.sh @@ -1,4 +1,4 @@ #!/bin/sh -mkdir -p ${1+"$@"} +mkdir -p ${1+"./$@"} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8139> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

Re: [GHC] #2648: Report out of date interface files robustly
by GHC 31 Oct '13

31 Oct '13

#2648: Report out of date interface files robustly -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * cc: hvr (added) Comment: @liyang: this should never happen during the normal course of developing and reloading a multi-module program in GHCi. You're probably encountering a different bug with the same symptom. We'd be really grateful if you could find a way to reproduce it; if so just open another ticket and dump your instructions in there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2648#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
by GHC 31 Oct '13

31 Oct '13

#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 -------------------------+------------------------------------------------- Reporter: | Owner: dylukes | Status: closed Type: bug | Milestone: 7.4.2 Priority: high | Version: 7.4.1 Component: | Keywords: rts, strange closure, Runtime System | internal error, os x Resolution: | Architecture: x86_64 (amd64) worksforme | Difficulty: Unknown Operating System: | Blocked By: MacOS X | Related Tickets: Type of failure: | Runtime crash | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by CoreyOConnor): Reproduced the same crash using a slightly different setup: 1. uninstalled the haskell platform 2. removed all haskell software from system 3. installed ghc using homebrew 4. re-ran the repro steps I outline above. The same error occurs. I do not currently see any difference in the two failures. In this case the settings are: {{{ corey-mbp:~ corey$ more /usr/local/Cellar/ghc/7.6.3/lib/ghc-7.6.3/settings [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/local/bin/gcc-4.2"), ("C compiler flags", " -m64 -fno-stack-protector -m64"), ("ar command", "/usr/bin/ar"), ("ar flags", "clqs"), ("ar supports at file", "NO"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("perl command", "/usr/bin/perl"), ("target os", "OSDarwin"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "False"), ("target has .ident directive", "True"), ("target has subsections via symbols", "True"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5899#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
by GHC 30 Oct '13

30 Oct '13

#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 -------------------------+------------------------------------------------- Reporter: | Owner: dylukes | Status: closed Type: bug | Milestone: 7.4.2 Priority: high | Version: 7.4.1 Component: | Keywords: rts, strange closure, Runtime System | internal error, os x Resolution: | Architecture: x86_64 (amd64) worksforme | Difficulty: Unknown Operating System: | Blocked By: MacOS X | Related Tickets: Type of failure: | Runtime crash | Test Case: | Blocking: | -------------------------+------------------------------------------------- Changes (by CoreyOConnor): * cc: simonmar (added) Comment: I think I've encountered a similar error. Not sure. I do not have a short set of repro steps right now. The example program in comment 2 works fine. My repo steps are a bit annoying.... 1. install vty from git@github.com:coreyoconnor/vty.git 2. install yi and yi-contrib from git@github.com:coreyoconnor/yi.git 3. use the following ~/.yi/yi.hs: {{{ module Main where import qualified Yi.Config.Users.Corey as Config main = Config.main }}} 4. start yi 5. enter exactly ":tabedit test.txt". This will create a new "tab" with the test.txt title. 6. type "gt" - next tab 7. type "gT" - previous tab At this point yi crashes. However, due to the terminal setup there may be no output. type "reset" and enter to reset the terminal. The error output by GHC is: {{{ yi-darwin-x86_64: internal error: evacuate: strange closure type 67827 (GHC version 7.6.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The closure type is different each time. The compiler environment is: * GHC 7.6.3 installed via the haskell platform 2013.2.0.0 * Mac OS version 10.8.5 * XCode 5.0 installed and command line tools installed * /usr/bin/gcc is: {{{ Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix }}} The settings used is: {{{ [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -m64 -fno-stack-protector -m64"), ("ar command", "/usr/bin/ar"), ("ar flags", "clqs"), ("ar supports at file", "@ArSupportsAtFile@"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("perl command", "/usr/bin/perl"), ("target os", "OSDarwin"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "False"), ("target has .ident directive", "True"), ("target has subsections via symbols", "True"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5899#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 30 Oct '13

30 Oct '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: patch request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Changes (by simonpj): * priority: high => highest Comment: OK, let's do that. Austin can you go ahead? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 30 Oct '13

30 Oct '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: patch request | Milestone: 7.8.1 Priority: high | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Changes (by errge): * blocking: 8398, 8489 => 8398 Comment: Thanks for the review, I'll look into how current usages is handled and what is the best way to fix these issues. I've created another ticket for this: #8489 and assigned it to myself. In the meantime, by slightly modifying your example, I've confirmed that usages always contains the imports, even if they're not used. So I never get less than what I want. I confirmed this behavior also through the source code via this backtrace: - [[GhcFile(compiler/deSugar/Desugar.lhs#L167)]] - [[GhcFile(compiler/iface/MkIface.lhs#L147)]] - [[GhcFile(compiler/iface/MkIface.lhs#L256)]] - [[GhcFile(compiler/iface/MkIface.lhs#L921)]] - [[GhcFile(compiler/iface/MkIface.lhs#L944)]] So for me this patch would already be very useful in 7.8.1, and yes, I'll work on fixing the remaining edge case that you've just showed. If everyone agrees, please apply this as-is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4900: DEPENDS pragma
by GHC 30 Oct '13

30 Oct '13

#4900: DEPENDS pragma -------------------------------------+------------------------------------ Reporter: cdsmith | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_Depends | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Thanks. I think we need Simon M's ok here, and then perhaps it's good to do. I hope there is good user documentation. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4900#comment:61> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4900: DEPENDS pragma
by GHC 30 Oct '13

30 Oct '13

#4900: DEPENDS pragma -------------------------------------+------------------------------------ Reporter: cdsmith | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_Depends | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by adamgundry): * cc: adam@… (added) * status: new => patch * milestone: 7.6.2 => 7.8.1 Comment: I've updated Patrick's patch to the latest HEAD, which involved switching to use file content hashes rather than modification times (per the fix to #8144) and integrating with the new parallel upsweep (#910). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4900#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 30 Oct '13

30 Oct '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: patch request | Milestone: 7.8.1 Priority: high | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonpj): OK, I'm happy with API, but not so happy with the implementation (though it may do for now). The issue is this: the mi_usages field of the `ModIface` refers to each module that contains the definition of something that is used in this module. Suppose I have {{{ module M where import Big f = p module Big where import P( p ) import Q( q ) }}} Then the `mi_usages` field of M will have an entry for P, but not Q, since Q.q isn't referred to in M. (I think this is right, but the comments need improving.) What you really want here is a single list of the '''direct''' imports, so that you can walk the direct-import tree, isn't it? Currently you are going to get more then you want (because you'll get not only the direct imports, but more besides); and perhaps less than you want (because Q may not have an entry). I don't think the direct-import information is recorded as-such in the `ModIface` currently, but it easily could be. I suppose we could commit the patch as-is (ie perhaps buggy in corner cases), but I want to be sure that you were going to push thorough the Right Thing in due course. As part of that, we need more precise commentary on the fields of `HscTypes.Dependencies`, `TcRnTypes.ImportAvails`, and `mi_usages` of `ModIface`. For example, I wonder whether the `mi_usages` field could be part of the `Dependencies` record. I can help with working this out. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8485: Type roles in GHCi
by GHC 29 Oct '13

29 Oct '13

#8485: Type roles in GHCi ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This works: {{{ λ> data A a; type role A nominal λ> :i A type role A nominal data A a }}} This doesn't: {{{ λ> data A a λ> type role A nominal λ> :i A type role A phantom data A a }}} Accepting role annotations after the definition probably leads to problems when intermediate definitions relied on the earlier role; so I think the second situation should give an error. In fact, in the second snippet GHC does not even require -XRoleAnnotations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4