Re: 'undefined reference to `_imp__Addr_zdfNumAddrOff_closure' (? ????????)
Simon Peyton Jones ([EMAIL PROTECTED]) wrote: [snip] : Subject: 'undefined reference to `_imp__Addr_zdfNumAddrOff_closure' [snip] : I am using GHC 4.08.1 on Win32. Every attempt to compile the code below : results in a message error on link phase. The message is shown after the : code. Appologies if I am too paranoid here---I've been reinstalling software for the last 20 hours or so:-) Are these C identifiers? They are a bit long. ANSI C only guarantees that identifiers up to the first 31 characters can be distinguished. The identifier mentioned above has a length of 32. Regards, Marc van Dongen
Bug report: mkPrimReturnCode: Upd tpl4{-c9vM-}
Hello there, Just after I added some strictness annotations (!) to an algebraic datatype, ghc-4.08 paniced and halted with the following error message: panic! (the `impossible' happened): mkPrimReturnCode: Upd tpl4{-c9vM-} Please report it as a compiler bug to [EMAIL PROTECTED] The annotations were added in a file containing type and data definitions only. The compilation of that file went fine. The compilation of another one depending on the types went wrong:-( I have attached a log. Let me know if you need some more info. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 4903578 University College Cork, NUIC | Fax:+353 21 4903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] ghc-4.08 -prof -auto-all -H20M -recomp -v -fglasgow-exts -cpp -hi-diffs -syslib posix -syslib util -fvia-C -fno-update-analysis -optC-fallow-overlapping-instances -funbox-strict-fields -fno-prune-tydecls -fno-prune-instdecls -ddump-rules -ddump-simpl-stats -O2 -c PSearch.lhs The Glorious Glasgow Haskell Compilation System, version 4.08 literate pre-processor: echo '#line 1 "PSearch.lhs"' /tmp/ghc18636.lpp /usr/local/lib/ghc-4.08/unlit PSearch.lhs - /tmp/ghc18636.lpp real0.0 user0.0 sys 0.0 Effective command line: -prof -auto-all -H20M -recomp -v -fglasgow-exts -cpp -hi-diffs -syslib posix -syslib util -fvia-C -fno-update-analysis -optC-fallow-overlapping-instances -funbox-strict-fields -fno-prune-tydecls -fno-prune-instdecls -ddump-rules -ddump-simpl-stats -O2 -c Haskellised C pre-processor: echo '{-# LINE 1 "PSearch.lhs" -}' /tmp/ghc18636.cpp /usr/local/lib/ghc-4.08/hscpp -v '-DPROFILING' -D__HASKELL__=98 -D__HASKELL1__=5 -D__GLASGOW_HASKELL__=408 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -I. -I/usr/local/lib/ghc-4.08/includes /tmp/ghc18636.lpp /tmp/ghc18636.cpp real0.0 user0.0 sys 0.0 hscpp:CPP invoked: gcc -E -undef -traditional -DPROFILING -D__HASKELL__=98 -D__HASKELL1__=5 -D__GLASGOW_HASKELL__=408 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -I. -I/usr/local/lib/ghc-4.08/includes - /tmp/ghc18636.lpp ghc-4.08:recompile:Input file PSearch.lhs newer than PSearch.o Haskell compiler: /usr/local/lib/ghc-4.08/hsc /tmp/ghc18636.cpp -fglasgow-exts -fallow-overlapping-instances -funbox-strict-fields -fno-prune-tydecls -fno-prune-instdecls -ddump-rules -ddump-simpl-stats -fauto-sccs-on-all-toplevs -fscc-profiling -ffoldr-build-on -fdo-eta-reduction -fdo-lambda-eta-expansion -fcase-of-case -fcase-merge -flet-to-case -fpedantic-bottoms -fsimplify [ -finline-phase0 -fno-rules -fno-case-of-case -fmax-simplifier-iterations2 ] -fspecialise -ffloat-outwards -ffloat-inwards -fsimplify [ -finline-phase1 -fmax-simplifier-iterations4 ] -fsimplify [ -finline-phase2 -fmax-simplifier-iterations2 ] -fsimplify [ -fmax-simplifier-iterations2 ] -fstrictness -fcpr-analyse -fworker-wrapper -fsimplify [ -fmax-simplifier-iterations4 ] -ffloat-outwards -fcse -ffloat-inwards -fsimplify [ -fmax-simplifier-iterations4 ] -fmassage-stg-for-profiling -flet-no-escape -fwarn-overlapping-patterns -fwarn-missing-methods -fwarn-missing-fields -fwarn-deprecations -fwarn-duplicate-exports -fhi! -version=408 -static "-himap=.%.hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/posix%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/concurrent%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/util%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/posix%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/posix%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/concurrent%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/util%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/posix%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/std%.p_hi" "-himap-sep=:"-v -hifile=/tmp/ghc18636.hi -olang=C -ofile=/tmp/ghc18636.hc -F=/tmp/ghc18636_stb.c -FH=/tmp/ghc18636_stb! .h +RTS -H2000 -K100 Glasgow Haskell Compiler, version 4.08, for Haskell 98, compiled by GHC version 4.08 Transformation rules Top-level specialisations FloatOut stats: 322 Lets floated to top level; 40 Lets floated elsewhere; from 287 Lambda groups Strictness analysis statistics Lambda vars: 0/0; Case vars: 218/661; Let vars: 29/232 FloatOut stats: 18 Lets floated to top level; 3 Lets floated elsewhere; from 203 Lambda groups Grand total simplifi
ghc-4.08 core dumps: probably parenthesis related
Hello all, Yesterday I downloaded ghc-4.08 (thanks again to Simon). When I ran ghc-4.08 today I got a $ ghc geom.hs Segmentation Fault - core dumped I think it is caused by the following contrived list-comprehension. c' = [ e | e - c, ((elem e ls) ] Note that the level of parentheses is not ok. Hope this helps. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 4903578 University College Cork, NUIC | Fax:+353 21 4903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
Re: Integer arithmetic broken (again)
Sven Panne ([EMAIL PROTECTED]) wrote: : [EMAIL PROTECTED] might be the more appropriate list. A reader of that list asked me explicitly not to send it to that list because he thought it wasn't appropriate to sent cvs-bug messages to that list:-) I'll send further error messages to cvs-ghc in the future. It does seem to be more appropriate. : Could you send a (small) program exhibiting *what* is broken? : Guessing one of the many numerical operations on Integers is a : little bit hard... :-) [see below] : I decided to rebuild because of an email from yesterday that : suggested that gcd had been improved---but I may have understood : this incorrectly. : : GCD on Int/Integer now uses the GMP lib, not the generic version for : Integral types. Furthermore, compile-time constant folding in general : has been improved (or broken by me :-} since 4.06, so it could be a : bug there, too, so an example would really be helpful. Sending a small program will be very difficult. the next email I'll send to you will be a tarball with instructions of how to generate an example which produces wrong output. I've spent too much time on this in the past and am too bussy to have alook at it myself at the moment. Sorry about that. Regards, Marc
Integer arithmetic broken (again)
Hello there, I downloaded the latest version of ghc from CVS yesterday, rebuilt and noticed that the Integer arithmetic is broken again. I decided to rebuild because of an email from yesterday that suggested that gcd had been improved---but I may have understood this incorrectly. Please feel free to contact me for further information. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 4903578 University College Cork, NUIC | Fax:+353 21 4903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
mkdependHS (proposal for improvement)
Hi there, I don't know if this is a known problem. The ``problem'' with mkdependHS is when it is used in conjunction with happy. The imports in the .ly file are not recognised and one has to rebuild sources by hand. I am surprised I never noticed this before and it isn't a big problem. Just a thought. Regards, Marc
Re: Recent Sparc breakage
[Me reporting: Integer artithmetic broken.] [Simon Marlow reporting: Integer arithmetic possibly fixed.] Hello again, It has taken me 8 days to rebuild ghs from cvs after this report. Unfortunately I have to report thast the Integer arithmetic is still broken. Pleases feel free to contact me for further info:. Regards, Marc van Dongen
cvs: make all - SocketPrim error
Hi all, When making ghc from cvs, make all fails due to a SocketPrim -syslib lang -syslib text -optc-DNON_POSIX_SOURCE -c SocketPrim.lhs -o SocketPrim.o -osuf o does not exist Action: getDirectoryContents Reason: no such file or directory /newdisk/dongen/CVS/fptools/hslibs/text/parsec make[2]: *** [SocketPrim.o] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 Just to let you know. Log appended. Regards, Marc van Dongen ===fptools== Recursively making `all' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/CVS/fptools ==fptools== make all -r; in /newdisk/dongen/CVS/fptools/glafp-utils ===fptools== Recursively making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/CVS/fptools/glafp-utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/CVS/fptools/glafp-utils/mkdependC make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/CVS/fptools/glafp-utils/lndir make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/CVS/fptools/glafp-utils/ltx make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/CVS/fptools/glafp-utils/mkdirhier make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/CVS/fptools/glafp-utils/runstdtest make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/CVS/fptools/glafp-utils/sgmlverb make[2]: Nothing to be done for `all'. ===fptools== Finished making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/CVS/fptools/glafp-utils ==fptools== make all -r; in /newdisk/dongen/CVS/fptools/ghc ===fptools== Recursively making `all' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/CVS/fptools/ghc ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/CVS/fptools/ghc/utils ===fptools== Recursively making `all' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/CVS/fptools/ghc/utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/CVS/fptools/ghc/utils/hp2ps make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/CVS/fptools/ghc/utils/hscpp make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/CVS
SocketPrim (more info)
Sorry about the previous messgae. Perhaps I shold have bee a bit more explicit about what I deid in order to build ghc from cvs. What I did (starting this morning) was: make clean \ cvs update -Pd ghc hslibs \ cd ghc \ ./configure \ cd .. \ ./configure \ make boot \ make all Regards, Marc van Dongen
FastString.lhs:629: parse error on input `#'
Hi again, When trying to build ghc from cvs (cvs update, make clean, etc) I got: utils/FastString.o -osuf o FastString.lhs:629: parse error on input `#' Compilation had errors make[2]: *** [utils/FastString.o] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 log appended. Regards, Marc van Dongen -- ===fptools== Recursively making `all' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb make[2]: Nothing to be done for `all'. ===fptools== Finished making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `all' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `all' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hp2ps make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hscpp make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/mkdependHS make INSTALLING=0 BIN_DIST=0 - --no-print-directory -r all make[4]: Nothing to be done for `all
Re: FastString.lhs:629: parse error on input `#'
George Russell ([EMAIL PROTECTED]) wrote: : Marc van Dongen wrote: [error at line 629] : Odd, because I get (from the anon-cvs repository) : : /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -cpp -fglasgow-exts -Rghc-timing -I. :-IcodeGen -InativeGen -Iparser :-iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:nativeGen : -recomp -H40m -Onot -c utils/FastString.lhs -o utils/FastString.o -osuf o : : FastString.lhs:632: : Couldn't match : `ByteArray Int' against `MutableByteArray RealWorld Int' : Expected type: ByteArray Int : Inferred type: MutableByteArray RealWorld Int : In the second argument of `hPutBufBA', namely `mba' : In a do statement: hPutBufBA handle mba (I# l#) : : Compilation had errors : : : "cvs status" tells me that my copy of FastString.lhs is up-to-date. Maybe you build with a different ghc-version? #if __GLASGOW_HASKELL__ 405 | otherwise = hPutBufBA handle (ByteArray bot ba#) (I# l#) #elsif __GLASGOW_HASKELL__ 407 | otherwise = hPutBufBA handle (ByteArray bot bot ba#) (I# l#) #else | otherwise = do mba - stToIO $ unsafeThawByteArray (ByteArray (bot::Int) bo hPutBufBA handle mba (I# l#) Just a guess. Regards, Marc van Dongen
Re: cvs: make all - error PackedString.lhs
Sven Panne ([EMAIL PROTECTED]) wrote: : Marc van Dongen wrote: : Just to let jou know. I just updated and tried to rebuild : ghc from cvs. I then got: : : PackedString -c PackedString.lhs -o PackedString.o -osuf o : [...] : : I've already fixed that one (and a related bug in ghc itself) : yesterday evening. But I don't know when exactly these changes : are mirrored in the anonCVS. That probably explains it. I updated yesterday rebuilt (failed) and then posted the report. Regards, Marc
Re: -O2 == crash
Marcin 'Qrczak' Kowalczyk ([EMAIL PROTECTED]) wrote: : Thu, 9 Mar 2000 01:58:02 -0800, Simon Marlow [EMAIL PROTECTED] pisze: : : So the likely candidate would appear to be your gcc - which version : do you have installed? : : 2.95.1 : : With -O -O2-for-C it still crashes. With -O it does not. : With -O2-for-C it does not. Hi Macin, I installed gcc-2.95 some months ago and downgraded to 2.8.1 because I couldn't get it running. gcc-2.8.1 seemed to work fine (until a few days ago). Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
Re: Enum instance for Ratio
George Russell ([EMAIL PROTECTED]) wrote: : Marc van Dongen wrote: : Wouldn't that make Enum depend on Ord? : Doesn't seem to make sense if classes are : enumerable but not comparable. Of course above I should have said orderable in stead of comparable. : What examples are there of types for which it would be sensible to implement : Enum but not Ord? The concept rather puzzles me. In particular, suppose you : don't have an ordering on the pair (a,b). How do you propose to compute :[a..b] data Human = Woman | Man I can see reasons why I would like to know which Humans are there from a to b given a certain predifined order. Bu having said that I also think that in order to implement this, it is not necesary to to have to say that Woman is less than Man or vice versa. Regards, Marc
Re: Enum instance for Ratio
George Russell ([EMAIL PROTECTED]) wrote: : A logical definition of Enum (to me wearing a mathematical hat) : would be : : succ x = min { y | y x} : Wouldn't that make Enum depend on Ord? Doesn't seem to make sense if classes are enumerable but not comparable. Regards, Marc
cvs built ghc creates segmentation fault generating binaries
Hello again, Just to let you know this problem exists. I have built ghc from cvs (didn't make any changes to the sources) and used it to compile one of my programs. When run it fails with a: Segmentation Fault This didn't happen before. Again I have resons for suspecting Integer arithmetic to be the cause of the problem. I'll try to locate the error and let you know of my findings. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
cvs: Profiling.c:462: parse error before `'
Hello again, When making cvs it halts because of a Profiling.c:462: parse error before `' I have appended a log. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] ===fptools== Recursively making `all' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb make[2]: Nothing to be done for `all'. ===fptools== Finished making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `all' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `all' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hp2ps make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hscpp make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/mkdependHS make INSTALLING=0 BIN_DIST=0
Re: Profiling.c:462: parse error before `'
Simon Marlow ([EMAIL PROTECTED]) wrote: [...] : It looks like you had a conflict when you cvs updated. Check Profiling.c : for the telltale ''. If you didn't make any changes to Profiling.c that : you want to keep (I suspect you just fixed yesterday's problem by hand, : hence the conflict), then just remove Profiling.c and cvs update to recover : the stock version. Thanks, that solved that problem. Now I get a:-( StixPrim.lhs:6: Could not find valid [boot] interface file `OrdList' Any suggestions? Log appended. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] ===fptools== Recursively making `all' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb make[2]: Nothing to be done for `all'. ===fptools== Finished making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `all' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `all' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hp2ps make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools
cvs: MachCode (undeclared functions)
Hi there, Make all fails due to the fact that some functions in nativeGen/MachCode are undeclared. Log appended. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] ===fptools== Recursively making `all' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb make[2]: Nothing to be done for `all'. ===fptools== Finished making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `all' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `all' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hp2ps make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hscpp make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/mkdependHS make INSTALLING=0 BIN_DIST=0
cvs: Profiling.c:462: strucuture has no member named `emitted'
Hi there, I just updated cvs and now make fails because of a Profiling.c:462: strucuture has no member named `emitted' thingy. Log appended. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] ===fptools== Recursively making `all' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb make[2]: Nothing to be done for `all'. ===fptools== Finished making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `all' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `all' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hp2ps make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hscpp make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/mkdependHS make
cvs: make boot fails: mkdependHS-inplace: can't open directory haxml/lib
Hello again, When carrying out a make boot with cvs this caused a problem because of the following: mkdependHS-inplace: can't open directory haxml/lib I have appended a log. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] ===fptools== Recursively making `boot' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make boot -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `boot' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir ../../glafp-utils/mkdependC/mkdependC -f .depend -- -- lndir.c ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb ../../glafp-utils/mkdependC/mkdependC -f .depend -- -- sgmlverb.c ===fptools== Finished making `boot' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make boot -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `boot' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `boot' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hp2ps ../../../glafp-utils/mkdependC/mkdependC -f .depend -- -O-- AreaBelow.c AuxFile.c Axes.c Curves.c Deviation.c Dimensions.c Error.c HpFile.c Key.c Main.c Marks.c PsFile.c Reorder.c Scale.c Shade.c TopTwenty.c TraceElement.c Utilities.c ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hscpp ==fptools== make boot - --no-print-directory -r
Re: make boot fails: mkdependHS-inplace: can't open directory hax ml/lib
Simon Marlow ([EMAIL PROTECTED]) wrote: : When carrying out a make boot with cvs this caused a problem : because of the following: : mkdependHS-inplace: can't open directory haxml/lib : : Maybe you need to 'cvs update -Pd'. The haxml directory just appeared : yesterday. Thanks. Mike Gunter also pointed me in this right direction. Regards, Marc -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
cvs 4.07 arithmetic errors in Integer arithmetic
Hi there, I am trying to fix some errors in the Integer arithmetic Simon Marlow and I spotted. I just reinstalled cvs from scratch yesterday and build ghc-4.07 from it. I then noticed that one of my programs resulted in completely different output than it did with ghc-4.06 (or even 4.07 from cvs a few weeks ago). I am pretty convinced that the ghc-4.06 output is correct and the 4.07 output is **very** wrong. I am pretty sure the differences are caused by changes in Integer arithmetic (again, I have not noticed these problems with 4.07 and cvs a few weeks ago, so the changes must have been recent.) If I were to guess the errors are caused by changes to quot or gcd. Unfortunately I have very limited time to spend on this. (I already spent more time on this than I had anticipated I would need.) Is there anybody who thinks that a *recent* change made by him could have led to the problems I noticed? I would appreciate suggestions from cvs hackers as to what is a good approach to locate the cause of the problem. Finally I would like to know if there is a way to get my hands on a cvs tree for 4.06 so that I can compare the two and see what happens when I apply a fix to 4.07 against applying the same fix for 4.06? Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
CVS: make all: [MatchPS.o] Segmentation Fault (core dumped)
Hello again, Just to let you know. When trying to make all from CVS I got the following: make[2]: *** [MatchPS.o] Segmentation Fault (core dumped) make[1]: *** [all] Error 1 make: *** [all] Error 1 I had this before. Re-making will solve the problem. Let me know if more information is required. Regards, Marc van Dongen
CVS make all failed: RegAllocInfo
Hello there, A make all from CVS failed because of the following: /usr/local/bin/ghc -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:nativeGen -recomp -c nativeGen/RegAllocInfo.lhs -o nativeGen/RegAllocInfo.o -osuf o RegAllocInfo.lhs:565: Variable not in scope: `g1' RegAllocInfo.lhs:565: Variable not in scope: `g2' RegAllocInfo.lhs:565: Variable not in scope: `f14' RegAllocInfo.lhs:565: Variable not in scope: `f15' RegAllocInfo.lhs:565: Variable not in scope: `f16' RegAllocInfo.lhs:565: Variable not in scope: `f18' Compilation had errors make[2]: *** [nativeGen/RegAllocInfo.o] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 I built the same from cvs yesterday. After updating today this failed. Any suggestions on how to fix this will be greatly appreciated. Thanks in advance. Marc van Dongen *** log *** ===fptools== Recursively making `all' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb make[2]: Nothing to be done for `all'. ===fptools== Finished making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `all' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `all' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc
Segmentation Fault (After installing 2.95.2)
Hi there, I have just instaled gcc version 2.95.2 and recompiled one of my programs. When running it, it immediately halts, but not befor it has uttered the famous words: Segmentation Fault (core dumped) Any suggestions as to how to solve this fix this? (Other C programs compiled with 2.95.2 sem to run fine.) Regards, Marc van Dongen ___ Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
make depend
Hi There, When I noticed that my mkdependHS didn't work any more I noticed that the release notes for ghc-4.04 mentioned that this program had become obsolete and that ghc-4.04 -M should be used instead. The problem I have with ghc-4.04 -M is that is seems to be *very* reluctant to generate dependencies. Invoking ghc-4.04 as follows: ghc-4.04 -M for a Makefile containing the following lines SRCS = *.lhs *.hs .SUFFIXES : .o .hi .hs .lhs .o.hi: @: .lhs.o: $(HC) -c $ .hs.o: $(HC) -c $ (and more) in a directory containing *lots* of source files does absolutely nothing. The last two lines in the resulting Makefile are # DO NOT DELETE: Beginning of Haskell dependencies # DO NOT DELETE: End of Haskell dependencies The result of invoking ghc-4.04 -M does indeed update the Makefile (I checked this using an ls -l). I cannot find any documnetation about the -M option so I don't know if I am doing something wrong.s Am I doing something wrong or is this a bug? Any help would be greatly appreciated. Yours desperately, Marc
Re: make depend
: Hi, Hi! Thanks for writing. : Did you try just `ghc-4.04 -M'? If so, you must add .hs file names after : the command. I did. : $ ghc-4.04 -M your.hs haskell.hs source.hs programs.hs That doesn't seem to do very much either. : You can find dependencies among `.hs' files in the Makefile. I think I'll wait until I am refered to some form of documentation. Thanks again, Marc van Dongen
Re: make depend
Sigbjorn: : : Did you try just `ghc-4.04 -M'? If so, you must add .hs : file names after : : the command. : : I did. : : : $ ghc-4.04 -M your.hs haskell.hs source.hs programs.hs : : That doesn't seem to do very much either. : : : You can find dependencies among `.hs' files in the Makefile. : : I think I'll wait until I am refered to some form : of documentation. : : : Kwanghoon Choi's comments is really all there's to it, but see : top of Section 8.1 in the user's guide for more. That's interesting. I hadn't noticed that section. I looked at Section 2 (Using GHC/command line options) which doesn't make any reference to the -M flag. I'll try again. Thanks. Regards, Marc van Dongen
Re: ghc from CVS (1999/07/31) throws core...
: Hi! : : I tried to recompile the latest ghc (1999/07/31) on a Linux/glibc2.1.1 : system (egcs 2.91.66), but there seems to be a problem: the build works, but : the resulting compiler produces executables, that throw core, even with : "main = return ()". I've noticed that as well. Code like does not produce proper error messages anymore which it did with ghc-4.02. One wonders where the performance boost came from:-) $ cat tmp.lhs module Main( main ) where main = putStr $ show q where q = quot 1 0 $ ghc-4.02 tmp.lhs ghc-4.02: module version changed to 176; reason: usages changed 1006 swift ~/ghc/constraints/mixed $ a.out Fail: Prelude.Integral.quot{Integer}: divide by 0 1007 swift ~/ghc/constraints/mixed $ ghc-4.04 tmp.lhs ghc-4.04: module version changed to 177; reason: usages changed 1008 swift ~/ghc/constraints/mixed $ a.out Arithmetic Exception (core dumped) Regards, Marc van Dongen
Internal Happy Error (another one)
Hi there, ghc-4.04's parser does not seem to like expressions of the following kind: case a of (#I a) - and blah (# sa, a, #) Upon using these expressions it dies due to an internal Happy error. Hope this helps, Marc van Dongen
Internal Happy Error
Hi there, The following ``code'' forces ghc-4.04 to crash with an internal Happy error message: module Rules where import GlaExts import PrelGHC integerGcd :: Integer - Integer - Integer integerGcd a b = case a of (S# a) - case b of (S# b) - unsafePerformIO $ _ccall_ gcdSSSZh (I# a) (1::Int) (I# b) = \g - case g of (I# g) - return (S# g) (J# sb b) - unsafePerformIO $ _casm_ gcdSBSZh a sb b = \g - case g of (I# g) - return (S# g) Hope that helps. Regards, Marc van Dongen
bug with trace
Hi there, The following program (ghc-4.02): f :: [Int] - Int f (i:is) | trace "0" False = error [] f is | trace "1" False = error [] f is = f $ tail is main = putStr $ show $ f [0] Outputs: 1 Fail: Prelude.tail: empty list wheras it should have output: 0 1 Fail: Prelude.tail: empty list Regards, Marc van Dongen
Re: Integer - Int conversion
Sigbjorn: : The question is what should 0x8000 :: Integer : become when its coerced into an int. : : GHC takes the lowest 32 bits. : Advantage: Equality above maxBound still "works" aka above. : Disadvantage: 0x + 1 == 0 ! : : Perhaps constant Int's larger than maxBound (or smaller : than minBound) should be a compile time error? : : : Int arithmetic is modulo maxBound (at least that's what : ghc and Hugs implements), so making the Integer-Int conversion : fall into line with that, has some merit. On my machine the following program: main = do putStr "According to ghc-4.02 (1-maxBound)^2 = " putStr $ show mult1 putStr "\nAccording to ghc-4.02 (maxBound-1)^2 = " putStr $ show mult2 where mult1, mult2 :: Int mult1 = (1-maxBound)*(1-maxBound) mult2 = (maxBound-1)*(maxBound-1) outputs: According to ghc-4.02 (1-maxBound)^2 = 4 According to ghc-4.02 (maxBound-1)^2 = 4 Mod maxBound the result of both multiplication should have been 1. Maybe it is better to rely on Integers. Regards, Marc van Dongen
Proposal for error message improvement
Dear implementors, Consider the following silly module definition: module Proposal( C ) where class C p a where ci :: p a - p a f :: (C p a) = f (p a) - f (p a) f a = case ci a of [] - a Compiling this leads to the following (ghc-4.02): Proposal.lhs:6: Inferred type is less polymorphic than expected Quantified type variable `f' is unified with `[]' When checking the type signature f :: forall f1 p1 a1. {C p1 a1} = f1 (p1 a1) - f1 (p1 a1) Here it is not difficult to see what causes the problem. However, the more equations there are in the definition of a function, the more difficult I have found it to locate the cause of errors resulting in error messages as the one above. Would it be possible to provide an explanation as to what could have caused such errors? Regards, Marc van Dongen
Re^2: Extra output lines from trace.
Hi there, This is related to at least two earlier messages in this forum which sadly enough I only noticed today. It probably is a feature that since then trace doesn't print Trace on/Trace off anymore. Is there any reason for not doing this anymore? In my opinion it makes tracing very awkward. People who don't want Trace on/off could always redirect stderr to stdout and use a grep -v Trace. Maybe adding a traceOnOff function? Regards, Marc
kind mismatch ($)
Hi there, When I compile the module below with ghc-4.01 and -fglasgow-exts, I get the following error message: YouCantDoThat.lhs:8: Kind mis-match between `_a :: *' and `Int# :: *#' Expected type: _a - Int' Inferred type: Int# - Int' In the first argument of `$', namely `Int'' In the right-hand side of an equation for `disallowed': Int' $ (a +# a) The function @allowed@ seems perfectly ok. module YouCantDoThat( disallowed, allowed ) where import GlaExts data Int' = Int' Int# disallowed :: Int# - Int' disallowed a = Int' $ a +# a allowed :: Int# - Int' allowed a = Int' (a +# a) One additional comment. I frequently use quotes (') as suffixes for identifier and type names. As can be seen above ghc loves adding quotes (` and ') around parts of its messages. This becomes *very* confusing when the last part of the message consists of an identifier suffixed by a one or more quote symbols. Regards, Marc van Dongen
Pattern match(es) overlapped (again)
Hi there, This is ghc-4.01 I have not seen an instance of such a message for non-overlapping patterns for non-string types. As part of a where clause I have (modulo renaming) two equations of the following form: f Pat1 p2 p3 p4 = rhs1 f Pat2 p2 p3 p4 = rhs2 where Pat1 and Pat2 are disjoint ``ground'' instances of a user defined algebraic data type as in data Pattern = Pat1 | Pat1 I get nevertheless (modulo renaming) Pattern match(es) are overlapped in the definition of function `f' Pat2 p2 p3 p4 = ... I tried to isolate this but strangely enough the message is not generated in a module of the following type: module Overlap( overlap ) where data Pattern = A | B overlap A i j k = 0 overlap B i j k = 0 Let me know if you need more info. Regards, Marc
Overlapping Patterns (false alarm)
Hello again, Sorry about my previous ``report'' on overlapping patterns. I overlooked the fact that the first ``ground'' instance appearing in the function definition was, in fact, a variable. GHC really works! Regards, Marc
`__ap_9_upd_info' undeclared
Hi there, Just at the end of the stage of creating an object file I got this message after which compilation was aborted. I have trimmed the verbose output (modulo pretty-printing) of ghc-4.01 to what I have appended at the end of this message. No Filnam.o was created. It seems to me something went wrong. If you need more info to know what is going on, please let me know and I may give it a shot to isolate the problem. Regards, Marc van Dongen ** ghc-4.00 -c Filnam.lhs -recomp -v -fglasgow-exts -cpp -hi-diffs -syslib misc -fvia-C -fno-update-analysis -optC-fallow-overlapping-instances [snip] /tmp/ghc8501.hc:664: `__ap_9_upd_info' undeclared (first use this function) /tmp/ghc8501.hc:664: (Each undeclared identifier is reported only once /tmp/ghc8501.hc:664: for each function it appears in.) real9.9 user9.7 sys 0.1 deleting... /tmp/ghc8501.lpp /tmp/ghc8501.cpp /tmp/ghc8501.hi /tmp/ghc8501.hc /tmp/ghc8501_stb.c /tmp/ghc8501_stb.h ghc8501.c ghc8501.s /tmp/ghc8501_o.s rm -f /tmp/ghc8501* make: *** [Filnam.o] Error 1
bug report 4.00
Hi there, While compiling some stuff with 4.00 I get the following output before compilation stops. [snip] GNU CPP version 2.7.2 (sparc) #include "..." search starts here: #include ... search starts here: . /usr/local/ghc-4.00/lib/ghc-4.00/includes /usr/local/ghc-4.00/lib/ghc-4.00/includes /usr/local/include /usr/local/sparc-sun-solaris2.5/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2/include /usr/include End of search list. /usr/local/ghc-4.00/lib/ghc-4.00/includes/ClosureMacros.h:140: unterminated character constant /usr/local/ghc-4.00/lib/ghc-4.00/includes/StgMacros.h:87: unterminated string or character constant real0.3 user0.2 sys 0.0 deleting... /tmp/ghc6070.cpp /tmp/ghc6070.hi /tmp/ghc6070.hc /tmp/ghc6070_stb.c /tmp/ghc6070_stb.h ghc6070.c ghc6070.s /tmp/ghc6070_o.s rm -f /tmp/ghc6070* make: *** [Result.o] Error 1 Needless to say I haven't changed ClosereMacros.h or StgMacros.h Any suggestions how to fix this? Regards, Marc
stranal/SaAbsInt.lhs:668: Non-exhaustive patterns in function `absApply'
Hi there, module F( f ) where class C a b where f :: a - b - b instance C Bool b where f a b = if a then b else b instance C (IO Bool) (IO b) where f a b = a = \bool - f bool b Leads to a ghc-3.02 crash: stranal/SaAbsInt.lhs:668: Non-exhaustive patterns in function `absApply' Hope this helps. Regards, Marc
tcLookupGlobalValue
Hi there, I would like to report the following. After splitting up one module in two seperate modules in two different files, I ended up with something as follows: swift more A.lhs module A( a ) where a = 1 swift more B.lhs module A( b ) where import A( a ) b = a + a The compilation session (modulo empty lines) went as follows: swift ghc-3.02 -c A.lhs ghc-3.02: module version changed to 1; reason: no old .hi file swift ghc-3.02 -c B.lhs importDecl wierdness: A.a{-r6J-} importDecl wierdness: A.a{-r6J-} panic! (the `impossible' happened): tcLookupGlobalValue: A.a{-r6J-} Please report it as a compiler bug to [EMAIL PROTECTED] Hope this helps. Regards, Marc [Add SPAM to my e-mail address if you don't want to send me mail.]
quotes deleted in error messages
Hello there, While compiling some source code of mine, containing the following lines (line numbers included): 321 322 minCycleLength :: Vertex - (MarcMap Vertex (MarcMap Vertex v)) - Maybe Int 323 minCycleLength v g 324 = mcl ws g'' 325 where ws = mapDom (rdMap g v) 326 g' = mapMap (\wrs - mapMap (\_ - Nothing) wrs) g 327 g'' = foldr (\w g' - wrMap (rdMap g' w) v (Just (w,1))) g' ws 328 mcl [] _ 329 = Nothing 330 Line 329 was the last line of the definition of minCycleLength (under construction). The following error message was returned by ghc-3.01 Search.lhs:327: Occurs check: cannot construct the infinite type: a1Lv = MarcMap a1Lt a1Lv Expected: MarcMap a1Lz (MarcMap a1Lz a1Lv) Inferred: MarcMap a1Lz a1Lv In the first argument of `MarcMap.rdMap', namely `g' In the first argument of `MarcMap.wrMap', namely `(MarcMap.rdMap g w)' It seems as if the quote symbol in the fragment (rdMap g' w) in line 327 has been omitted somehow. The two nearest occurences of the regular expression "rdMap[ ]+g[ ]+w" are more than 100 lines before and 30 lines after line 327. If needed, I can provide the source-code from which this was generated. Regards, Marc
Is this a bug?
Hi there, I suspect the program included below is incorrect. Nevertheless it compiles fine under ghc-3.01 patchlevel 0. module Main( main ) where import List( genericLength ) main = putStr (show integral) putStr "\n" return () where integral = genericLength [] The reason why I am having problems with this program is that I cannot infer whether integral should be an Int or an Integer. ghc-3.01 thinks integral is an Int (a big positive integral is sometimes shown as a negative number). Regards, Marc
Re: Is this a bug?
[snip] : module Main( main ) where : import List( genericLength ) : main = putStr (show integral) : putStr "\n" : return () :where integral = genericLength [] [snip] : This is a legal Haskell program. The (ambiguous) type of `integral' is : (Num a = a), but Haskell disambiguates numeric expressions with the : help of `default' declarations. As per Haskell 1.4 (see section 4.3.4 Thanks for the pointer. : of the report), this means resolving `integral' to be a value of type : Int. I think this ``resolving'' may lead to unwanted results. It took me quite some time to discover that Integral was resolved to Int in some program I had. Is there a possibility of generating a warning message whenever programs like the one above have to be disambiguated? Maybe a compiler-switch to turn these warning messages on and off? : ghc-3.01 thinks integral is an Int (a big : positive integral is sometimes shown as a : negative number). : : ghc's implementation of Ints doesn't do overflow checking, so this is Now there is something I did know. : not too surprising. Disambiguate your program either by using type : annotations telling the compiler that `integral' really is an Integer : or use a `default' declaration. Thanks again, Marc
Re: ghc-3.00-linux bug in linking
spj: : Sergey, Marc : : I've had a look at your Docon thing. It really is Sergey's thing. He deserves all the credit. [snip] Cheers, Marc
bug report
While compiling some stuff with 3.00 which normally compiles with 2.10, I came across the following: panic! (the `impossible' happened): ERROR: can't generate code for polymorphic case probably a mis-use of `seq' or `par'; the User's Guide has more details. Offending type: Residue.ResidueG{-rHG-} (Pol.Polynomial{-rHB-} $x0_ts1Kze $x1_ts1Kzd) - Group_.Subgroup{-rD3-} (Residue.ResidueG{-rHG-} (Pol.Polynomial{-rHB-} $x0_ts1Kze $x1_ts1Kzd)) PrelBase.Integer{-3g-} If more details are needed please call. Regards, Marc van dongen
happy bug
Hi there, I would like to report the following Happy bug. With rules of the form: This :: { Type } This: Is A Rule{ let a = 1 b = 2 in $1 } Happy generates .. (let a = 1 b = 2 .. Which isn't proper Haskell. Regards, Marc van Dongen
bug report
Hi there, When compiling with 2.0899, I get the following error at linking stage: Undefined first referenced symbol in file getBufferMode /usr/local/ghc-2.09/lib/libHS.a(IOHandle__131.o) Main_main_closure /usr/local/ghc-2.09/lib/libHS.a(GHCmain__7.o) I have not used the function getBufferMode in my source. I do have a hSetBuffering. Any suggestions how to get around this? Thanks in advance, Marc van Dongen
profiling
Hi there, I was wondering if somebody could help me with the following. I have *many* functions-names of the following form descriptor_prefix_TYPE_SUFFIX Many different functions have the same descriptor_prefix part. The TYPE_SUFFIX is meant to describe the type of the arguments of the different functions. When I profile my sources (-auto-all) it happens a lot that I see names of the following form SourceFile:ModuleName/descripto in stead of names of the form SourceFile:ModuleName/descriptor_prefix_TYPE_SUFFIX as I would have expected. Is there a way to get the full function-names out of the profiling package? I have looked at the .hp files, but the information does not seem to be available at that level. Any help would be greatly appreciated. Regards, Marc van Dongen [EMAIL PROTECTED]
bug report
Hi there, ghc-2.0498, complains about list-comprehensions when compiling the following. There's probably some code-transformation going on here. module Strange( strange ) where strange :: (a,a,a) - a strange triple | (first triple) == (fst triple) = first triple first :: (a,b,c) - a first (a,b,c) = a Stange.lhs:5: Couldn't match the type `PrelTup.(,,) tazz' against `PrelTup.(,)' Expected: `(tazz, tazz, tazz)' Inferred: `(tazz, tazN)' In a list-comprehension qualifer: `(first triple) PrelBase.== (PrelTup.fst triple)' Hope this helps, Marc van Dongen [EMAIL PROTECTED]
bug report
Hi there, With ghc-2.04 I can successfully compile the following: module Buggy( buggy ) where data L a = L [a] class (Eq a,Ord a,Num a,Read a,Show a) = Class a where method :: a - Bool instance (Class a) = Class (L a) where method (L as) = True instance (Class a) = Eq (L a) where (==) e1 e2 = True instance (Class a) = Ord (L a) where compare a b = EQ instance (Class a) = Num (L a) where negate p = p instance (Class a) = Show (L a) where showsPrec _ _ c = c instance (Class a) = Read (L a) where readsPrec _ _ = [(L [],[])] buggy :: (Class a) = (L a) - (L a) buggy omega = g omega 1 g :: (Class a) = (L a) - a - (L a) g omega one = omega I had expected an overloading error because of the use of ``1'' in the definition for ``buggy''. Hope this helps. Regards, Marc van Dongen
bugg report (profiling again)
The latest patch provided Thu 16 Jul I still have problems with profiling and optimization: at the link-stage. (See also my report from Thu, 26 Jun). After: ghc -o ModuleMain -H40M -K4M -recomp -v \ -fglasgow-exts -cpp -hi-diffs -ansi -syslib ghc \ -fshow-import-specs -O2 -fvia-C -O2-for-C -prof -auto \ [object files snipped] I get the following error: Undefined first referenced symbol in file CC_mkZubalancedZ92Z92Z92Zq_struct Module1.o CC_DICTs_struct Module2.o CC_mkZubalancedZ92Zq_struct Module3.o CC_nubZ92Zq_struct Module4.o ld: fatal: Symbol referencing errors. No output written to ModuleMain Compiling without profiling and -O2 or compiling with -O2 but without profiling produces no errors. Regards, Marc van Dongen
bug report
I would like to report the following bug in ghc-2.04. Profiling and optimizing with -O2 (I have not and will not try -O) leads to errors like this at link-time: CC_mkZubalancedZ92Z92Z92Zq_struct Blah1.o CC_DICTs_struct Blah2.o CC_mkZubalancedZ92Zq_struct Blah3.o CC_DICTsBlah2.o CC_nubZ92Zq_struct Blah4.o ld: fatal: Symbol referencing errors. No output written to Blah Hope this helps. Regards, Marc
profiling
Hi all, I have noticed that profiling in ghc-2.03 in combination with -O or -O2 is not possible because of some problems at the linking stage. Also it turns out that profiling combined with tracing results in programs which don't output any trace at all. Are the problems related to profiling an optimization resolved in ghc-2.04? I have programs which havilly depend of optimization. Without it, I have to say nasty things like +RTS -H100M -K1M -hC -RTS. Whereas normally a heap of 16M suffices. I have also noticed (no bug) that programs with bigger heaps need more stack. Is this due to garbage collection? Regards, Marc
-fshow-specialisations
This does not work in ghc-2.03. ghc-2.03: unrecognised option: -fshow-specialisations Hope this helps. Regards, Marc van Dongen
bug report
Hi, While I was constructing an example for ghc-users, I created the following program which crashed ghc-2.03. module Tmp( g ) where data AB p q = A | B p q g :: (Ord p,Ord q) = (AB p q) - Bool g (B _ _) = g A tmp.lhs:6: Warning: Possibly incomplete patterns in the definition of function `g' zonkIdOcc: g_aoQ panic! (the `impossible' happened): lookupBindC:no info! for: g_aoQ (probably: data dependencies broken by an optimisation pass) static binds for: Tmp.$d1{-rmM,x-} local binds for: Two seconds later, my system crashed. I assume ghc-2.03 did not cause this :-) Regards, Marc
tcLookupTyVar error (Similar as last one? Don't know.)
Sorry if this is caused by exactly the same as my last tcLookupTyVar report. Since I can't tell, I'll report it anyway. panic! (the `impossible' happened): tcLookupTyVar:a_r6F Please report it as a compiler bug to [EMAIL PROTECTED] If the instance definition for (*) at the end of this toy module is replaced by the definition that is commented, this all compiles fine. Strange, because the two implementations are equivalent modulo the theory {(*) = multiply}. Remove the `multiply :: a - a - a' part, and it compiles without problems. Hope this helps. Regards, Marc van Dongen module Rings( Group, Ring ) where import qualified Prelude( Ord(..), Eq(..), Num(..) ) import Prelude hiding( Ord(..), Eq(..), Num(..), MonadZero( zero ) ) class Group a where compare :: a - a - Prelude.Ordering fromInteger :: Integer - a (+) :: a - a - a (-) :: a - a - a zero :: a one :: a zero = fromInteger 0 one = fromInteger 1 -- class (Group a) = Ring a where -- (*) :: a - a - a -- (*) a b = -- case (compare a zero) of --EQ - zero --LT - zero - ((*) (zero - a) b) --GT - case compare a one of --EQ - b --_ - b + ((*) (a - one) b) class (Group a) = Ring a where (*) :: a - a - a (*) a b = multiply a b where multiply :: a - a - a multiply a b = case (compare a zero) of EQ - zero LT - zero - (multiply (zero - a) b) GT - case compare a one of EQ - b _ - b + (multiply (a - one) b)
bug report
If my memory serves me right, I haven't seen this one in ghc-2.03: *** Pattern-matching error within GHC! This is a compiler bug; please report it to [EMAIL PROTECTED] Fail: "typecheck/Unify.lhs", line 60: incomplete pattern(s) to match in function "unifyTauTyLists" Caused by the following faulty program: module F( f ) where f :: (Ord c) = c - c f c = g c g :: c - c g c = c where p = foldr (f c) [] [] Regards, Marc
Big heap for a small program
I just wanted to report that the erroneous and tiny program added below can not be compiled within 6MB of heap (Admitted it can be compiled with a bigger heap). It was part of a bigger program that could not be compiled within 20MB of heap. Regards, Marc van Dongen [EMAIL PROTECTED] ** ghc-2.02 -c tmp.lhs -H6M -K10M -recomp -v -fglasgow-exts -cpp -hi-diffs -ansi -syslib ghc The Glorious Glasgow Haskell Compilation System, version 2.02, patchlevel 0 literate pre-processor: echo '#line 1 "tmp.lhs"' /tmp/ghc6307.lpp /usr/local/lib/ghc-2.02/unlit tmp.lhs - /tmp/ghc6307.lpp real0.1 user0.0 sys 0.0 Haskellised C pre-processor: echo '#line 1 "tmp.lhs"' /tmp/ghc6307.cpp /usr/local/lib/ghc-2.02/hscpp -v -D__HASKELL1__=4 -D__GLASGOW_HASKELL__=202 -I. -I/usr/local/lib/ghc-2.02/includes -I/usr/local/lib/ghc-2.02/includes /tmp/ghc6307.lpp /tmp/ghc6307.cpp real0.0 user0.0 sys 0.0 hscpp:CPP invoked: /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2/cpp -traditional -D__HASKELL1__=4 -D__GLASGOW_HASKELL__=202 -I. -I/usr/local/lib/ghc-2.02/includes -I/usr/local/lib/ghc-2.02/includes /tmp/ghc6307.lpp Haskell compiler: /usr/local/lib/ghc-2.02/hsc ,-N ,-W ,/tmp/ghc6307.cpp -fglasgow-exts -hisuf-prelude=.hi -hisuf=.hi -fignore-interface-pragmas -fomit-interface-pragmas -fsimplify \( -ffloat-lets-exposing-whnf -ffloat-primops-ok -fcase-of-case -freuse-con -fpedantic-bottoms -fsimpl-uf-use-threshold0 -fessential-unfoldings-only -fmax-simplifier-iterations4 \) -himap=.:/usr/local/lib/ghc-2.02/hslibs/ghc/imports:/usr/local/lib/ghc-2.02/hslibs/ghc/imports:/usr/local/lib/ghc-2.02/imports -v -hifile=/tmp/ghc6307.hi -S=/tmp/ghc6307.s +RTS -H600 -K1000 Glasgow Haskell Compiler, version 2.02, for Haskell 1.3 GHC's heap exhausted; while trying to allocate 12 bytes in a 600-byte heap; use the `-Hsize' option to increase the total heap size. real 34.0 user 18.0 sys 0.1 deleting... /tmp/ghc6307.hi /tmp/ghc6307.s rm -f /tmp/ghc6307* make: *** [tmp.o] Error 1 ** module Too_Kuch( too_much ) where too_much :: [Int] - [(Int,Int)] - [(Int,[Int])] - Bool too_much ds ((k,m):q1) s0 = case (list1,list2) of [] - too_much ds q2m s2m where list1 = [k' | k' - ds, k == k'] list2 = [k' | k' - ds, m == k'] s1 = aas s0 k raM = [] raKM = listUnion (\a b - a) [] [] s1k = s1 q1k = raM s2k = s1 q2k = raM s2m = s1 q2m = raM s2km = foldr (flip aas) s1 raKM q2km = raKM listUnion :: (v - v - Bool) - [v] - [v] - [v] listUnion _ _ _ = [] aas :: (a,b) - a - (a,b) aas s _ = s