- ghc-tickets - Haskell.org

Re: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries
by GHC 16 Jan '13

16 Jan '13

#6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------+----------------------------------------- Reporter: mtjm | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.5 Resolution: fixed | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Building GHC failed | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6086#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries
by GHC 16 Jan '13

16 Jan '13

#6086: Cross compilation fails using system linker for other architecture binaries ---------------------------------+------------------------------------------ Reporter: mtjm | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.5 Keywords: | Os: Linux Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by marlowsd@…): commit f77291d60f33fe601dbe0ff94b0192c5cd4ad6b5 {{{ Author: Simon Marlow <marlowsd(a)gmail.com> Date: Wed Jan 16 14:15:47 2013 +0000 Pass --with-ld=$(LD) to ghc-cabal when configuring packages (#6086) rules/build-package-data.mk | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6086#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries
by GHC 16 Jan '13

16 Jan '13

#6086: Cross compilation fails using system linker for other architecture binaries ---------------------------------+------------------------------------------ Reporter: mtjm | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.5 Keywords: | Os: Linux Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * priority: normal => high Comment: I just ran into the same thing, cross-compiling for Raspberry Pi. Fix coming... -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6086#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 16 Jan '13

16 Jan '13

#6084: Add stg_ap_pnnv and related call patterns ---------------------------------+------------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): A better fix for this just occurred to me. If we're making a tail-call to an unknown function that would require multiple stack frames, we could attempt to shortcut it like this (pseudo code): {{{ if (GET_TAG(fun) != 0 && fun->header.info.f.arity == 5) { // make a fast call with args in regs } else { // make the slow call as before } }}} This is more code of course, but the advantage is that it doesn't require us to guess which call patterns we need. It could be enabled with -O2 only, and only if we're making a call that would need, say, 3 or more frames. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6084#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5
by GHC 16 Jan '13

16 Jan '13

#7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5 ------------------------------------------+--------------------------------- Reporter: PHO | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.7 Resolution: invalid | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: Great, thanks for following this up. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7537#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7299: threadDelay broken in ghci, Mac OS X
by GHC 16 Jan '13

16 Jan '13

#7299: threadDelay broken in ghci, Mac OS X ---------------------------------+------------------------------------------ Reporter: tmcdonell | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.6.2 Component: GHCi | Version: 7.6.1 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): The state in `libraries/base/cbits/DarwinUtils.c` would explain why `threadDelay` would return immediately in GHCi, but I don't see anything that would cause it to crash. In any case, the fix is to move `initialize_timer` and `scaling_factor` into the RTS (or maybe just use the existing RTS facilities). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7299#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7299: threadDelay broken in ghci, Mac OS X
by GHC 16 Jan '13

16 Jan '13

#7299: threadDelay broken in ghci, Mac OS X ---------------------------------+------------------------------------------ Reporter: tmcdonell | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.6.2 Component: GHCi | Version: 7.6.1 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by thorkilnaur): I should mention that I am working on identifying the patch(es) that introduced this problem. The problem is reproducible on my Intel Mac OS X 10.5 (the tn23 builder), sometimes as segmentation faults, but more often as no apparent wait when threadDelay is called via ghci. I am using the tn23 builds as "synchronization points". Using the "repo versions" reported for each build, I have been able to, with some adjustments, to reproduce successful builds and, not least, avoid unsuccessful ones. So far, I have been able to narrow the problem as being introduced between tn23 build 599 (http://darcs.haskell.org/ghcBuilder/builders/tn23/599.html) and build 600 (http://darcs.haskell.org/ghcBuilder/builders/tn23/600.html) (Build 599 is a failed build, but it is possible to repair by applying the changes of patch "da102b36bfee605d4849ab74908886b5270d37ad Fix RTS build on OS X" by hand.) In other words, the adjusted build 599 succeeds and threadDelay seems to work. And build 600 succeeds and threadDelay provides no apparent delay. It is slow going, but I expect to be able to narrow down further within the next couple of days. In the meantime, the present interval may provide some useful hints. Best regards Thorkil -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7299#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7585: Core lint failure when optimizing coercions in branched axioms
by GHC 15 Jan '13

15 Jan '13

#7585: Core lint failure when optimizing coercions in branched axioms -------------------------------+-------------------------------------------- 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: -------------------------------+-------------------------------------------- The attached code causes the failure. Core Lint correctly checks branched axioms for internal consistency -- when using branch ''n'' of an axiom, we must ensure that no branch ''m < n'' can possibly apply, no matter what the instantiation for any type variables in the branch may be. However, the coercion optimizer does not respect this property. It will replace coercions used in axioms with equivalent coercions that do not respect this internal consistency property. Everything works out OK in the end (without {{{-dcore-lint}}}, the file compiles and runs correctly), but we go through an invalid state on the way. In particular, the {{{TrPushAx}}} rules are to blame. I'm not sure what the best fix for this is, but it seems to be my job to find it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7585> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5
by GHC 15 Jan '13

15 Jan '13

#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: ------------------------------------------+--------------------------------- Comment(by PHO): I updated my [https://github.com/phonohawk/packages- base/commit/c7b2cc087a1202903e3042e842154d6166edde72 patch] for a temporary workaround but I think it shouldn't be merged as it will (hopefully) be soon unnecessary. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7537#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7537: [PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5
by GHC 15 Jan '13

15 Jan '13

#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: ------------------------------------------+--------------------------------- Comment(by PHO): You are right. This was indeed an autoconf bug so I sent a patch to the autoconf folks: [http://lists.gnu.org/archive/html/bug- autoconf/2013-01/msg00040.html AC_SYS_LARGEFILE: define _DARWIN_USE_64_BIT_INODE conditionally] -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7537#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0