#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by lukexi): Also here on x86_64 Mac OS X. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by erikd): Hmm, compiles fine on x86_64 Linux. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by jstolarek): * cc: jan.stolarek@… (added) Comment: Austin sugests that this happened around the time when I pushed my loopification patch (this bug reported on 30 Aug, my patch pushed a day earlier). Panic happens in `splitAtProcPoints` function and I recall that my previous attempt at loopification as a Cmm pass didn't work with LLVM because it broke the invariant that a block may be reachable only from a single procpoint. So, can anyone experiencing this problem try {{{ git revert d61c3ac186c94021c851f7a2a6d20631e35fc1ba }}} and see if this solves the problem? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by erikd): @jstolarek : On powerpc64-linux, if I revert commit d61c3ac186c94021c851f7a2a6d20631e35fc1ba the stage1 build completes and then fails during the stage2 build. This suggests that something in that commit is causing the `expectJust` failure. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by erikd): Replying to [comment:8 jstolarek]:

...

if I revert commit d61c3ac186c94021c851f7a2a6d20631e35fc1ba the stage1 build completes and then fails during the stage2 build.

This is most strange. If stage2 fails after reverting that commit this would mean that you are experiencing some other bug.

Yes, this is another probably unrelated bug.

Did you clean the build tree after reverting the commit?

Yes.

Also, how does stage2 fail? What error do you get?

