Dear GHC developers,
`Making' GHC of cvs update -r ghc-6-2-branch
with ghc-6.2.1
on RedHat Linux (about version 8) libc-2.2, i686
seems to meet a problem:
**
... myfptools ...
...
cd myfptools
./configure
mechvel:
Dear GHC developers,
`Making' GHC of cvs update -r ghc-6-2-branch
with ghc-6.2.1
on RedHat Linux (about version 8) libc-2.2, i686
seems to meet a problem:
**
... myfptools ...
...
cd
On Mon, May 17, 2004 at 04:07:56PM +1000, Donald Bruce Stewart wrote:
mechvel:
Dear GHC developers,
`Making' GHC of cvs update -r ghc-6-2-branch
with ghc-6.2.1
on RedHat Linux (about version 8) libc-2.2, i686
seems to meet a problem:
I advise against giving -H flags to GHC if you have plenty of memory.
Might push up your GC time a lot.
I have absolutely no idea why GHC keeps getting re-invoked. You could
try cd'ing to ghc/compiler and uttering the command line that compiles
PrimOp.lhs manually. Does that continually reinvoke
And it also appears at the run-time.
`Making' docon-2.08-pre (like in previous report enclosed)
under -O,
making the test by cd $(s)/demotest
ghc $pcpdocon --make T_
and running the test byghci $pcpdocon T_ +RTS any space -RTS
It also appears when a particular instance in Pol3_
is replaced with what ghc required earlier.
test log
ghc-6.2.1: internal error: scavenge:
unimplemented/strange closure type 64 @ 0x40603330
---
It also appears under -Onot
:set +sremoves
Addition to my previous two reports:
* this internal error also happens in the test ghci
when docon is compiled under -Onot too.
* But I tried:set +s
before test log
, and with this, the test completed successfully.
-
Serge Mechveliani
[EMAIL
There is a known bug in the one-space compacting garbage collector for
GHC 6.2.1. It is fixed in the 6.2 branch.
This bug is shown up by your space=XXX choice. If you omit space=xxx
you won't use the one-space collector, and the bug will probably vanish.
I am not sure why you use it. Still, it
