- Glasgow-haskell-users

How to compile .hc files with gcc?
by Srđan Stipić 03 Jul '07

03 Jul '07

I wanted to compile simple Haskell program (simple.hs) to .c and after that to target platform (x86). I did the following things: ghc -C simple.hs mv simple.hc simple.c gcc -c simple.c -I/usr/lib/ghc-6.6/include/ And I got the following error message: In file included from /usr/lib/ghc-6.6/include/Stg.h:148, from treci.c:3: /usr/lib/ghc-6.6/include/Regs.h:220: warning: call-clobbered register used for global register variable /usr/lib/ghc-6.6/include/Regs.h:226: warning: call-clobbered register used for global register variable /tmp/ccBtIPsT.s: Assembler messages: /tmp/ccBtIPsT.s:31: Error: junk at end of line, first unrecognized character is `-' /tmp/ccBtIPsT.s:63: Error: junk at end of line, first unrecognized character is `-' How to compile .hc files with gcc? Tnx, Srdjan

2 2

-keep-hc-files or -keep-hc-file?
by Christian Maeder 02 Jul '07

02 Jul '07

I'm currently confused if it must be plural or singular (or any) http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilatio… shows plural options whereas http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html… shows them in singular (except -keep-tmp-files) Cheers Christian

3 3

readArray is faster than unsafeRead
by Scott Dillard 01 Jul '07

01 Jul '07

Hello, I'm writing some matrix multiplication and inversion functions for small matrices (3x3 and 4x4 mostly, for 3d graphics, modeling, simulation, etc.) I noticed that the matrix multiplication was a bottleneck so I set out to optimize and found that using unsafeRead instead of (!) (or readArray in stateful code) helped a lot. So then I went to optimize my gaussian elimination function and found just the opposite. unsafeRead is slower than readArray. This struck me as very odd considering that readArray calls unsafeRead. If there is a "good" reason why the compiler optimized readArray better than unsafeRead, I'd like to know what it is so that I can make all my array code safe as well as fast. (By "good" reason I mean something deterministic and repeatable, not just luck.) On the otherhand, if this is a fluke, I'm inclined to think that it's not the safe code which is freakishly fast, but the unsafe code which is needlessly slow. That is, something about my program is hindering optimization of the unsafe code. What is it? Attached is the profiling results and a test program with a handful of matrix multiplication and gaussian elimination functions to illustrate what I've seen. This happens both on amd64 and intel core architectures. Thanks for any insight, Scott

5 6

6.6.1 on long lists
by Serge D. Mechveliani 30 Jun '07

30 Jun '07