{{{ "inplace/bin/ghc-stage2" -optc-Werror -optc-Wall -optc-Ilibraries/old- time/include -optc-I'/home/erikd/PPC64/ghc-ppc64/libraries/base/include' -optc-I'/home/erikd/PPC64/ghc-ppc64/rts/dist/build' -optc-I'/home/erikd/PPC64/ghc-ppc64/includes' -optc-I'/home/erikd/PPC64/ghc-ppc64/includes/dist- derivedconstants/header' -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -fPIC -dynamic -H32m -O -Werror -Wall -H64m -O0 -package-name old-time-1.1.0.1 -hide-all- packages -i -ilibraries/old-time/. -ilibraries/old-time/dist-install/build -ilibraries/old-time/dist-install/build/autogen -Ilibraries/old-time /dist-install/build -Ilibraries/old-time/dist-install/build/autogen -Ilibraries/old- time/include -optP-include -optPlibraries/old-time/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package old-locale-1.0.0.5 -XHaskell98 -XCPP -XForeignFunctionInterface -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -c libraries/old- time/cbits/timeUtils.c -o libraries/old-time/dist-install/build/cbits/timeUtils.dyn_o Segmentation fault make[1]: *** [libraries/old-time/dist-install/build/cbits/timeUtils.dyn_o] Error 139 }}} THis is actually the first command run using the second stage compiler. It builds the non dynamic timeUtils.o object successfully and when it builds timeUtils.dyn_o I get this segfault. I'm going to try and build without dyn. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by jstolarek): OK, I'm really puzzled about this segfault in stage2 compiler, but perhaps I can help with panic in `expectJust` - we need to reproduce it. This means you need to revert the reverting commit :) or in other words attempt to build unmodified HEAD and allow stage1 build to fail with panic that you originally reported. After that happens run the command that causes the segfault with `-ddump-cmm -dcmm-lint` added. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by jstolarek): Edward: No, unfortunately I don't have access to one. I asked Richard if he is able to reproduce the problem on his Mac but everything builds fine on his machine. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by jstolarek): * owner: => jstolarek Comment: erikd: Thanks. Are you sure this is the right dump? If compiler panicked during compilation the dump should be incomplete, whereas yours is. But that's not that important - Kazu provided a dump which allows me to figure out what's going on. Below is an explanation of what is going on (no solution yet). Here is how Cmm looks before stack layout (`cFXJ` and `cFXS` are important here): {{{ ==================== Post control-flow optimisations ==================== {offset cFXP: _sCxU::I32 = I32[(old + 12)]; _sCxV::P32 = P32[(old + 8)]; goto cFXI; cFXI: if (Sp - <highSp> < SpLim) goto cFXS; else goto cFXT; cFXT: _sCxW::I32 = _sCxU::I32; if (_sCxW::I32 != 0) goto cFXN; else goto cFXO; cFXN: I32[(young<cFXR> + 4)] = cFXR; R1 = _sCxV::P32; if (R1 & 3 != 0) goto cFXR; else goto cFXU; cFXU: call (I32[R1])(R1) returns to cFXR, args: 4, res: 4, upd: 4; cFXR: _sCxX::P32 = R1; _sCxY::P32 = P32[_sCxX::P32 + 3]; _sCxZ::P32 = P32[_sCxX::P32 + 7]; _cFXZ::I32 = _sCxW::I32 - 1; _sCy0::I32 = _cFXZ::I32; _sCxV::P32 = _sCxZ::P32; _sCxU::I32 = _sCy0::I32; goto cFXJ; cFXJ: if (Sp - <highSp> < SpLim) goto cFXS; else goto cFXT; cFXS: R1 = happyDropStk_rjgW_closure; I32[(old + 12)] = _sCxU::I32; P32[(old + 8)] = _sCxV::P32; call (stg_gc_fun)(R1) args: 12, res: 0, upd: 4; cFXO: R1 = _sCxV::P32 & (-4); call (I32[R1])(R1) args: 4, res: 0, upd: 4; } }}} Stack layout transforms it to: {{{ ==================== Layout Stack ==================== {offset cFXP: _sCxU::I32 = I32[Sp]; _sCxV::P32 = P32[Sp + 4]; goto cFXI; cFXI: goto cFXT; cFXT: _sCxU::I32 = I32[Sp]; _sCxV::P32 = P32[Sp + 4]; _sCxW::I32 = _sCxU::I32; if (_sCxW::I32 != 0) goto cFXN; else goto cFXO; cFXN: I32[Sp] = cFXR; R1 = _sCxV::P32; I32[Sp + 4] = _sCxW::I32; if (R1 & 3 != 0) goto cFXR; else goto cFXU; cFXU: call (I32[R1])(R1) returns to cFXR, args: 4, res: 4, upd: 4; cFXR: _sCxW::I32 = I32[Sp + 4]; _sCxX::P32 = R1; _sCxY::P32 = P32[_sCxX::P32 + 3]; _sCxZ::P32 = P32[_sCxX::P32 + 7]; _cFXZ::I32 = _sCxW::I32 - 1; _sCy0::I32 = _cFXZ::I32; _sCxV::P32 = _sCxZ::P32; _sCxU::I32 = _sCy0::I32; goto cFXJ; cFXJ: goto uFY0; uFY0: I32[Sp] = _sCxU::I32; P32[Sp + 4] = _sCxV::P32; goto cFXT; cFXO: R1 = _sCxV::P32 & (-4); Sp = Sp + 8; call (I32[R1])(R1) args: 4, res: 0, upd: 4; } }}} Notice that `cFXS` block was eliminated during stack layout and we got a new `uFY0` block. Now comes the time for CAF analysis followed by proc- point analysis: {{{ ==================== CAFEnv ==================== [(cFXI, {}), (cFXJ, {}), (cFXN, {}), (cFXO, {}), (cFXP, {}), (cFXR, {}), (cFXT, {}), (cFXU, {}), (uFY0, {})] ==================== procpoint map ==================== [(cFXI, reached by cFXP), (cFXJ, reached by cFXR), (cFXN, reached by cFXT), (cFXO, reached by cFXT), (cFXP, <procpt>), (cFXR, <procpt>), (cFXS, <procpt>), (cFXT, <procpt>), (cFXU, reached by cFXT), (uFY0, reached by cFXR)] }}} Notice that procpoint map refers to deleted `cFXS` block. The problem is that we determine proc-points before stack layout but run proc-point analysis after stack layout. Clearly, stack layout can remove some proc- points that we previously computed and thus invalidate our analysis. I don't have a good idea for a solution yet. We can't compute proc-points after stack layout, because stack-layout needs that information. One idea that comes to my mind is modifying stack layout so that it returns a new list of procpoints, possibly modified. I wonder why does this only happen on MacOS and why only on some machines. I think this should be deterministic and happen always, regardless of operating system. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by jstolarek): Replying to [comment:16 erikd]:

