Re: Missing Folder in ghc?
Ashley Yakeley wrote: Lemmih wrote: Did you run 'sh darcs-all get'? Oh, that wasn't in the README. Thanks. The instructions for getting GHC by darcs are here: http://cvs.haskell.org/trac/ghc/wiki/GhcDarcs It looks like you expected to build GHC by grabbing the darcs repo and reading the README file - that isn't a route I anticipated :-) I'll make sure the README gets updated at some point. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: factorial: let's get ahead of jhc! :)
Hello Simon,
Friday, February 24, 2006, 7:18:30 PM, you wrote:
1) add for/if/while to the C-- statement types list (data CmmStmt)
SM Please don't extend the C-- data type - it's very small and simple
SM because that makes it easy to manipulate and reason about.
SM I don't see why you need to, either: you can already express for, if and
SM while in C-- using conditional branches. I don't think gcc cares
SM whether you write your code using labels and goto or while/for/if, it
SM generates the same code either way.
i tested gcc (3.4.2, included in ghc 6.4.1) and my tests show that gcc
unroll loops only when a loop variable modified directly. This loop
unrolls:
loop: ...
i=i-1;
if(i1) goto loop;
and this loop don't unrolls:
loop: ...
x=i-1;
i=x;
if(i1) goto loop;
but using of while/goto don't matters. i attached fac.c that shows
this - here only fac() and fac3() are unrolled
2) implement recognizer for such simple STG functions (leaf unboxed
procedures recognizer)
3) implement the translation itself
SM By all means try this. What you want is to compile recursive functions
SM like this:
SMf() {
SM x = arg1;
SM y = arg2;
SML:
SM ... body of f, with args mapped to x y,
SM and recursive calls jumping to L passing args in x y.
SM}
SM It's quite hard to do this as a C-- to C-- optimisation, at least
SM without implementing a lot of other optimisations that we don't already
SM have. I was hoping that gcc would do it for us, if we compile code like
SM this:
SMf() {
SML:
SM ... body of f ...
SM goto L;
SM}
SM but sadly it doesn't do the whole job. (see cmmLoopifyForC in
SM cmm/CmmOpt.hs, which I added today).
SM So you might try the hacky way of doing this transformation at a higher
SM level, when generating the C-- in the first place. Putting the args in
SM temporaries is the easy bit; generating different code for the recursive
SM call will be more tricky.
i just downloaded fresh sources. cmmLoopifyForC may be not what we
need. the whole idea of transformation is to move f() parameters to
local variables, and then update contents of these local variables and
perform `goto` on each recursive call. why cmmLoopifyForC is not good
for this? only because before processing by this function the code
should look like this:
f() {
x = arg1;
y = arg2;
L:
... body of f, with args mapped to x y,
x = newarg1;
y = newarg2
jump f();
}
what is just not proper code, especially if xy is local f()
variables. so to use this function we should start from generating
improper code and anyway we should change STG-C-- code generation
i think that the discussed optimization can be done in another way:
1) in function mkFunEntryCode add check that f() is a leaf unboxed
function
2) if it's true then replace call to bindArgsToStack with generation
of x=sp[0]; y=sp[4]; L: assignments and bind corresponding args to
xy (instead of binding them to sp[0]/sp[4])
3) in cgTailCall function check that it's a self-recursive call and
in this case generate sequence x=newarg1; y=newarg2; goto L instead
of jump f(). i think that this check will require adding info about
f() to the FCode monad. so, the whole story should look like this:
CgClosure.lhs:
- ; bindArgsToStack stk_args
+ ; if isLeafUnboxedFunction cl_info body
+ then do local_args - makeNewLocals (length stk_args) -- generate xy
locals
+ generateLoads local_args stk_args-- generate x=sp[0];
y=sp[4] assignments
+ lbl - generateNewLabel -- generate L:
+ bindStkArgstoLocals local_args stk_args -- bind arguments to
xy local variables
+ modifyFCodeState (Just cl_info) lbl -- put in FCode monad
state info about
+ -- now-processed leaf
function and label
+ -- marking start of
its self-recursive cycle
+ else do bindArgsToStack stk_args
+ modifyFCodeState Nothing undefined
CgTailCall.lhs:
- = do { fun_info - getCgIdInfo fun
+ = do { fun_info - getCgIdInfo fun
+; (optimized_fun, lbl) - getFromFCodeState--
optimized_fun/=Nothing only if we
+ -- process leaf
unboxed function
- else -- Normal case, fun is boxed
+ else if (Just fun == optimized_fun) then
+ do generateAssignments-- generate x=newarg1; y=newarg2
+ generateGoto lbl -- generate goto L
+ else -- Normal case, fun is boxed
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
fac.c
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Did you try to link the DLL statically (i.e. via import library) and
remove the call to shutdownHaskell() ?
It worked for me (I am using Visual Studio 7, though).
Cheers,
Cyril
___
I wrapped up some Haskell modules in a Win32 DLL.
Loading the DLL dynamically (with LoadLibrary) works fine. However,
whether I actually use the library or not, the program (an application
with MFC GUI) crashes upon termination.
To find the reason for the crash, I added a new function for unloading
the DLL using FreeLibrary. FreeLibrary works fine, however the program
crashes when it returns to the main event loop. Interestingly, when I
reload the library (FreeLibrary followed by LoadLibrary) the program
continues working. However, every reload cycle causes the virtual size
of the process to increase by about 300K and the fourth reload fails
with the error message getMBlock: VirtualAlloc failed with: 8 (appears
in a message window) accompanied by many repetitions of the message
Timer proc: wait failed -- error code: 6 (appears on stderr) and
followed by the message getMBlocks: misaligned block returned (again
in a message window). Then the programm crashes.
Development takes place on Windows XP Professional using MS Visual
Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side
to the Haskell heap. I build the DLL using the command
ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o
dllMain.c
dllMain.c looks as follows:
#include windows.h
#include Rts.h
extern void __stginit_EUzu3820zu85(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain(HANDLE hModule, DWORD reason, void* reserved) {
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need
to start it up. */
startupHaskell(1, args, __stginit_Foo);
return TRUE;
} else if (reason == DLL_PROCESS_DETACH) {
shutdownHaskell();
}
return TRUE;
}
I played around with hs_exit instead of shutdownHaskell, I moved
initialization and clean-up from DllMain to my library loader, nothing
helps. Even doing no clean-up whatsoever does not change the behaviour.
Any ideas?
Michael
--
Message: 2
Date: Wed, 01 Mar 2006 12:06:27 -0800
From: Ashley Yakeley [EMAIL PROTECTED]
Subject: Re: Missing Folder in ghc?
To: glasgow-haskell-users@haskell.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Simon Marlow wrote:
The configure script has mis-detected your GHC version somehow. Could
you look through the output of configure, and see what it says about
GHC?
Nothing special:
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
Canonicalised to: i386-unknown-linux
checking for path to top of build tree...
/home/ashley/Projects/Collected/Haskell/ghc
checking for ghc... /usr/bin/ghc
checking version of ghc... 6.4
checking for nhc... no
checking for nhc98... no
checking for hbc... no
Also look in mk/config.mk, at the value of GhcCanonVersion.
GHC = /usr/bin/ghc
GhcDir = $(dir $(GHC))
GhcVersion = 6.4
GhcMajVersion = 6
GhcMinVersion = 4
GhcPatchLevel = 0
# Canonicalised ghc version number, used for easy (integer) version
# comparisons. We must expand $(GhcMinVersion) to two digits by
# adding a leading zero if necessary:
ifneq $(findstring $(GhcMinVersion), 0 1 2 3 4 5 6 7 8 9)
GhcCanonVersion = $(GhcMajVersion)0$(GhcMinVersion)
else
GhcCanonVersion = $(GhcMajVersion)$(GhcMinVersion)
endif
Maybe you switched GHC versions but didn't reconfigure?
I think the problem is that I called autoconf etc. before I called
darcs-all get, but not after. Calling autoreconf fixed the problem.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--make keep going?
is there an option to get ghc to keep going if it encounters an error building a file with --make? as in, I'd like it to continue compiling as much as it can only skipping what actually depends on the file that failed rather than completly aborting everything. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Missing Folder in ghc?
Simon Marlow wrote: It looks like you expected to build GHC by grabbing the darcs repo and reading the README file - that isn't a route I anticipated :-) I'll make sure the README gets updated at some point. Thanks. Now the build process gets stuck here: ==fptools== make all -wr -f Makefile; in /home/ashley/Projects/Collected/Haskell/ghc/libraries/base rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir GHC/Base_split; else /usr/bin/find GHC/Base_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi The compiler just sits and does nothing for hours. It doesn't even use any CPU, it seems to be just waiting for something (in state S+ according to ps). I tried running the command with -H64m, but that didn't help. With -v it gives this: Glasgow Haskell Compiler, Version 6.5, for Haskell 98, compiled by GHC version 6.4 Using package config file: /home/ashley/Projects/Collected/Haskell/ghc/ghc/driver/package.conf.inplace Using package config file: /home/ashley/.ghc/i386-linux-6.5/package.conf package haskell98-1.0 will be ignored due to missing dependencies: base-1.0 package template-haskell-1.0 will be ignored due to missing dependencies: base-1.0 package unix-1.0 will be ignored due to missing dependencies: base-1.0 package Cabal-1.1.4 will be ignored due to missing dependencies: base-1.0 package parsec-2.0 will be ignored due to missing dependencies: base-1.0 package haskell-src-1.0 will be ignored due to missing dependencies: base-1.0 package network-1.0 will be ignored due to missing dependencies: base-1.0 package QuickCheck-1.0 will be ignored due to missing dependencies: base-1.0 package HUnit-1.1 will be ignored due to missing dependencies: base-1.0 package mtl-1.0 will be ignored due to missing dependencies: base-1.0 package fgl-5.2 will be ignored due to missing dependencies: base-1.0 package stm-1.0 will be ignored due to missing dependencies: base-1.0 package readline-1.0 will be ignored due to missing dependencies: base-1.0 Hsc static flags: -static *** Literate pre-processor: /home/ashley/Projects/Collected/Haskell/ghc/ghc/utils/unlit/unlit -h GHC/Base.lhs GHC/Base.lhs /tmp/ghc28900_0.lpp *** C pre-processor: gcc -E -undef -traditional -v -I include -I /home/ashley/Projects/Collected/Haskell/ghc/ghc/includes -D__HASKELL1__=5 -D__GLASGOW_HASKELL__=605 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -Dlinux_BUILD_OS=1 -Di386_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Di386_HOST_ARCH=1 -x c /tmp/ghc28900_0.lpp -o /tmp/ghc28900_0.hscpp Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) /usr/lib/gcc/i486-linux-gnu/4.0.2/cc1 -E -traditional-cpp -quiet -v -I include -I /home/ashley/Projects/Collected/Haskell/ghc/ghc/includes -D__HASKELL1__=5 -D__GLASGOW_HASKELL__=605 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -Dlinux_BUILD_OS=1 -Di386_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Di386_HOST_ARCH=1 /tmp/ghc28900_0.lpp -o /tmp/ghc28900_0.hscpp -mtune=i486 -undef ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: include /home/ashley/Projects/Collected/Haskell/ghc/ghc/includes /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.0.2/include /usr/include End of search list. *** Checking old interface for GHC.Base: *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 2851 *** Simplify: It stops and waits there. This is my machine: $ uname -a Linux rollright 2.6.12-10-386 #1 Mon Feb 13 12:13:15 UTC 2006 i686 GNU/Linux ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Missing Folder in ghc?
On 2-Mar-06, at 7:35 PM, Ashley Yakeley wrote: Thanks. Now the build process gets stuck here: I ran into this yesterday, but didn't have time to look into it; today, ./darcs-all pull seems to have fixed it. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
