- Glasgow-haskell-users

environment variables for ghc
by Frederik Eaton 09 Mar '05

09 Mar '05

Is it possible to set environment variables which ghc will look at, corresponding to command line options such as '-i' or '-package-conf'? I.e. the equivalent of gcc's LIBRARY_PATH, CPATH, etc... or perl's PERL5LIB or even PERL5OPT (which is the most flexible). These would be really convenient since I have a package.conf file in my home directory for locally installed packages, and some modules in another directory that I often link to. Frederik -- http://ofb.net/~frederik/

1 0

environment variables for ghc
by Frederik Eaton 08 Mar '05

08 Mar '05

Is it possible to set environment variables which ghc will look at, corresponding to command line options such as '-i' or '-package-conf'? I.e. the equivalent of gcc's LIBRARY_PATH, CPATH, etc... or perl's PERL5LIB or even PERL5OPT (which is the most flexible). These would be really convenient since I have a package.conf file in my home directory for locally installed packages, and some modules in another directory that I often link to. Frederik -- http://ofb.net/~frederik/

1 0

infix type operators
by Ross Paterson 08 Mar '05

08 Mar '05

The User's Guide says: The only thing that differs between operators in types and operators in expressions is that ordinary non-constructor operators, such as + and * are not allowed in types. Reason: the uniform thing to do would be to make them type variables, but that's not very useful. A less uniform but more useful thing would be to allow them to be type constructors. But that gives trouble in export lists. So for now we just exclude them. Conal has pointed out that the uniform thing would be useful for general arrow combinators: liftA2 :: Arrow (~>) => (a -> b -> c) -> (e ~> a) -> (e ~> b) -> (e ~> c)

1 0

RE: Registerised x86_64 port: test version available
by Simon Marlow 08 Mar '05

08 Mar '05

On 08 March 2005 15:59, Duncan Coutts wrote: > On Tue, 2005-03-08 at 15:16 +0000, Simon Marlow wrote: >> I've put up an x86_64/Linux registerised build for testing here: >> >> >> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4-x86_64-unknown-linux >> .tar.bz2 >> >> This is a binary distribution: ./configure && make -k install. The >> -k is necessary because it doesn't have all the docs. It was built >> on Fedora FC3. Note it claims version 6.4, but actually it's >> 6.4.20050308. >> >> Still no GHCi, no foreign export dynamic, no native code gen. But it >> seems to work (this is a stage 3 build). > > For someone with an amd64 and some spare time: > > So the burning question is: do all those extra registers help? Does > Haskell code run faster in 64bit mode or 32bit mode? > > Performance graphs on a postcard to the usual address... I haven't really made full use of the extra registers yet. The register mapping is certainly sub-optimal: I didn't use any of the call-clobbered regs, but almost certainly it will be a good idea to do so. So far I've only assigned a single argument register, the same as x86. Upshot: you're unlikely to get much better performance than the plain x86 registerised build at the moment. When I've got some time I'll play around with more aggressive register assignments (or anyone else is welcome... just fiddle with the settings in ghc/includes/MachRegs.h, and don't forget to set the appropriate CALLER_SAVES macro if you pinch a call-clobbered reg). Cheers, Simon

1 0

Happy, again
by Frank-Andre Riess 08 Mar '05

08 Mar '05

Hi folks, having set up some monadic type for usage with Happy, I've encountered some thing that puzzles me: as it seems, once happyError gets called, you cannot get back into the parser "loop" even if you return some `Failed xy::ParseMonad' instead of calling error. How and where do I catch such an error and can I really cope with most "unexpected errors" this way (even at the beginning of the input)? Thanks in advance, Frank-Andre Riess P.S.: Sorry, dear moderator, for sending this message twice. The first one was sent with an alias different to the e-mail address I've registered with (although being the same account). Me pardon.

1 0

RE: FW: RE: x86_64 port
by Simon Marlow 08 Mar '05

08 Mar '05