My machine isn't MacOS its Linux, but on powerpc64 (not powerpc). Oh, right. I forgot.

Kazu's machine is x86_64 MacOS. His logs said he's on 32 bit.

Still, I don't understand why this doesn't happen to everyone. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): Sure. I think I can help you. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by jstolarek): Kazu, I pushed a speculative fix into HEAD. Please try to build latest HEAD and tell me whether the problem is gone. Kazu, when you were dumping this Cmm, did you got anything on stderr? On my machine I am getting a warning that `cFXS` and `cFXT` are non-call proc-points. This warning is not in your dump. I suspect the reason is that you did not redirect stderr to the log.txt file. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): I verified that the current GHC head can be build on Mac using 32bit GHC 7.6.3! According to my command history, I specified "2>&1 > log.txt". So, stderr was also recorded, I think. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed Comment: Replying to [comment:23 kazu-yamamoto]:

I verified that the current GHC head can be build on Mac using 32bit GHC 7.6.3! Good. I'm marking this bug as solved.

According to my command history, I specified "2>&1 > log.txt". So, stderr was also recorded, I think. I don't know MacOS, but on Linux this would NOT redirect stderr to log.txt. Redirections are evaluated from left to right, so what you are saying here is: redirect current stderr to *current* stdout (which is the console!) and later you say redirect *current* stdout to a file. It's like assignmnets: {{{ stderr = stdout; stdout = log.txt; }}} This doesn't mean that stderr is now log.txt - Bash is not a functional language :) So you need to say `>log.txt 2>&1`.

No longer getting the originally reported but now get the following: Erik, I think something is very wrong with your build. I'd suggest that you try to pull a clean tree and build there. If that fails I'd mail ghc- devs or fill a bug report.

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): This bug stopped GHC building. I guess that is enough and it is hard to make a regression test. Does anybody have any ideas for regression test? And, sorry for my redirection mistake. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by jstolarek): Well, actually we don't have a test because I couldn't reproduce the problem on my machine and I wasn't able to check whether the test really catches the bug. I just pushed a speculative test into testsuite. Kazu, can you test whether it does the job? Here's what you need to do: {{{ ./sync-all pull make -j4 cd testsuite/tests make TEST=T8205 }}} Since the problem is fixed, this test should pass. Now you need to tests whether the test fails without my fix: {{{ cd ../.. git revert bec3c0497fa55e84005d175e0fc6b1d72df961e1 }}} Now build only stage2 compiler: {{{ make stage=2 -j4 }}} This will give you a broken stage2 compiler. Run the test again: {{{ cd testsuite/test make TEST=T8205 }}} This time it should fail with a panic. If it does, then all is well and we have the test that catches the bug. Could you try doing this and report the results? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): Which version of python is necessary? {{{ Traceback (most recent call last): File "../driver/runtests.py", line 188, in ? from testlib import * File "/home/kazu/work/ghc/testsuite/driver/testlib.py", line 1856 with t.lockFilesWritten: ^ SyntaxError: invalid syntax make: *** [test] Error 1 }}} I'm testing on 32bit Linux. python is version 2.4. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by monoidal): Python 2.4 doesn't support "with", even with the `__future__` import. The `__future__` statement is needed in Python 2.5 and already present in the script. I highly recommend updating Python, version 2.4 has over five years and possibly has security issues. It should be possible to get rid of "with" and replace it with call to acquire/release but there're probably other obstacles to running the script. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): After reverting, I did "make maintainer-clean" and built and tried this test again. On both 32bit and 64bit Linux, I got "4 expected passes". I reverted "bec3c0497fa55e84005d175e0fc6b1d72df961e1". Should I revert other ones? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): I installed GHC head both on 32bit and 64bit Linux today (without haddock). On both Linux, mighttpd2 can be built without any problems. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:37 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8205: the 'impossible' happened : expectJust block_order ----------------------------------------+---------------------------------- Reporter: erikd | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): No problem. If there are something I can do for you, please feel free to ask me. :-) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8205#comment:39 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler