- Glasgow-haskell-users

ghc and aarch64?
by Jens Petersen 26 Mar '13

26 Mar '13

I am curious if anyone has started or is planning to work on porting GHC to the new ARM 64bit architecture AArch64 for Linux? Jens

3 3

Re: Libffi errors while cross-compiling GHC 7.6.2 (Stage 1)
by Nikita Karetnikov 23 Mar '13

23 Mar '13

> Is /usr/bin/gcc a MIPS cross-compiler? If not, how do you expect it > to work? Right, I wasn't using a cross-compiler. That's the problem. I haven't succeeded in cross-building yet. I'm using a distro with a non-common directory structure and I still have to figure out how to specify both GCCs. But it has nothing to do with the ticket. So I've just closed it. I apologize for the noise.

1 0

Compiled code
by migmit 22 Mar '13

22 Mar '13

Suppose I compiled some module and kept it's .hi and .o files. Is it possible to use this module in my program if the source code was deleted for some reason? Seems like the answer is "yes" — by creating a fake .hs file (with no real content) and touch-in .hi and .o files I tricked ghc so that it didn't attempt to recompile the module, so the information in .hi and .o files is sufficient. But ghc insists on having the .hs file around, and I didn't find a way to turn it off. Is there any? Or there is a specific reason not to have it?

1 0

Release plans
by Ian Lynagh 21 Mar '13

21 Mar '13

Hi all, Thank you to everyone who gave us feedback on when we should release 7.8.1, and on future release plans in general. We've looked at all the responses, and we think that the best plan is to continue to make major releases annually, with minor "patch-level" releases between them. Additionally, we may recommend particular snapshots, and provide binary builds for all tier-1 platforms, for people who wish to test new features etc in HEAD. There is more detail on how all this will work here: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Releases We will therefore aim for a 7.8.1 release in October. We do not currently expect to make a 7.6.3 release, although that may change if serious bugs in 7.6.2 are discovered. Would a 7.7.x recommended snapshot be useful to you? Tell us if you want one. Compared to 7.6 it would contain: * polykinded Typeable library * major improvements in DPH (vectorisation avoidance, new vectoriser) * type holes * rebindable list syntax * major changes to the type inference engine * type level natural numbers * overlapping type families * the new code generator * support for vector (SSE/AVX) instructions * Scheduler changes to the RTS to improve latency Is it worth us putting out a preview, or are you happy to work from the nightly snapshots and wait for the full release in October? Thanks Ian

8 10

Polymorphic implicit parameters
by Roman Cheplyaka 21 Mar '13

21 Mar '13