On 07 March 2005 18:01, Kurt Roeckx wrote: > On Mon, Mar 07, 2005 at 11:47:31AM -0000, Simon Marlow wrote: >> >> $ cat bug.c >> register void * R1 __asm__("%r13"); >> >> extern void g(void); >> static void f(void) { >> R1 = g; >> goto *R1; >> } >> $ gcc -S -O bug.c >> $ >> >> And take a look at the generated assembly for the function f: >> >> f: >> .LFB2: >> movl $g, %eax >> jmp *%rax > > I get the same with both gcc-3.3 and gcc-3.4. They generate > identical code. > >> Note that the assignment to the global variable R1 has been lost. It >> works fine on x86 though: change the register variable to %esi and >> try it. > > It looks to me like it's using eax/rax instead of r13 to me. > It's probably doing some optimizing it shouldn't, but on the > other hand isn't "wrong". ... > Anyway, as summary: > - It's using a movl where it should use a movq > - It's probably doing some optimizations it shouldn't, but > they're not "wrong" in this testcase and probably can't be > avoided because of the way gcc works. > Those happen on both i386 and amd64. The question of whether this behaviour is wrong or not is interesting. On the face of it, the generated code is incorrect because it doesn't implement the semantics of the original program. However, we have to be clear about what the semantics of the original program *is*. The register annotation is just an annotation, and therefore doesn't affect the semantics. But the gcc manual has this to say about computed goto: You may not use this mechanism to jump to code in a different function. So, perhaps the example program relies on undefined behaviour. But, you can change the example program so that gcc has no idea where it's jumping to, and gcc will still generate incorrect code. So in fact it has nothing to do with the jump destination being outside the current function. It's a bug. Cheers, Simon

1 0

[ ghc-Feature Requests-1124080 ] Implicit Parameters and monomorphism
by SourceForge.net 08 Mar '05

08 Mar '05

Feature Requests item #1124080, was opened at 2005-02-16 17:01 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1124080&group_… Category: None Group: None Status: Open >Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: Implicit Parameters and monomorphism Initial Comment: http://www.haskell.org/pipermail/haskell-cafe/2005-January/008571.html Notes some oddness with recursive binding of implicit parameters. Roughly, giving a type signature to a function with implicit params causes its bindings to act recursively, despite what section 7.4.5.2 of the user's guide says. ---------------------------------------------------------------------- >Comment By: Simon Marlow (simonmar) Date: 2005-03-08 10:35 Message: Logged In: YES user_id=48280 This "bug" is just to record the strange interaction between implicit parameters and monomorphism. [adding text of original message] Jim Apple wrote: > Does anyone have examples of these? This one scares the foo out of me: > >>> * It's not even safe in general to add a signature giving the same type >>> that the compiler would infer anyway Here's an example: > len :: [a] -> Int > > len xs = let ?accum = 0 in len' xs > > len' [] = ?accum > len' (x:xs) = let ?accum = ?accum + (1::Int) in len' xs *Main> :t len' len' :: forall a. (?accum :: Int) => [a] -> Int *Main> len "hello" 0 > len :: [a] -> Int > > len xs = let ?accum = 0 in len' xs > > len' :: forall a. (?accum :: Int) => [a] -> Int > > len' [] = ?accum > len' (x:xs) = let ?accum = ?accum + (1::Int) in len' xs *Main> :t len' len' :: forall a. (?accum :: Int) => [a] -> Int *Main> len "hello" 5 This happens as a side effect of the way that type inference currently works on recursive binding groups. It happens with typeclass dictionaries too, but it isn't observable because they can't be rebound in a local scope. -- Ben ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1124080&group_…

1 0

RE: [Haskell] "Classic" vs. "Cunning Newtype" Derivation
by Simon Peyton-Jones 08 Mar '05

08 Mar '05