Dear GHC developers, I tried to test the ghc-6.6.1 performance on long lists. And there is something a bit suspicious about the test. Consider the program ----------------------------------------- main = putStr (shows res "\n") where n = k*10^6 :: Int k = 2 -- put k = 2,4,6, ... res = head $ rev [1 .. n] rev xs = r [] xs where r xs [] = xs r xs (y: ys) = r (y: xs) ys ----------------------------------------- 512 Mb RAM machine, Pentium 4, 1.6 GHz, Debian Linux. `Making': ghc -O --make Main Running time Main +RTS -M400m -RTS ---- ghc-6.6.1 -------------------| k time [sec] minimal needed ghc-5.02.3 for 400Mb heap (-M..) [Mb] 2 1.3 41 2 sec 41 Mb 4 3.0 6 7.8 8 8.8 164 8 ------------------ 10 23.7 12 24.7 244 14 25.1 13 ----------------------------------------------------------------- Should the cost of this program be linear in k ? For example: 8/4 = 2, time(8)/time(4) = 8.8/3.0 =~= 2.9 Should this ratio be near 2.0 ? Further, at k = 10, the time jumps. This is, probably, due to that a list of 10*10^6 ints takes about 8*10*10^6 bytes =~= 80 Mb (please, is this so ?), the program may need a copy of this list ... and this total may be close to -M400M (?), and thus garbage collection happens (once). After k = 10, it looks again like linear. My impression is that at the segment k <- [2, 8] the cost is about k*(log k). Thank you in advance for your comments. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

ghc api, some simple questions
by Claus Reinke 29 Jun '07

29 Jun '07

- {-# OPTIONS_GHC -package ghc #-} would be useful, doesn't give a warning, but doesn't work, either. -package works in ghci, but not in source pragmas, why? - hostSession hardcoding topDir doesn't seem to be a good idea. shouldn't GHC export means to get at the "hosting" ghc session (the one compiling the current code), so that one could ask for topDir there? currently, i'm calling "ghc --print-libdir" externally .. if nothing else, perhaps something like the 'ghcDir' hack from the example below could be in GHC? - ppr/printForUser should GHC reexport Outputable? also, ppr doesn't seem to handle infix op definitions correctly, printing the left-hand side in prefix form, but without parentheses? [ghc 6.6.1] claus ----------------------------------------------------- {-# OPTIONS_GHC -package ghc #-} module API where import DynFlags import GHC import System.Process import System.IO import Outputable mode = Interactive -- shouldn't something like this be in System.Process? writer >| cmd = runInteractiveCommand cmd >>= \(i,o,e,p)->writer i cmd |> reader = runInteractiveCommand cmd >>= \(i,o,e,p)->reader o -- shouldn't GHC export a hostSession, -- so that we could ask for things like topDir there? ghcDir = "ghc --print-libdir" |> (fmap dropLineEnds . hGetContents) where dropLineEnds = filter (not . (`elem` "\r\n")) main = defaultErrorHandler defaultDynFlags $ do s <- newSession mode . Just =<< ghcDir flags <- getSessionDynFlags s (flags, _) <- parseDynamicFlags flags ["-package ghc"] GHC.defaultCleanupHandler flags $ do setSessionDynFlags s flags{ hscTarget=HscInterpreted } addTarget s =<< guessTarget "API.hs" Nothing load s LoadAllTargets prelude <- findModule s (mkModuleName "Prelude") Nothing usermod <- findModule s (mkModuleName "API") Nothing setContext s [usermod] [prelude] Just cm <- checkModule s (mkModuleName "API") unqual <- getPrintUnqual s printForUser stdout unqual $ ppr $ parsedSource cm

1 0

GHC 6.6.1 Build failure on plain vanilla linux i686 build
by Robin Bate Boerop 29 Jun '07

29 Jun '07

My build dies very soon after issuing "make". Here are the last few lines. Does anyone know what is happening and how to fix it? (The floating constant of which the error message speaks is __GHC_PATCHLEVEL__, which is set to 2.20060331.) I have a working GHC 6.4 installed, BTW. /sec/bin/ghc -optc-O -optc-I. -optc-Iinclude -optc-D__GHC_PATCHLEVEL__=2.20060331 -optc-I../libraries/base/cbits -optc-I../libraries/base/include -H16m -O -I. -Iinclude -Rghc-timing -ignore-package Cabal -I../libraries -fglasgow-exts -no-recomp -c cbits/unicode.c -o cbits/unicode.o cbits/unicode.c:1:63: error: floating constant in preprocessor expression <<ghc: 13597044 bytes, 3 GCs, 103440/103440 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.17 elapsed), 0.01 GC (0.02 elapsed) :ghc>> make[2]: *** [cbits/unicode.o] Error 1 make[1]: *** [boot] Error 2 make: *** [stage1] Error 1

2 3

Re: 64-bit windows version?
by Peter Tanski 26 Jun '07

26 Jun '07

> skaller wrote: > >> On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote: >> >>> Bulat Ziganshin wrote: >>> >>>> Hello glasgow-haskell-users, >>>> >>>> are you plan to implement 64-bit windows GHC version? >>>> >>> The main thing standing in the way of this is the lack of a 64- >>> bit port of >>> mingw. >>> >> >> Why do you need mingw? What's wrong with MSVC++? The largest problem is the build system: GHC uses autoconf with custom makefiles. I have looked into porting the whole thing to a Visual Studio project, using SCons (unreliable), CMake (limited command line abilities--good for a one-shot build but really just a "safe" lowest-common-denominator version of Make), Waf (another python-based build system that started as a fork of SCons for the KDevelop changeover from Autotools) and Jam. I would prefer to use Jam but I'm afraid I would be the only one who would ever want to support it. Nothing has the auto-configuration abilities you (John) built into the Felix Interscript-based system but I do not porting the build system (at least) to Interscript would go over well with anyone else who wanted to maintain it and the build itself would require heavy customisation. I have tested all of these on a small scale (the replacement-Integer library). The best option seems to be to create a VS project (not trivial--lots of glue) so a user may also call that from Make (if under Mingw) or pure DOS. There is also some gcc-specific code in the RTS (inline assembler, use of extern inline, etc.) By the way, as of gcc-4.2 (I believe; I know it is true for gcc-4.3) the use of 'extern inline' now conforms strictly to the C99 standard so we will have to add the option '- fgnu-89-inline' to get the old behaviour back--'extern inline' is used in some of the headers. Converting those 'extern inline's to 'static inline' or best yet plain 'inline' would also solve the problem. Ian Taylor's message at http://gcc.gnu.org/ml/gcc/2006-11/ msg00006.html describes this in greater detail; his proposal was implemented. > I don't think we'll be able to drop the mingw route either, mainly > because while > the MS tools are free to download, they're not properly "free", and > we want to > retain the ability to have a completely free distribution with no > dependencies. I don't know of any completely free 64-bit compilers for Windows. The Intel compilers are free for 30-day evaluation but everything else is for Win32. For the base Win32-native port there are many compilers available but I have mostly worked on using CL and Yasm (assembler) as replacement back-end compilers for GHC. > There are people that want a Cygwin port too; personally I think > this is heading > in the wrong direction, we want to be more "native" on Windows, > using the native > object format and interoperating directly with the native Windows > tools. Cygwin has a real problem with gcc: it is far behind everything else (gcc-3.4.4, though Mingw isn't much better) and it doesn't look like that will change anytime soon. It is also only 32-bit, I believe. Cheers, Pete

8 29

hpux 11.0 floating point alignment problem in PrimOps.cmm
by Joe Buehler 26 Jun '07

26 Jun '07

I am getting a floating point alignment exception during a GHC 6.4.2 bootstrap on hpux 11.0 -- the stage 1 ghc core dumps. The stack trace looks like this: (gdb) where #0 0x1ac0df8 in __gmpn_mul_1 () #1 0x1abdd24 in __gmpz_mul () #2 0x1aa2ef4 in timesIntegerzh_fast () #3 0x1ab8124 in StgRun () #4 0x1a9bc08 in schedule () #5 0x1a9c5f4 in waitThread_ () #6 0x1a9c52c in scheduleWaitThread () #7 0x1a99a88 in rts_evalLazyIO () #8 0x1a990dc in main () (gdb) The timesIntegerzh_fast routine is calling into libgmp, libgmp is then core dumping because of an access to a double with bad alignment -- it is trying to load a double from a 4-byte aligned address -- hpux requires 8 byte alignment. The code for timesIntegerzh_fast comes from PrimOps.cmm. It is making use of these memory locations: section "bss" { mp_tmp1: bits8 [SIZEOF_MP_INT]; } section "bss" { mp_tmp2: bits8 [SIZEOF_MP_INT]; } section "bss" { result1: bits8 [SIZEOF_MP_INT]; } section "bss" { result2: bits8 [SIZEOF_MP_INT]; } Might this alignment problem be fixed by adding in some "align 8" statements? Joe Buehler

1 0

Build Systems (was: Re: 64-bit windows version?)
by Peter Tanski 25 Jun '07

25 Jun '07

Gour wrote: > Have you seen Aap (http://www.a-a-p.org/) ? I have A-A-P (or Aap) but I only did the basic hello-world build and read the manual. It has in fact been updated as late as Febuary 2007. The Make-like syntax is elegant. Maybe someone else could look at this and see if they want to do something big in it? One thing that would have to be done for Haskell is write special Aap modules. The builtin ability to grab sources from CVS and publish things to the web might be extended to darcs and Trac. My one gripe is that it requires both Python and Perl. Cheers, Pete

1 0

need help with 6.4.2 boot build for hpux 11.0
by Joe Buehler 25 Jun '07

25 Jun '07

I am attempting to get 6.4.2 booted under hpux 11.0 following the instructions for building from hc files generated on another machine. The target compiler builds but will not build a trivial test program. The error message indicates that it cannot import the Prelude module. Looking at the system calls that the compiler is making I am guessing that package.conf.inplace is not correct. The one produced by the target build is basically empty, as compared to the one on the host machine. Can this file just be copied from the host build machine to the target? Another question I have is this, is there a better version of GHC to try this with? The instructions don't match the 6.6 source tree layout so I went back to 6.4.x. I have had to install some patches though so am wondering if I would have an easier time of this with something even earlier? -- Joe Buehler

1 0