Re: compiler bug
On 1/24/07, D.A.Turner [EMAIL PROTECTED] wrote: Dear GHC people, I downloaded and installed the debian package fpr GHC-6 (on an AMD64 platform) and got the following error from ghci (below). Is this because you don't support 64bit platforms? Thanks for any info. GHC 6.2.2 is a very old version. Is there any reason why you can't download and install GHC 6.6? There should be a debian package for 6.6. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Ana Ng and I are getting old and we still haven't walked in the glow of each other's majestic presence / Listen Ana hear my words, they're the ones you would think I would say if there was a me for you -- TMBG ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Wildly inaccurate profiling results
I have a program, compiled with cost-center profiling on, that takes about 5 minutes, 30 seconds to run (measured with a stopwatch), but the resulting .prof file reports the total time as 34 seconds. I know that this number doesn't include overhead due to profiling, but surely the overhead can't be that much! (Also, the program runs about as long when run without -P.) I'm using a copy of GHC built from sources checked out around July 1. I'd include the program, but it's very large and I'm not sure how to minimize it and preserve the same behavior. Any ideas as to what the problem might be? Thanks, Kirsten -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Wildly inaccurate profiling results
On Tue, Oct 21, 2003 at 05:21:37PM +0100, Simon Marlow wrote: I think the profiler only measures CPU time, so if the program is waiting for I/O or sleeping a lot of the time, that won't be included in the profile. I don't think that's the issue -- when I run the program with debugging flags on that print out what it's doing, I can tell that it spends at most the first minute reading in files, and at most the last minute writing files (out of 5.5 minutes). Also, top shows that the program is using around 97% of the CPU for most of its run. Also, the overhead due to heap rofiling can sometimes be a lot, because it includes the time to scan the heap and collect the census data. Retainer profiling (+RTS -hr) is also especially expensive. You should see the profiling overheads drop considerably when not doing heap profiling, though. I'm not doing any heap profiling -- the only profiling flag I'm using is -P. When I recompiled the program without any profiling and ran it again, it took about 4 minutes as opposed to 5.5, suggesting that the 34 seconds reported by profiling really is inaccurate. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt I wish people weren't so set on being themselves, when that means being a bastard. -- Robertson Davies http://www.cs.berkeley.edu/~krc/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Wildly inaccurate profiling results
I think I understand what's going on: GC time isn't counted as part of the time reported by profiling. This seems misleading to me, since if your program is spending 4 times as much time doing GC as doing actual work (such as mine is), you'd want to know about it... but I suppose you can always just get the GC stats with -t anyway. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt There is no such thing as a weird human being. It's just that some people require more understanding than others.--Tom Robbins http://www.cs.berkeley.edu/~krc/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Wildly inaccurate profiling results
[Sorry if this shows up twice -- I accidentally posted from the wrong address and left something out.] I have a program, compiled with cost-center profiling on, that takes about 5 minutes, 30 seconds to run (measured with a stopwatch), but the resulting .prof file reports the total time as 34 seconds. I know that this number doesn't include overhead due to profiling, but surely the overhead can't be that much! (Also, the program runs about as long when run without -P.) I'm using a copy of GHC built from sources checked out around July 1. Also, using top I've observed that the program takes up about 120MB of memory, and I have much more memory than that, so there's no swapping going on. I'd include the program, but it's very large and I'm not sure how to minimize it and preserve the same behavior. Any ideas as to what the problem might be? Thanks, Kirsten -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt I always feel I have to take a stand, and there's always someone on hand to hate me for standing there / I always feel I have to open my mouth, and every time I do, I offend someone somewhere...--Ani DiFranco http://www.cs.berkeley.edu/~krc/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-frules-off
Not exactly a bug, but -frules-off doesn't do exactly what I would expect -- it effectively disables specialization, whereas it would be useful (to me, anyway) for it to disable user-defined rules while still applying rules generated by the compiler, such as specialization rules. Since there's another option that disables specialization (I think), it would seem sensible for -frules-off to work that way. I have a fix that involves changing activeRule (in simplify/SimplMonad.lhs) back to the way it was before and changing lookupRule (in specialise/Rules.lhs) to check whether opt_RulesOff is true, and, if so, only return the matching rule if it's a SPEC rule, but undoubtedly there's a better way. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
loop reading in external Core
There seems to be a bug in the latest version of GHC involving renaming/typechecking external Core files (well, besides the last 3 bugs I posted about...): $ ghc -fext-core -fno-code Hello.hs /home/deforest/ghc6.1src/fptools/ghc/compiler/ghc-inplace -fext-core -fno-code Hello.hs $ ghc Hello.hcr /home/deforest/ghc6.1src/fptools/ghc/compiler/ghc-inplace Hello.hcr ghc-6.1: panic! (the `impossible' happened, GHC version 6.1): loop Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. $ cat Hello.hs cat Hello.hs module Hello where foo = putStrLn Hello world! $ cat Hello.hcr cat Hello.hcr %module Hello foo1 :: GHCziIOBase.IO GHCziBase.Z0T = SystemziIO.putStrLn (GHCziBase.unpackCStringzh (Hello world!::GHCziPrim.Addrzh)); Hello.foo :: GHCziIOBase.IO GHCziBase.Z0T = foo1; I get the loop message with every .hcr file I've tried (restricting it to ones that don't define a main function, due to the issue mentioned in my previous post). This is with a GHC built from sources downloaded from CVS today. If I try to narrow things down by adding various verbosity options, the error message gets printed right after the renamer stats get printed out; that's as much as I've been able to figure out. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core front end is completely broken
On Wed, Jul 09, 2003 at 12:08:50PM +0100, Simon Peyton-Jones wrote: Ah, yes. Fixed. | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Kirsten Chevalier | Sent: 09 July 2003 00:25 | To: [EMAIL PROTECTED] | Subject: External Core front end is completely broken | | Using the latest version of GHC downloaded from CVS, it's impossible to use | GHC to compile any .hcr files that it generates itself. The reason for this | is that, as per the CVS log for prelude/PrelNames.lhs, all Main modules now | contain a definition for $Main.main -- however, the External Core lexer | still requires module names to begin with an upper-case letter, resulting in | a parse error. Not quite -- the RTS still expected the main closure to be called zdMain_main_closure, but once I fixed that, everything works as expected. Patches are attached. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt Index: Prelude.h === RCS file: /cvs/fptools/ghc/rts/Prelude.h,v retrieving revision 1.23 diff -r1.23 Prelude.h 21c21 extern StgClosure zdMain_main_closure; --- extern StgClosure ZCMain_main_closure; 70c70 #define mainIO_closure(zdMain_main_closure) --- #define mainIO_closure(ZCMain_main_closure) Index: Main.c === RCS file: /cvs/fptools/ghc/rts/Main.c,v retrieving revision 1.38 diff -r1.38 Main.c 44c44 extern void __stginit_zdMain(void); --- extern void __stginit_ZCMain(void); 56c56 startupHaskell(argc,argv,__stginit_zdMain); --- startupHaskell(argc,argv,__stginit_ZCMain);
External Core front end is completely broken
Using the latest version of GHC downloaded from CVS, it's impossible to use GHC to compile any .hcr files that it generates itself. The reason for this is that, as per the CVS log for prelude/PrelNames.lhs, all Main modules now contain a definition for $Main.main -- however, the External Core lexer still requires module names to begin with an upper-case letter, resulting in a parse error. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Meaning of -fno-foldr-build-on?
Hi, I'm using GHC 5.05 and after compiling a program with -O1, -ddump-simpl-stats, -fno-foldr-build-on, got output like this: other stuff snipped 3 RuleFired 1 fold/build 1 map 1 unpack So, the fold/build rule is being applied even if you run GHC with -fno-foldr-build-on. I RTFSed, and it appears that the only place in GHC where the -ffoldr-build-on command-line option is looked at is in DsListComp.lhs. In the flag reference in the manual, the effect of -ffoldr-build-on is listed as Enable foldr-build optimisation (presumably suggesting that -fno-foldr-build-on disables the optimization). This seems misleading if the only thing that -ffoldr-build-on/-fno-foldr-build-on actually does is to control whether list comprehensions are desugared using foldr/build. It seems that either the documentation or GHC should be corrected. (It would be nice if there were a flag to disable *all* rewrite rules while still doing other optimizations -- this doesn't seem to exist either.) Sorry if this is something that's corrected in 6.0 - I haven't upgraded yet. Thanks, Kirsten -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Profiling + External Core = trouble
On Tue, Apr 01, 2003 at 04:37:35PM -0800, Kirsten Chevalier wrote:
In case anyone is wondering, this particular problem seems to be fixed after
doing a cvs update, but then, any External Core program that was compiled for
profiling would segfault. I was able to fix this by modifying the EnterFunCCS
function in rts/Profiling.c to change the line:
if (ccsfn-root-is_caf == CC_IS_CAF) {
to
if ((ccsfn-root != NULL) (ccsfn-root-is_caf == CC_IS_CAF)) {
I don't know whether that's the right solution, but it seems to work for me.
It turns out that the real problem was that the External Core renamer was
unconditionally filling in [] for the imports, which was screwing up
profiling bigtime. I fixed it, but I don't know whether y'all want my code...
(for some reason I feel like I'm talking to myself here.)
--
Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Profiling + External Core = trouble
I'm using the latest version of GHC and gcc 2.96 on a Linux machine, and I get the following weird behavior when trying to compile programs for profiling and generate external Core: $ ghc -fglasgow-exts -fno-code -fext-core -prof -auto-all hello.hs $ ghc -o hello -prof -auto-all hello.hcr /tmp/ghc24088.hc:6: `NULL' undeclared here (not in a function) /tmp/ghc24088.hc:6: initializer element is not constant /tmp/ghc24088.hc:6: (near initialization for `Main_CAFs_cc_ccs[0].prevStack') /tmp/ghc24088.hc:6: `NULL' undeclared here (not in a function) /tmp/ghc24088.hc:6: initializer element is not constant /tmp/ghc24088.hc:6: (near initialization for `Main_CAFs_cc_ccs[0].indexTable') /tmp/ghc24088.hc:15: `NULL' undeclared here (not in a function) /tmp/ghc24088.hc:15: initializer element is not constant /tmp/ghc24088.hc:15: (near initialization for `Main_main_closure.header.prof.hp\.rs') /tmp/ghc24088.hc:63: `NULL' undeclared here (not in a function) /tmp/ghc24088.hc:63: initializer element is not constant /tmp/ghc24088.hc:63: (near initialization for `Main_zdmain_closure.header.prof.\hp.rs') This happens no matter what program I try to compile, and it doesn't happen if I don't use -prof -auto-all. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
CVS server down?
I can't seem to connect to the cvs server: $ cvs up cvs [update aborted]: unrecognized auth response from glass.cse.ogi.edu: cvs: error in loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
External Core bug: Illegal data constructor name
If you compile the lambda nofib benchmark with -fext-core, GHC won't compile the resulting .hcr file: [EMAIL PROTECTED] lambda]$ ghc -fext-core Main.hs [EMAIL PROTECTED] lambda]$ ghc Main.hcr Illegal data constructor name `Main.StateMonad2' This is using GHC 5.05. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
External Core typechecker bug
The external core file resulting from compiling the circsim nofib benchmark won't compile with GHC 5.05 -- I get the following error message: tcLookup: `GHC.Base.:TEq' is not in scope When checking kinds in `GHC.Base.:TEq a' In the data type declaration for `Main.:TSignal' -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Profiling and ext-core
The latest version of GHC (downloaded from CVS today) doesn't seem to be able to compile external Core files for profiling. If I do: $ ghc -prof -auto-all -fext-core -fno-code hello.hs $ ghc -prof -auto-all hello.hcr I get the following error message: ghc-5.05: panic! (the `impossible' happened, GHC version 5.05): main/CodeOutput.lhs:109: Non-exhaustive patterns in function outputC Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Whereas if I compile the original .hs file with -prof -auto-all, it works fine. This happens for every example I've tried. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-odir and -fext-core
Hi, The -odir switch doesn't seem to work properly when used in conjunction with with -fext-core. If I say: $ ghc -fext-core -odir /tmp/foo foo.hs the file foo.hcr gets placed in the current directory, not in /tmp/foo as it should be. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Yet another External Core bug
On Fri, Jan 24, 2003 at 01:31:46PM -, Simon Peyton-Jones wrote: In short, it's really a bug, but not a particularly easy one to fix. Rumination required. But it probably only happens on a few programs, right? It happens on at least two of the nofib benchmarks, so it seems to be pretty significant. I didn't understand your explanation of the problem, so unfortunately I can't suggest any solution. Did the other Core bug I reported at the same time http://www.haskell.org/pipermail/glasgow-haskell-bugs/2003-January/002877.html ever get fixed? Thanks, Kirsten -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Core Lint bug
The attached program, chr.hs, causes GHC to generate external Core that
results in a type error when compiled with -dcore-lint, but compiles normally
itself. That is:
$ ghc -fext-core -fno-code -fglasgow-exts chr.hs
$ ghc -dcore-lint chr.hcr
*** Core Lint Errors: in result of Simplifier phase 0, iteration 1 out of 4 ***
No locn: In the expression: GHC.Prim.leWord#
(GHC.Prim.int2Word# i#) 1114111
Argument value doesn't match argument type:
Fun type: GHC.Prim.Word# - GHC.Base.Bool
Arg type: GHC.Prim.Int#
error message trimmed
Compilation had errors
$ ghc -fglasgow-exts chr.hs
$
The code for mychr is just chr, from the Prelude. The typechecker seems
to think that 1114111 is an Int#, even though in the Core code, it's annotated
as being a Word#. (I'm using GHC 5.04.1 under RedHat Linux 7.3.)
--
Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt
import GHC.Exts
main = putStr (show (mychr 42))
{-# NOINLINE mychr #-}
mychr :: Int - Char
mychr (I# i#) | int2Word# i# `leWord#` int2Word# 0x10# = C# (chr# i#)
| otherwise = error Prelude.chr: bad
argument
Re: External Core typechecker
On Tue, Oct 01, 2002 at 08:48:00AM +0100, Simon Peyton-Jones wrote: That's true. Its architecture is rather different to the rest of GHC's type checker, and I'd been thinking that the obvious thing to do would be to use the same monad and style as the main type checker. For example, the utils/ext-core one reports only one error, and doesn't track line numbers. Still, it has the merit of existing! Presumably you can always use it stand-alone to check your core progs? Not right now, though, because it doesn't handle code produced by GHC 5, since some of the primitive module names are different. (That would probably be easy to change, I just haven't done it.) I'm not sure what the best approach is. Perhaps writing a new typechecker in the style of the GHC typechecker, but using the Core typechecker as a guide to what the type rules actually are, would be best. I'll think about it more after I get back from ICFP. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
On Mon, Sep 30, 2002 at 11:09:23AM +0100, Simon Peyton-Jones wrote: Yes please! Lint was never intended to be a 100% type checker, more of a compiler debugging tool. The reason I'm using it for Ext Core is that it exists, and writing the type checker for Ext Core would take another morning. But in the end it's the Right Thing to do. Volunteers? There is a typechecker for Ext Core already, in fptools/ghc/utils/ext-core. It would probably take some work to adapt it to be used with GHC, and to change it so it doesn't have the module names and primitives from GHC 4.08 wired into it, but would adapting it be the right thing to do? If so, I might have time to do it sometime. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
On Fri, Sep 27, 2002 at 04:12:11PM +0100, Simon Peyton-Jones wrote: I allege that I have fixed this. You now get type checking of external core without saying -dcore-lint. Dude, now I have to rebuild GHC *again*? Even with -dcore-lint, though, the compiler still seems to panic on certain ill-typed Core programs (this is using GHC 5.04.1 installed from rpms); one of these days I'll find a minimal test case and submit a bug report. Kirsten, would you care to say how you are using External Core? I'm using it to test a program transformation I'm implementing (type-inference- based deforestation) without linking into or hacking GHC (since I got quite enough of that before the External Core feature existed). Since I'm still debugging my transformation, it sometimes produces ill-typed programs, which is how I've encountered all these bugs. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
External Core typechecker
GHC doesn't seem to do much typechecking on external Core files; it happily compiles .hcr files with type errors that then segfault when you run the program. An example of such a program is attached (the type error is on line 19, where cons is applied to the Integer type and two integer lists). I'm using the latest version of GHC (built from CVS sources yesterday, using GHC 5.04 to bootstrap), on a RedHat Linux box with gcc 2.96. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
External Core typechecker
[ oops, forgot to include the attachment in the last message; it's also
copied here as text ]
%module Main
%rec
{main1 :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
%let %rec
{x :: GHCziNum.Integer = lit;
x1 :: GHCziNum.Integer = x}
%in %let %rec
{y :: GHCziBase.ZMZN GHCziNum.Integer =
GHCziBase.zdwZC @ GHCziNum.Integer lit1
(GHCziBase.zdwZC @ GHCziNum.Integer lit2
(GHCziBase.zdwZC @ GHCziNum.Integer lit3
(GHCziBase.zdwZMZN @ GHCziNum.Integer)));
y1 :: GHCziBase.ZMZN GHCziNum.Integer = y}
%in SystemziIO.putStrLn
(show (GHCziBase.ZC @ GHCziNum.Integer y1 y1));
main :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
main1;
lit :: GHCziNum.Integer =
fromInteger (GHCziNum.zdwSzh (5::GHCziPrim.Intzh));
fromInteger :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
GHCziNum.fromInteger @ GHCziNum.Integer zddNum;
lit1 :: GHCziNum.Integer =
fromInteger1 (GHCziNum.zdwSzh (1::GHCziPrim.Intzh));
fromInteger1 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit2 :: GHCziNum.Integer =
fromInteger2 (GHCziNum.zdwSzh (2::GHCziPrim.Intzh));
fromInteger2 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit3 :: GHCziNum.Integer =
fromInteger3 (GHCziNum.zdwSzh (3::GHCziPrim.Intzh));
fromInteger3 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
show :: GHCziPrim.ZLzmzgZR
(GHCziBase.ZMZN GHCziNum.Integer)
(GHCziBase.ZMZN GHCziBase.Char) =
GHCziShow.show @ (GHCziBase.ZMZN GHCziNum.Integer) zddShow;
zddShow :: GHCziShow.ZCTShow (GHCziBase.ZMZN GHCziNum.Integer) =
GHCziShow.zdfShowZMZN @ GHCziNum.Integer zddShow1;
zddShow1 :: GHCziShow.ZCTShow GHCziNum.Integer =
GHCziNum.zdp2Num @ GHCziNum.Integer zddNum;
zddNum :: GHCziNum.ZCTNum GHCziNum.Integer =
GHCziNum.zdfNumInteger;
Main.zdmain :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
GHCziTopHandler.runIO @ GHCziBase.Z0T main};
--
Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt
%module Main
%rec
{main1 :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
%let %rec
{x :: GHCziNum.Integer = lit;
x1 :: GHCziNum.Integer = x}
%in %let %rec
{y :: GHCziBase.ZMZN GHCziNum.Integer =
GHCziBase.zdwZC @ GHCziNum.Integer lit1
(GHCziBase.zdwZC @ GHCziNum.Integer lit2
(GHCziBase.zdwZC @ GHCziNum.Integer lit3
(GHCziBase.zdwZMZN @ GHCziNum.Integer)));
y1 :: GHCziBase.ZMZN GHCziNum.Integer = y}
%in SystemziIO.putStrLn
(show (GHCziBase.ZC @ GHCziNum.Integer y1 y1));
main :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
main1;
lit :: GHCziNum.Integer =
fromInteger (GHCziNum.zdwSzh (5::GHCziPrim.Intzh));
fromInteger :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
GHCziNum.fromInteger @ GHCziNum.Integer zddNum;
lit1 :: GHCziNum.Integer =
fromInteger1 (GHCziNum.zdwSzh (1::GHCziPrim.Intzh));
fromInteger1 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit2 :: GHCziNum.Integer =
fromInteger2 (GHCziNum.zdwSzh (2::GHCziPrim.Intzh));
fromInteger2 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit3 :: GHCziNum.Integer =
fromInteger3 (GHCziNum.zdwSzh (3::GHCziPrim.Intzh));
fromInteger3 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
show :: GHCziPrim.ZLzmzgZR
(GHCziBase.ZMZN GHCziNum.Integer)
(GHCziBase.ZMZN GHCziBase.Char) =
GHCziShow.show @ (GHCziBase.ZMZN GHCziNum.Integer) zddShow;
zddShow :: GHCziShow.ZCTShow (GHCziBase.ZMZN GHCziNum.Integer) =
GHCziShow.zdfShowZMZN @ GHCziNum.Integer zddShow1;
zddShow1
Re: External Core typechecker
On Thu, Sep 05, 2002 at 12:20:27PM -0700, Sigbjorn Finne wrote: To enable type checking of Core, compile with -dcore-lint Ah, thanks. You'd think it would do that by default when starting from an external Core file (hint :-)) -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Problem building GHC
Hi, I'm trying to compile the latest version of GHC (snarfed from CVS today), and I got the following errors: ../../ghc/compiler/ghc-inplace -ldl -fglasgow-exts -cpp -Iinclude -funbox-strict-fields -package-name base -O -Rghc-timing -spli\t-objs-c GHC/IOBase.lhs -o GHC/IOBase.o /tmp/ghc11830.hc:14233: `GHCziIOBase_ReadBuffer_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14233: initializer element is not constant /tmp/ghc11830.hc:14233: (near initialization for `GHCziIOBase_BufferState_closure_tbl[0]') /tmp/ghc11830.hc:14235: `GHCziIOBase_WriteBuffer_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14235: initializer element is not constant /tmp/ghc11830.hc:14235: (near initialization for `GHCziIOBase_BufferState_closure_tbl[1]') /tmp/ghc11830.hc:14308: `GHCziIOBase_ClosedHandle_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14308: initializer element is not constant /tmp/ghc11830.hc:14308: (near initialization for `GHCziIOBase_HandleType_closure_tbl[0]') /tmp/ghc11830.hc:14309: `GHCziIOBase_SemiClosedHandle_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14309: initializer element is not constant /tmp/ghc11830.hc:14309: (near initialization for `GHCziIOBase_HandleType_closure_tbl[1]') /tmp/ghc11830.hc:14310: `GHCziIOBase_ReadHandle_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14310: initializer element is not constant /tmp/ghc11830.hc:14310: (near initialization for `GHCziIOBase_HandleType_closure_tbl[2]') /tmp/ghc11830.hc:14311: `GHCziIOBase_WriteHandle_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14311: initializer element is not constant /tmp/ghc11830.hc:14311: (near initialization for `GHCziIOBase_HandleType_closure_tbl[3]') /tmp/ghc11830.hc:14312: `GHCziIOBase_AppendHandle_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14312: initializer element is not constant /tmp/ghc11830.hc:14312: (near initialization for `GHCziIOBase_HandleType_closure_tbl[4]') /tmp/ghc11830.hc:14314: `GHCziIOBase_ReadWriteHandle_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14314: initializer element is not constant /tmp/ghc11830.hc:14314: (near initialization for `GHCziIOBase_HandleType_closure_tbl[5]') /tmp/ghc11830.hc:14635: `GHCziIOBase_Overflow_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14635: initializer element is not constant /tmp/ghc11830.hc:14635: (near initialization for `GHCziIOBase_ArithException_closure_tbl[0]') /tmp/ghc11830.hc:14636: `GHCziIOBase_Underflow_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14636: initializer element is not constant /tmp/ghc11830.hc:14636: (near initialization for `GHCziIOBase_ArithException_closure_tbl[1]') /tmp/ghc11830.hc:14637: `GHCziIOBase_LossOfPrecision_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14637: initializer element is not constant /tmp/ghc11830.hc:14637: (near initialization for `GHCziIOBase_ArithException_closure_tbl[2]') /tmp/ghc11830.hc:14638: `GHCziIOBase_DivideByZZero_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14638: initializer element is not constant /tmp/ghc11830.hc:14638: (near initialization for `GHCziIOBase_ArithException_closure_tbl[3]') /tmp/ghc11830.hc:14640: `GHCziIOBase_Denormal_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14640: initializer element is not constant /tmp/ghc11830.hc:14640: (near initialization for `GHCziIOBase_ArithException_closure_tbl[4]') /tmp/ghc11830.hc:14669: `GHCziIOBase_ThreadKilled_closure' undeclared here (not in a function) /tmp/ghc11830.hc:14669: initializer element is not constant /tmp/ghc11830.hc:14669: (near initialization for `GHCziIOBase_AsyncException_closure_tbl[2]') ghc: 253552400 bytes, 548 GCs, 3497347/6298444 avg/max bytes residency (9 samples), 16M in use, 0.00 INIT (0.00 elapsed), 2.70 \MUT (7.13 elapsed), 1.85 GC (1.79 elapsed) :ghc gmake[2]: *** [GHC/IOBase.o] Error 1 gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory `/home/crete/lumberjacks3/krc/ghc/fptools-build/libraries' gmake: *** [all] Error 1 gcc -v gives -- gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-110) and uname -a gives Linux puma 2.4.18-3smp #1 SMP Thu Apr 18 07:27:31 EDT 2002 i686 unknown Thanks, Kirsten Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bug in CorePrep.lhs
Using more or less the latest version of GHC from CVS, I was getting error
messages from the assembler that complained about duplicate definitions of
closures for various data constructors. I changed lines 109-113 of
coreSyn/CorePrep.lhs as follows:
binds_out = initUs_ us (
corePrepTopBinds (md_binds mod_details) `thenUs` \
floats1 - {-
corePrepTopBinds implicit_binds `thenUs` \ floats2 -
-}
returnUs (deFloatTop (floats1 {- `appOL` floats2 -}))
)
and that seems to fix it. I don't know whether this breaks anything else,
but there's definitely a bug.
--
Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in CorePrep.lhs
On Fri, May 24, 2002 at 03:33:45AM -0700, Simon Peyton-Jones wrote: Strange. You fix definitely isn't the Right Thing, but there's clearly something wrong going on. Can you give more details please? I.e. give source code and what commands you executed to show up the bug? I should have been more specific... the bug doesn't manifest itself when I compile a Haskell file directly, but does if I compile it to Core and then compile the .hcr file. For example: $ ghc -fext-core -fno-code hello.hs $ ghc hello.hcr /tmp/ghc21711.s: Assembler messages: /tmp/ghc21711.s:1332: Error: Symbol Main_Foo_closure already defined. /tmp/ghc21711.s:1339: Error: Symbol Main_Foo_info already defined. /tmp/ghc21711.s:1341: Error: Symbol Main_Foo_entry already defined. /tmp/ghc21711.s:1351: Error: Symbol Main_Foo_fast1 already defined. /tmp/ghc21711.s:1402: Error: Symbol Main_Bazz_closure already defined. /tmp/ghc21711.s:1409: Error: Symbol Main_Bazz_info already defined. /tmp/ghc21711.s:1411: Error: Symbol Main_Bazz_entry already defined. /tmp/ghc21711.s:1421: Error: Symbol Main_Bazz_fast1 already defined. where hello.hs is: main = putStr $ Hello world! ++ (show (foo 2)) ++ (show (foo 0)) data Bar = Foo String | Baz Int deriving Show foo x = if (x == 0) then Foo zero else Baz x -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-funfolding-use-threshold in GHC 5.03
I'm using a copy of GHC built from CVS sources on May 13, and I get a panic message when I use the -funfolding-use-threshold with any input file: $ ghc -funfolding-use-threshold= hello.hs ghc-5.03: panic! (the `impossible' happened, GHC version 5.03): Prelude.read: no parse Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bug in external Core front end (again)?
GHCziPrim.RealWorld) GHCziBase.Z0T) = GHCziTopHandler.runMain @ GHCziBase.Z0T main1; -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core front-end in GHC 5.03
On Wed, May 08, 2002 at 07:18:17AM -0700, Sigbjorn Finne wrote: Hi, I'm unable to reproduce this here (with a 2002-05-07 HEAD build.) Make sure no interface files from earlier GHC builds are in scope; the -dshow-passes output you give hints that this _might_ be the cause. I'm still having the same problem -- I tried the newest version of GHC from CVS (as of today), as well as the April 11 snapshot (ghc-5.03.20020410). I don't think that any older interface files are in scope -- at least, there are none in the same directory as the program being compiled. Any other ideas? Thanks, Kirsten (my original message is below) - Original Message - From: Kirsten Chevalier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 03, 2002 15:39 Subject: External Core front-end in GHC 5.03 Hi, I just downloaded and built the latest version of GHC from the CVS repository yesterday and tried to use it to compile an external Core file, which caused the compiler to crash: $ ghc -fext-core -fno-code hello.hs $ ghc hello.hcr Segmentation fault I know that the external Core feature is still a work in progress, but is there something I should be doing differently or is it totally broken? Here are the relevant details: $ uname -a Linux puma 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98) and the results of compiling with -v: $ ghc -v hello.hcr Glasgow Haskell Compiler, Version 5.03, for Haskell 98, compiled by GHC version 5.02.1 Using package config file: /home/crete/lumberjacks3/krc/ghc/fptools-build/ghc/driver/package.conf.inpla ce Packages package stuff snipped Hsc static flags: -static -fignore-interface-pragmas -fomit-interface-pragmas -fdo-lamb da-eta-expansion -flet-no-escape *** Checking old interface for hs = Just hello.hcr, hspp = Just hello.hcr: *** Renamer: Segmentation fault The program I'm trying to compile is just: main = putStr Hello world! Thanks, Kirsten -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
External Core front-end in GHC 5.03
Hi, I just downloaded and built the latest version of GHC from the CVS repository yesterday and tried to use it to compile an external Core file, which caused the compiler to crash: $ ghc -fext-core -fno-code hello.hs $ ghc hello.hcr Segmentation fault I know that the external Core feature is still a work in progress, but is there something I should be doing differently or is it totally broken? Here are the relevant details: $ uname -a Linux puma 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98) and the results of compiling with -v: $ ghc -v hello.hcr Glasgow Haskell Compiler, Version 5.03, for Haskell 98, compiled by GHC version 5.02.1 Using package config file: /home/crete/lumberjacks3/krc/ghc/fptools-build/ghc/driver/package.conf.inplace Packages package stuff snipped Hsc static flags: -static -fignore-interface-pragmas -fomit-interface-pragmas -fdo-lambda-eta-expansion -flet-no-escape *** Checking old interface for hs = Just hello.hcr, hspp = Just hello.hcr: *** Renamer: Segmentation fault The program I'm trying to compile is just: main = putStr Hello world! Thanks, Kirsten -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
