Eval Int
ghc-4 insists on declaring instance Eval Int before applying foldlStrict (+) 0 [1,2] :: Int Is this correct? For it was written somewhere in Haskell-1.4 report that almost everything is of Eval automatically. -- Sergey Mechveliani [EMAIL PROTECTED]
RE: GHC-4.00 unimplemented check
Jan Laitenberger [EMAIL PROTECTED] writes: We use a small Avl module in our compiler project. GHC 4.00 crashes with the error message "unimplemented check" when compiling with ghc -c -O -H45M Avl.hs - but ghc -c -H45M Avl.hsand ghc -c -O2 -H45M Avl.hs will compile without error messages. Why? There's a couple of heap checks that are unimplemented by the native code generator, hence the crash. For now, turn off the use of the native code generator and compile with -fvia-C instead. (which is what -O2 does.) --Sigbjorn
RE: Eval Int
[EMAIL PROTECTED] writes: something is wrong here: ghc-4 does not compile the above foldlStrict ..., and it compiles it when it is preceeded by instance Eval Int So it occures that ghc-4.00 does not drop Eval mentionning - ? Ah, the Eval is actually defined in the 4.00 Prelude sources, but it is devoid of meaning (and I don't see the value of it being defined still as long as Eval isn't silently being dropped from contexts by the compiler.) Just do as suggested, drop Eval from the context of foldlStrict, and you should be laughing. --Sigbjorn
GHC-4.00 assembler crash
Hi, Compiling our interpreter module causes the assembler to crash ghc -c -H45M Inter.hs returns: /usr/ccs/bin/as: "/tmp/ghc22153.s", line 572: error: statement syntax /usr/ccs/bin/as: "/tmp/ghc22153.s", line 572: error: statement syntax /usr/ccs/bin/as: "/tmp/ghc22153.s", line 590: error: statement syntax /usr/ccs/bin/as: "/tmp/ghc22153.s", line 590: error: statement syntax These lines look like: (I used -S to get the assembler file) .word 0rfunction Is this a valid assembler syntax?? If I delete "rfunction" the assembler accepts the program. But is it still correct then? Best Wishes, Jan ___ '---|-- | __, _ _ EMail: [EMAIL PROTECTED] | / | / |/ | WWWeb: http://www.uni-passau.de/~laitenbe/ |/\_/|_/ | |_/ /| Laitenberger --(-|-- \|
RE: Eval Int
[EMAIL PROTECTED] writes: ghc-4 insists on declaring instance Eval Int before applying foldlStrict (+) 0 [1,2] :: Int Is this correct? For it was written somewhere in Haskell-1.4 report that almost everything is of Eval automatically. The Eval class doesn't exist anymore - so, for ghc-4.00 (and Haskell 98), just drop the use of it in your source. --Sigbjorn
RE: Eval Int
something is wrong here: ghc-4 does not compile the above foldlStrict ..., and it compiles it when it is preceeded by instance Eval Int So it occures that ghc-4.00 does not drop Eval mentionning - ?
RE: GHC-4.00 assembler crash
Jan Laitenberger [mailto:[EMAIL PROTECTED]] writes:
Hi,
Compiling our interpreter module causes the assembler to crash
ghc -c -H45M Inter.hs
returns:
/usr/ccs/bin/as: "/tmp/ghc22153.s", line 572: error:
statement syntax
/usr/ccs/bin/as: "/tmp/ghc22153.s", line 572: error:
statement syntax
/usr/ccs/bin/as: "/tmp/ghc22153.s", line 590: error:
statement syntax
/usr/ccs/bin/as: "/tmp/ghc22153.s", line 590: error:
statement syntax
These lines look like: (I used -S to get the assembler file)
.word 0rfunction
Is this a valid assembler syntax?? If I delete "rfunction"
the assembler accepts the program. But is it still correct then?
To quote from somewhere deep within the Prelude:
instance Show (a - b) where
showsPrec _ _ = showString "function"
[meta-comment: could we just do away with this one? Beyond giving
rise to semi-entertaining bugs, it's of precious little practical use..]
Thanks for the report; fixed (one line patch attached.)
--Sigbjorn
begin 600 MachRegs.diff
M*BHJ(-O;7!I;5R+VYA=EV94=E;B]-86-H4F5GRYL:',),3DY."\P.2\R
M.2`Q-3HP,3HS.`DQ+C$V+C(N-@T*+2TM(-O;7!I;5R+VYA=EV94=E;B]-
M86-H4F5GRYL:',),3DY."\Q,"\R,"`P-SHS,3HR,`T**BHJ*BHJ*BHJ*BHJ
M*BHJ#0HJ*BH@.3,L.3D@*BHJ*@T*("`)($E7T%20TA?86QP:$HRUPF5P
M96YD(YO=AI;FM?0T*("`)+$E7T%20TA?:3,X-B@@)S`G(#H@)V0G(#H-
M"B`@"2Q)1E]!4D-(7W-P87)C*"P)R`Z("=R)R`Z+"DI*0T*(2`)VAO=R`H
MF%T:6]N86P@BDI#0H@(%QE;F1[8V]D97T-"B`@#0H@("4@+2`M("T@+2`M
M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@
M+2`M("T@+2`M("T@+0T*+2TM(#DS+#DY("TM+2T-"B`@"2!)1E]!4D-(7V%L
MAA*'LM')E5N9"!N;W1H:6YG+7T-"B`@"2Q)1E]!4D-(7VDS.#8H("P
M)R`Z("=D)R`Z#0H@(`DL249?05)#2%]S%R8R@G,"@.B`GB@.BPI*2D-
M"B$@"7-H;W=31]C("AR871I;VYA;"!R*2D-"B`@75N9'MC;V1E?0T*("`-
M"B`@)2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@
=+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M#0H=
`
end
ghc-4 panic
Dear ghc developers,
ghc-4 `panics' at the project which is built by ghc-3.02
successfully:
ftp.botik.ru:/pub/local/Mechveliani/docon/fordebug/n.zip
unzip n.zip;
set ghcROOT, doconEXPORT as it is said in install.txt;
cd docon/
make all
This has to make the project with -Onot. It yields
many modules compiled
...
/usr/ghc/4/bin/ghc -c source/pol/factor/Pfact_.hs -fglasgow-exts
-optC-fallow-overlapping-instances -optC-fallow-undecidable-instances
-fvia-C -K1500k -syslib misc -cpp -recomp -hi-diffs -iexport -Iexport
-odir export -fno-warn-overlapping-patterns -ohi export/Pfact_.hi
-H1k -Onot
zonkIdOcc: cPMul_a38V
panic! (the `impossible' happened):
lookupBindC:no info!
for: cPMul_a38V
(probably: data dependencies broken by an optimisation pass)
static binds for:
caS2
caS3
...
Pfact_.factorOverPrimeFinField_1_{-rlV,x-}
local binds for:
caTz
Please report it as a compiler bug to [EMAIL PROTECTED]
make: *** [source/pol/factor/Pfact_.o] Error 1
---
It breaks at the last function in the module Pfact_.hs.
ghc-3.02 makes this all
- only `instance Convertible a Int =...' has to be commented out of
ResEuc0_.hs (the language is slightly different).
Please, advise.
--
Sergey Mechveliani
[EMAIL PROTECTED]
option spelling check
The ghc-4 driver does not check the spelling of options. For example, -fallow-undecidooble-instances has the same affect as the empty string. Then, it takes some effort to find why ghc compiles things in one way and not in another. -- Sergey Mechveliani [EMAIL PROTECTED]
RE: option spelling check
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] writes: The ghc-4 driver does not check the spelling of options. For example, -fallow-undecidooble-instances has the same affect as the empty string. This is partially true - if you (have to) feed the options straight to the compiler (using -optC... ), no checks are performed. If you go via the driver, it will at least tell you that the option isn't recognised. --Sigbjorn
Re: relocate_TSO
Ralf Hinze wrote: [...] I would really love to see GHC 4.00 in action ;-). OK, you've asked for it: Here a picture of ghc-4.00 (CVS snapshot from Oct 18th, new-rts branch) bootstrapping itself... :-) /home/inst/glasgow/linux/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:reader:profiling:parser:nativeGen -recomp -Onot -H30m -fno-warn-incomplete-patterns -c rename/ParseIface.hs -o rename/ParseIface.o -osuf o GHC's heap exhausted; while trying to allocate 0 bytes in a 65536-byte heap; use the `-Hsize' option to increase the total heap size. make[2]: *** [rename/ParseIface.o] Error 1 The memory requirements have been drastically reduced by sophisticated engineering techniques, using only 0 bytes for large Haskell sources! More seriously, today's CVS snapshot misses the distrib directory, but simply copying an older one seems to work. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: bootstrapping ghc on AIX
Sigbjorn Finne (Intl Vendor) wrote:
Jan Kort [EMAIL PROTECTED] writes:
Thanks, I can get a lot further now, everything apart from
compiling the assembler files and linking the hsc works, but
that will have to wait till tommorow :)
Jan
Great, if you should get stuck while doing this, let us know,
and we'll try to help out.
--Sigbjorn
It looks like I'm either missing more code, or I'm on the wrong
track. I can't find the powerpc assembly code for "JMP_" (should
be in ghc/includes/TailCalls.h), "StgRun" (should be in
ghc/rts/StgCRun.c) and for "StgReturn" (should be in ghc/rts/StgRun.S).
I also tried to compile with USE_MINIINTERPRETER set to 1, but this
led to having to set INTERPRETER_ONLY to 1 as well,
otherwise Hugs_CONSTR_entry would be undefined. I asume that
"INTERPRETER_ONLY" means no compiler ?
In case I'm not missing code and I have to write it myself, if
I don't use native code generation, can I do:
#ifdef powerpc_TARGET_ARCH
StgThreadReturnCode
StgRun(StgFunPtr f) {
f();
return (StgThreadReturnCode)R1.i;
}
#endif
And for the "JMP_":
#if powerpc_TARGET_ARCH
#define JMP_(cont) \
{ \
goto (void *)(cont); \
}
#endif powerpc_TARGET_ARCH
I don't know what to do about StgReturn in ghc/rts/StgRun.S,
judging from the ifdef, the StgReturn is only valid for 386
architectures, so where is it defined on a sparc or an alpha ?
--
Jan Kort
Existentially quantified types and ``deriving Eq''
Hello! The following datatype declaration would, if possible, actually be very useful for an application I have in mind: module Test(V(..)) where import ST data V s = forall a . MkV (STRef s a) deriving Eq But when compiling it with Ghc-4.00 I get: == ecserver ~~ ghc -fglasgow-exts -c test.hs test.hs:5: Inferred type is less polymorphic than expected Quantified type variable `a' is unified with `a1' When checking an existential pattern that binds a1 :: STRef s a1 b1 :: STRef s1 a In an equation for function `==': == (MkV a1) (MkV b1) = (a1 PrelBase.== b1) In the definition for method `==' Compilation had errors == (Essentially the same happens in Hbc.) Do I have to understand this error message as signalling that the ``deriving'' mechanism may not yet be fully aware of existentially quantified constructors? (It should be prepared that the rule == (MkV a1) (MkV b1) = (a1 PrelBase.== b1) may not be applicable for typing reasons, i.e., before the program-side pattern ``== (MkV a1) (MkV b1)'' is matched, the typing pattern induced by it should be allowed to fail.) Or is this a design design that I just could not find any documentation for? Would other people also like to derive classes in such a way for existentially quantified datatypes? BTW, the sparc-sun-solaris binary is not at the end of its link in the Ghc download page. Best regards, Wolfram