I'm curious as to why GHC doesn't accept the following (contrived) module: {-# LANGUAGE ImplicitParams, RankNTypes #-} f :: (?g :: (forall a . a -> a)) => a -> a f = ?g The error message is: Illegal polymorphic or qualified type: forall a. a -> a In the type signature for `f': f :: ?g :: (forall a. a -> a) => a -> a It's not a big deal since one can wrap the polymorphism in a newtype, but it's somewhat unexpected. Roman

2 2

ANNOUNCE: GHC 7.6.2 Release Candidate 1
by Ian Lynagh 21 Mar '13

21 Mar '13

We are pleased to announce the first release candidate for GHC 7.6.2: http://www.haskell.org/ghc/dist/7.6.2-rc1/ This includes the source tarball, installers for Windows, and bindists for Windows, Linux, OS X and FreeBSD, on x86 and x86_64. We plan to make the 7.6.2 release early in 2013. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

8 12

Does GHC 7.8 make targeting bare metal ARM any easier?
by Jeremy Shaw 20 Mar '13

20 Mar '13

There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar. Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also highly prone to bitrot. With GHC 7.8, I believe we will be able to cross-compile to the Raspberry Pi platform. But, what really appeals to me is going that extra step and avoiding the OS entirely and running on the bare metal. Obviously, you give up a lot -- such as drivers, network stacks, etc. But, there is also a lot of potential to do neat things, and not have to worry about properly shutting down an embedded linux box. Also, since the raspberry pi is a very limited, uniform platform, (compared to general purpose PCs) it is feasible to create network drivers, etc, because only one chipset needs to be supported. (Ignoring issues regarding binary blobs, undocumented chipsets, usb WIFI, etc). I'm wondering if things are any easier with cross-compilation support improving. My thought is that less of GHC needs to be tweaked? - jeremy

3 2

scope invariants in core
by Ranjit Jhala 18 Mar '13

18 Mar '13

Hi all, I have been manipulating CoreExpr to convert it to A-Normal Form. Mostly, things have been working fine, but I hit an error this morning of the form: lq_anf__d11u is out of scope where lq_anf__d11u is a binder I have introduced in the transformed expression Data.ByteString.Internal.c_strlen = (\ (ds_d11l :: GHC.Ptr.Ptr Foreign.C.Types.CChar) -> case ds_d11l of lq_anf__d11t { GHC.Ptr.Ptr ds_d11n -> let { lq_anf__d11x :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Word.Word32 #) [LclId] lq_anf__d11x = \ (ds_d11q :: GHC.Prim.State# GHC.Prim.RealWorld) -> case {__pkg_ccall main strlen GHC.Prim.Addr# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Word# #)} ds_d11n ds_d11q of lq_anf__d11u { __DEFAULT -> case lq_anf__d11u of lq_anf__d11v { (# ds_d11p, ds_d11o #) -> let { lq_anf__d11w :: GHC.Word.Word32 [LclId] lq_anf__d11w = GHC.Word.W32# ds_d11o } in (# ds_d11p, lq_anf__d11w #) } } } in GHC.Types.IO @ GHC.Word.Word32 lq_anf__d11x }) It would appear, that the variable IS in scope (as it is bound by the case-expression just before it is used, but perhaps the binder is not added to the environment because of its type (# ... , ... #)? Or is there some other invariant I am breaking? Can anyone familiar with the scoping invariants of CoreExpr/CoreSyn give me a hint as to what might be happening? Many thanks in advance! Ranjit.

2 3

Annotating an AST with type checking / source line number info
by Craig Innes 14 Mar '13

14 Mar '13

Hi there, I am not hugely familiar with compilers or the particulars of GHC, but am interested in creating a few programs which manipulate Haskell source code in particular ways. Two things I would like to be able to do are: - Swap every occurrence of a particular type for a different / dummy value of that type. - Find the line / column number of every place a value of a particular type is used >From compiling Haskell programs, it seems clear that GHC performs type checking, and when I get a compile error it is able extract line and column information about where I had the error, so it appears as if GHC is annotating the source with this information as it compiles. I am struggling to find a lot in the way of learning materials for GHC, but from trawling through the API documentation (I am using GHC version 7.4.2), it seems like I can generate an abstract syntax tree via the method: parseModule :: GhcMonad<http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:GhcMon…>m => ModSummary<http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:ModSum…>-> m ParsedModule<http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:Parsed…> My question is this: what combination of functions do I have to use to get not only an AST for my source, but an AST annotated with typing information and line / column number annotations for values within it? Also, as I am a bit of a newbie to this whole GHC API thing, any pointers to resources to learn more about it would be enormously appreciated. Thanks, Craig

3 2

Re: Foreign.StablePtr: nullPtr & double-free questions.
by Edward Z. Yang 13 Mar '13

13 Mar '13

Excerpts from Remi Turk's message of Fri Mar 08 18:28:56 -0800 2013: > Good night everyone, > > I have two questions with regards to some details of the > Foreign.StablePtr module. [1] > > 1) The documentation suggests, but does not explicitly state, that > castStablePtrToPtr `liftM` newStablePtr x > will never yield a nullPtr. Is this guaranteed to be the case or not? > It would conveniently allow me to store a Maybe "for free", using > nullPtr for Nothing, but I am hesitant about relying on something that > isn't actually guaranteed by the documentation. No, you cannot assume that. In fact, stable pointer zero is base_GHCziTopHandler_runIO_info: ezyang@javelin:~/Dev/haskell$ cat sptr.hs import Foreign.StablePtr import Foreign.Ptr main = do let x = castPtrToStablePtr nullPtr freeStablePtr x ezyang@javelin:~/Dev/haskell$ ~/Dev/ghc-build-tick/inplace/bin/ghc-stage2 --make sptr.hs -debug [1 of 1] Compiling Main ( sptr.hs, sptr.o ) Linking sptr ... ezyang@javelin:~/Dev/haskell$ gdb ./sptr GNU gdb (GDB) 7.5-ubuntu Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /srv/code/haskell/sptr...done. (gdb) b freeStablePtrUnsafe Breakpoint 1 at 0x73f8a7: file rts/Stable.c, line 263. (gdb) r Starting program: /srv/code/haskell/sptr [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, freeStablePtrUnsafe (sp=0x0) at rts/Stable.c:263 263 ASSERT((StgWord)sp < SPT_size); (gdb) list 258 } 259 260 void 261 freeStablePtrUnsafe(StgStablePtr sp) 262 { 263 ASSERT((StgWord)sp < SPT_size); 264 freeSpEntry(&stable_ptr_table[(StgWord)sp]); 265 } 266 267 void (gdb) p stable_ptr_table[(StgWord)sp] $1 = {addr = 0x9d38e0} (gdb) p *(StgClosure*)stable_ptr_table[(StgWord)sp] $2 = {header = {info = 0x4e89c8 <base_GHCziTopHandler_runIO_info>}, payload = 0x9d38e8} Regardless, you don't want to do that anyway, because stable pointers have a bit of overhead. > 2) If I read the documentation correctly, when using StablePtr it is > actually quite difficult to avoid undefined behaviour, at least in > GHC(i). In particular, a double-free on a StablePtr yields undefined > behaviour. However, when called twice on the same value, newStablePtr > yields the same StablePtr in GHC(i). > E.g.: > > module Main where > > import Foreign > > foo x y = do > p1 <- newStablePtr x > p2 <- newStablePtr y > print $ castStablePtrToPtr p1 == castStablePtrToPtr p2 > freeStablePtr p1 > freeStablePtr p2 -- potential double free! > > main = let x = "Hello, world!" in foo x x -- undefined behaviour! > > prints "True" under GHC(i), "False" from Hugs. Considering that foo > and main might be in different packages written by different authors, > this makes correct use rather complicated. Is this behaviour (and the > consequential undefinedness) intentional? I think this bug was inadvertently fixed in the latest version of GHC; see: commit 7e7a4e4d7e9e84b2c57d3d55e372e738b5f8dbf5 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Thu Feb 14 08:46:55 2013 +0000 Separate StablePtr and StableName tables (#7674) To improve performance of StablePtr. Cheers, Edward

2 2