compiling PrimOp.lhs
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 --prefix=... ... make boot ... run it from ghc or ... -- OK, probably make boot not needed, right? make all make[1]: Entering directory `/disk2/home/mechvel/ghcCVS/myfptools/glafp-utils' --- ===fptools== Recursively making `boot' in mkdependC mkdirhier runstdtest docbook lndir ... PWD = /disk2/home/mechvel/ghcCVS/myfptools/glafp-utils ... ... e1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis ... -c basicTypes/NewDemand.lhs -o stage1/basicTypes/NewDemand.o -ohi stage1/basicTypes/NewDemand.hi ghc: 159979968 bytes, 32 GCs, 3950581/8666736 avg/max bytes residency (4 samples), 20M in use, 0.01 INIT (0.00 elapsed), 1.09 MUT (3.03 elapsed), 0.50 GC (0.55 elapsed) :ghc /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes ... fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include hschooks.h' -no-recomp -H80m -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o -ohi stage1/prelude/PrimOp.hi ./primop-tag.hs-incl:2: Warning: Pattern match(es) are overlapped In the definition of `tagOf_PrimOp': tagOf_PrimOp op = ... *** Now, it stayed at this point for about 50 minutes, no messages appear, ghc-6.2.1, cc1 keep on being re-envoked in turn. I have just interrupted it. This module does not look large, and is given -H80m ... What is the matter, please? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: compiling PrimOp.lhs
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 myfptools ./configure --prefix=... ... make boot ... run it from ghc or ... -- OK, probably make boot not needed, right? make all make[1]: Entering directory `/disk2/home/mechvel/ghcCVS/myfptools/glafp-utils' --- ===fptools== Recursively making `boot' in mkdependC mkdirhier runstdtest docbook lndir ... PWD = /disk2/home/mechvel/ghcCVS/myfptools/glafp-utils ... ... e1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis ... -c basicTypes/NewDemand.lhs -o stage1/basicTypes/NewDemand.o -ohi stage1/basicTypes/NewDemand.hi ghc: 159979968 bytes, 32 GCs, 3950581/8666736 avg/max bytes residency (4 samples), 20M in use, 0.01 INIT (0.00 elapsed), 1.09 MUT (3.03 elapsed), 0.50 GC (0.55 elapsed) :ghc /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes ... fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include hschooks.h' -no-recomp -H80m -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o -ohi stage1/prelude/PrimOp.hi ./primop-tag.hs-incl:2: Warning: Pattern match(es) are overlapped In the definition of `tagOf_PrimOp': tagOf_PrimOp op = ... *** Now, it stayed at this point for about 50 minutes, no messages appear, ghc-6.2.1, cc1 keep on being re-envoked in turn. I have just interrupted it. This module does not look large, and is given -H80m ... What is the matter, please? Do you have a very slow machine? Very low memory? It takes maybe 15-20 minutes to compiler PrimOp.lhs on a 150 MHz SPARCstation-20. Probably not the machine, though. -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: compiling PrimOp.lhs
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: ** make all make[1]: Entering directory `/disk2/home/mechvel/ghcCVS/myfptools/glafp-utils' ... /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes ... fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include hschooks.h' -no-recomp -H80m -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o -ohi stage1/prelude/PrimOp.hi ./primop-tag.hs-incl:2: Warning: Pattern match(es) are overlapped In the definition of `tagOf_PrimOp': tagOf_PrimOp op = ... *** Now, it stayed at this point for about 50 minutes, no messages appear, ghc-6.2.1, cc1 keep on being re-envoked in turn. I have just interrupted it. This module does not look large, and is given -H80m ... What is the matter, please? Do you have a very slow machine? Very low memory? It takes maybe 15-20 minutes to compiler PrimOp.lhs on a 150 MHz SPARCstation-20. Probably not the machine, though. Powerful intel-686 machine, much memory: cpu family : 6 model : 6 model name : AMD Athlon(TM) MP 2000+ stepping: 2 cpu MHz : 1666.742 cache size : 256 KB top --- 115 processes: 112 sleeping, 3 running, 0 zombie, 0 stopped CPU0 states: 7.2% user 92.2% system0.0% nice 0.0% iowait 0.0% idle CPU1 states: 99.1% user 0.4% system0.0% nice 0.0% iowait 0.0% idle Mem: 904512k av, 650588k used, 253924k free, 0k shrd, 60192k buff 234516k active, 108332k inactive Swap: 2048276k av,5936k used, 2042340k free219276k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 20751 niiks 16 0 2360 2360 1724 R99.9 0.2 5640m 0 vim 25220 mechvel9 0 29616 28M 7368 S84.8 3.2 0:04 1 ghc-6.2.1 25224 mechvel 14 0 10420 10M 2496 R14.5 1.1 0:00 1 cc1 24125 mechvel 11 0 1148 1148 800 R 0.3 0.1 0:00 1 top ... -- Maybe, ghc-6.2.1 has a memory leak ... Another reason may be that my GHC competes with other users programs, and they have higher priority (I do not know). Now, I restartedcd myfptools make all It advanced up to ../../ghc/compiler/ghc-inplace -H16m -O ... Text/ParserCombinators/Parsec/Token.hs ... and continues. Probably, this means that the compiler (and its PrimOp) has compiled, and now the `make' is dealing with the library? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: compiling PrimOp.lhs
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 GHC? Weird Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Serge D. Mechveliani | Sent: 17 May 2004 07:34 | To: Donald Bruce Stewart | Cc: [EMAIL PROTECTED] | Subject: Re: compiling PrimOp.lhs | | 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: | | ** | make all | | make[1]: Entering directory | `/disk2/home/mechvel/ghcCVS/myfptools/glafp-utils' | ... | | /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes | ... fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser |-recomp -Rghc-timing -H16M '-#include hschooks.h' |-no-recomp -H80m |-c prelude/PrimOp.lhs |-o stage1/prelude/PrimOp.o -ohi stage1/prelude/PrimOp.hi | | ./primop-tag.hs-incl:2: | Warning: Pattern match(es) are overlapped |In the definition of `tagOf_PrimOp': tagOf_PrimOp op = ... | *** | | Now, it stayed at this point for about 50 minutes, no messages appear, | ghc-6.2.1, cc1 keep on being re-envoked in turn. | I have just interrupted it. | This module does not look large, and is given -H80m ... | | What is the matter, please? | | Do you have a very slow machine? Very low memory? | It takes maybe 15-20 minutes to compiler PrimOp.lhs on a | 150 MHz SPARCstation-20. | | Probably not the machine, though. | | Powerful intel-686 machine, much memory: | | cpu family : 6 | model : 6 | model name : AMD Athlon(TM) MP 2000+ | stepping: 2 | cpu MHz : 1666.742 | cache size : 256 KB | | top | --- | 115 processes: 112 sleeping, 3 running, 0 zombie, 0 stopped | CPU0 states: 7.2% user 92.2% system0.0% nice 0.0% iowait 0.0% idle | CPU1 states: 99.1% user 0.4% system0.0% nice 0.0% iowait 0.0% idle | | Mem: 904512k av, 650588k used, 253924k free, 0k shrd, 60192k buff |234516k active, 108332k inactive | Swap: 2048276k av,5936k used, 2042340k free219276k cached | | PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND | 20751 niiks 16 0 2360 2360 1724 R99.9 0.2 5640m 0 vim | 25220 mechvel9 0 29616 28M 7368 S84.8 3.2 0:04 1 ghc-6.2.1 | 25224 mechvel 14 0 10420 10M 2496 R14.5 1.1 0:00 1 cc1 | 24125 mechvel 11 0 1148 1148 800 R 0.3 0.1 0:00 1 top | ... | -- | | Maybe, ghc-6.2.1 has a memory leak ... | | Another reason may be that my GHC competes with other users programs, | and they have higher priority (I do not know). | | Now, I restartedcd myfptools | make all | It advanced up to | ../../ghc/compiler/ghc-inplace -H16m -O ... | Text/ParserCombinators/Parsec/Token.hs | ... | and continues. | Probably, this means that the compiler (and its PrimOp) has compiled, | and now the `make' is dealing with the library? | | - | Serge Mechveliani | [EMAIL PROTECTED] | | | | | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
cvs ghc-6.2.. internal error
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
...
T_ :set +s
T_ test log
yields
...
...
fromOverX: X[y,z] - K[x,y,z] is the canonical isomorphism.
--- RESULT:
[ghc-6.2.1: internal error: scavenge:
unimplemented/strange closure type 64 @ 0x403c20a4
Please report this as a bug to [EMAIL PROTECTED],
or http://www.sourceforge.net/projects/ghc/
Also the message fromOverX: X[y,z] - K[x,y,z] ...
shows that at this point it works certain particular instance declared
in Pol3_.hs.
Simon P. Jones wrote about this something like
you may so far use old ghc-6xx.
But:
* under -Onot the test runs successfully,
* it is desirable a DoCon-reliable official ghc-new (for -O too).
Please, advise,
-
Serge Mechveliani
[EMAIL PROTECTED]
-- previous report
Dear GHC developers,
I have `made' GHC of cvs update -r ghc-6-2-branch(about May 14)
by ghc-6.2.1 on RedHat Linux (about version 8) libc-2.2, i686.
Now, you have the docon-2.08-pre
test, with Pol3_.hs containing
instance (LinSolvRing (Pol a), CommutativeRing a) =
LinSolvRing (UPol (Pol a))
...
And make space=-M20m docon
(-Onot)
yields
...
...
/home/mechvel/docon/2.08/docon/source/export/Pfact3_.hi:
openBinaryFile: does not exist (No such file or directory)
Compiling Pfact3_
( pol/factor/Pfact3_.hs,
/home/mechvel/docon/2.08/docon/source/export/Pfact3_.o )
INTERFACE HAS CHANGED
No old interface available
ghc-6.2.1: internal error: scavenge_mark_stack:
unimplemented/strange closure type 30 @ 0x41692598
Please report this as a bug to [EMAIL PROTECTED],
or http://www.sourceforge.net/projects/ghc/
Repeating this command, or `making' it from the start under -M30m
avoids this report.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
internal error: scavenge:
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 it.
-
Serge Mechveliani
[EMAIL PROTECTED]
--
Dear GHC developers,
I have `made' GHC of cvs update -r ghc-6-2-branch(about May 14)
by ghc-6.2.1 on RedHat Linux (about version 8) libc-2.2, i686.
Now, you have the docon-2.08-pre
test, with Pol3_.hs containing
instance (LinSolvRing (Pol a), CommutativeRing a) =
LinSolvRing (UPol (Pol a))
...
And make space=-M20m docon
(-Onot)
yields
...
...
/home/mechvel/docon/2.08/docon/source/export/Pfact3_.hi:
openBinaryFile: does not exist (No such file or directory)
Compiling Pfact3_
( pol/factor/Pfact3_.hs,
/home/mechvel/docon/2.08/docon/source/export/Pfact3_.o )
INTERFACE HAS CHANGED
No old interface available
ghc-6.2.1: internal error: scavenge_mark_stack:
unimplemented/strange closure type 30 @ 0x41692598
Please report this as a bug to [EMAIL PROTECTED],
or http://www.sourceforge.net/projects/ghc/
Repeating this command, or `making' it from the start under -M30m
avoids this report.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
internal error
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 PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc-6-2-branch `internal error'
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 should not cause a seg fault. I believe that the bug is already fixed. To test the 6.2-branch compiler (which is what you are trying to do), you need to build the stage-2 compiler, else you'll be running a 6.2-branch compiler linked to a 6.2.1 run-time system, which has the bug. If you sat in fptools/ and typed 'make' you should have successfully built a stage2 compiler; it lives in ghc/compiler/stage2/ghc-inplace. If you use this compiler to compile docon you should be all right. Or, if not, we'd like to know. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Serge D. Mechveliani | Sent: 17 May 2004 09:27 | To: [EMAIL PROTECTED] | Subject: ghc-6-2-branch `internal error' | | Dear GHC developers, | | I have `made' GHC of cvs update -r ghc-6-2-branch(about May 14) | | by ghc-6.2.1 on RedHat Linux (about version 8) libc-2.2, i686. | | Now, you have the docon-2.08-pre | test, with Pol3_.hs containing | | instance (LinSolvRing (Pol a), CommutativeRing a) = | LinSolvRing (UPol (Pol a)) | ... | | And make space=-M20m docon | (-Onot) | yields |... |... | /home/mechvel/docon/2.08/docon/source/export/Pfact3_.hi: | openBinaryFile: does not exist (No such file or directory) |Compiling Pfact3_ | ( pol/factor/Pfact3_.hs, |/home/mechvel/docon/2.08/docon/source/export/Pfact3_.o ) | | INTERFACE HAS CHANGED |No old interface available | |ghc-6.2.1: internal error: scavenge_mark_stack: |unimplemented/strange closure type 30 @ 0x41692598 | Please report this as a bug to [EMAIL PROTECTED], | or http://www.sourceforge.net/projects/ghc/ | | | Repeating this command, or `making' it from the start under -M30m | avoids this report. | | - | Serge Mechveliani | [EMAIL PROTECTED] | | | | | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