[redirecting to GHC users list] John is right. I've added something to the user manual to say so. | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of John Meacham | Sent: 08 March 2005 00:20 | To: haskell(a)haskell.org | Subject: Re: [Haskell] "Classic" vs. "Cunning Newtype" Derivation | | On Mon, Mar 07, 2005 at 04:06:44PM -0800, Ashley Yakeley wrote: | > I make quite a lot of use of "cunning newtype" deriviation (in GHC), | > because it's easy to understand. | > | > newtype Mytype = MkMytype T deriving C | > | > However, if I use one of the standard derivable classes (Eq, Ord, Enum, | > Bounded, Show, and Read), I believe that form of deriving takes priority. | > | > AFAICT from the H98 Report ch. 10, for Eq, Ord and Bounded this works | > out as the same thing, Enum doesn't apply, and Read and Show do | > something different. Is this correct, or are there subtle differences? | | Read, Show, Typeable, and Data are the only differences AFAIK. | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

RE: FW: RE: x86_64 port
by Simon Marlow 07 Mar '05

07 Mar '05

On 04 March 2005 17:32, Kurt Roeckx wrote: > I have no idea what ghc has too do with gcc, A bit of background: GHC uses gcc as a backend compiler. GHC generates C code that is compiled using gcc (we also have a native code generator for some platforms; but not for x86_64 yet). > or what the problem exactly is. The problem is that gcc generates incorrect code for C code that uses global register variables. You won't have noticed this, because most programs don't use global register variables. GHC uses global register variables to speed up the generated code. > We have very little problems with gcc for the debian > amd64 port. Our default compiler is still 3.3. This builds > almost everything without problems, however we build a few > mozilla packages with gcc-3.4. > > All I can tell is that ghc6 seems to be working on debian amd64. > It can build itself and things like that. That build of ghc6 is what we call "unregisterised": it doesn't make use of register variables to speed up the generated code. IOW, it generates plain ANSI C code, which gcc compiles fine. > Can someone please give a test case (and show what to do) to see > what is wrong? Ok, here's a really simple example: $ cat bug.c register void * R1 __asm__("%r13"); extern void g(void); static void f(void) { R1 = g; goto *R1; } $ gcc -S -O bug.c $ And take a look at the generated assembly for the function f: f: .LFB2: movl $g, %eax jmp *%rax Note that the assignment to the global variable R1 has been lost. It works fine on x86 though: change the register variable to %esi and try it. > Out current default compiler in debian is: > gcc version 3.3.5 (Debian 1:3.3.5-8) > > The gcc 3.4 version is: > gcc version 3.4.4 20050203 (prerelease) (Debian 3.4.3-9) > > And ghc6 is at version 6.2.2-3. I'm going to try with different versions of gcc. I've just submitted this bug report to the gcc guys. Cheers, Simon

3 3

RE: FW: RE: x86_64 port
by Simon Marlow 07 Mar '05

07 Mar '05

On 07 March 2005 16:40, Simon Marlow wrote: > On 07 March 2005 16:18, David Brown wrote: > >> On Mon, Mar 07, 2005 at 11:47:31AM -0000, Simon Marlow wrote: >> >>> $ cat bug.c >>> register void * R1 __asm__("%r13"); >>> >>> extern void g(void); >>> static void f(void) { >>> R1 = g; >>> goto *R1; >>> } >>> $ gcc -S -O bug.c >>> $ >>> >>> And take a look at the generated assembly for the function f: >>> >>> f: >>> .LFB2: >>> movl $g, %eax >>> jmp *%rax >>> >>> Note that the assignment to the global variable R1 has been lost. >>> It works fine on x86 though: change the register variable to %esi >>> and try it. >> >> Hmm. On gcc 3.3.5 that I have, it discards the assignment on x86 as >> well. > > Yes, looks like it fails with 3.4.1 and 3.4.3 I have here, but 3.2.2 > works. > > Now I'm quite surpised that this hasn't affected us on x86. Very > strange. The mystery as to why this doesn't affect us on x86 is solved: on x86 we generate slightly different C code, including a dummy function call: extern void g(void); static void f(void) { R1 = g; dummy(); goto *R1; } the call to dummy() (which we filter out from the assembly later) is enough to force gcc to emit the assignment to R1. That dummy function call has been there for ever, and the original reason for it has been lost in the mists of time... comments in the source code seemed to indicate that it was probably not necessary any more, so for x86_64 I removed it. It looks like I'll have to reinstate it to work around this bug, though. Cheers, Simon

4 3