- ghc-devs - Haskell.org

the cmm pages on the wiki seem out of date
by Carter Schonwald 09 Apr '13

09 Apr '13

Hey all, I've been staring at the cmm primop code in ghc over the past week to understand a number of things, and I was just today looking at the current cmm documentation on the ghc wiki. specifically i've been looking at https://github.com/ghc/ghc/blob/master/compiler/cmm/Cmm.hs https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmParse.y and https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm versus the wiki docs http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/CmmType it looks like CMM supports a nicer function definition convention than the wiki implies. (and presumably that also would hold for the ffi for calling user written cmm code too?) If the wiki is out of date, i'm happy to make a first pass at trying to add this info somewhere, thanks -Carter

4 3

integer-simple linker errors?
by Gabor Greif 08 Apr '13

08 Apr '13

Hi all, I am getting below errors from libraries/integer-simple. Which integer-gmp / GHC change caused this? I looked briefly, but could not find anything. Thanks, Gabor 0130407.so: undefined reference to `__word_encodeDouble' /libHSinteger-simple-0.1.1.0-ghc7.7.20130407.so: undefined reference to `__word_encodeFloat'

2 2

Re: [GHC] #7820: Installing profiling library BREAKS non-profiling executable
by Ryan Newton 08 Apr '13

08 Apr '13

By the way, does anyone have a positive example of a package on hackage that (1) uses foreign primops and (2) is robust across a wide variety of platforms and build methods? It would be great to work from such an example. Thanks, -Ryan On Mon, Apr 8, 2013 at 10:57 AM, GHC <cvs-ghc(a)haskell.org> wrote: > #7820: Installing profiling library BREAKS non-profiling executable > > --------------------------+------------------------------------------------- > Reporter: rrnewton | Owner: > Type: bug | Status: new > Priority: normal | Component: Compiler > Version: 7.6.2 | Keywords: profiling > Os: Linux | Architecture: x86_64 (amd64) > Failure: Runtime crash | Blockedby: > Blocking: | Related: > > --------------------------+------------------------------------------------- > I am trying to work through problems with different GHC "ways" so that I > can broadly deploy a library of foreign primops for lockfree data > structures. Here's the package I am testing at the moment: > > https://github.com/rrnewton/haskell-lockfree- > queue/tree/5d990fe43a983fc5ed32c3f58cb2e59df71b00b6/AtomicPrimops > > Here is a recipe for reproducing the bug from within that directory. Both > of these build modes work FINE: > > (cabal install --enable-library-profiling; cd testing; make prof; > ./Test_prof.exe) > (cabal install --disable-library-profiling; cd testing; make; > ./Test_threaded.exe) > > That is, building both library and executable with profiling, or without > profiling, works fine. But then this creates an executable that > segfaults: > > (cabal install --enable-library-profiling; cd testing; make; > ./Test_threaded.exe) > > At runtime the call to the .cmm-defined foreign primop just returns zero, > and then the process segfaults when it tries to use that as a Haskell > value. > > But my understanding is that --enable-library-profiling should just add > extra binaries to .cabal and NOT change the behavior of the non-profiling > binaries. > > Yet I can confirm that I see slightly different binary sizes with the non- > profiling .o and .a files installed in ~/.cabal/lib depending on whether > --enable-library-profiling is activated. Perhaps this in itself is a > cabal bug, but I haven't tracked down exactly what the difference is yet. > > I have confirmed the above behavior under: > * Mac OS (ghc 7.4.2 and 7.6.2) > * Linux, RHEL 6 (ghc 7.4.2 and 7.6.2) > > -- > Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7820> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Excessive inlining in libraries/time/Data/Time/Format.hs
by Gabor Greif 08 Apr '13

08 Apr '13

While investigating the residual problem with #7814, I discovered that there is some excessive inlining going on in libraries/time/Data/Time/Format.hs: wc -l libraries/time/Data/Time/Format.hs libraries/time/dist-install/build/Data/Time/Format.cmm 247 libraries/time/Data/Time/Format.hs 103342 libraries/time/dist-install/build/Data/Time/Format.cmm Format.cmm is created by -ddump-cmm-raw with the STAGE1 GHC HEAD. I am compiling for ELF/PPC, but that should be an irrelevant detail. Can somebody confirm this? Thanks and cheers, Gabor

1 0

Branching base
by Trevor Elliott 06 Apr '13

06 Apr '13

Hi Everyone, I've reached the point in the HaLVM update where I need to start applying patches to the base library. What is the best way to create a branch on my own local fork of the base library, that still plays nicely with the sync-all script? Should I fork all of the repositories that it manages, or is there an option in the packages file that would let me specify a different repo_base for one package? Thanks! --trevor

1 0

Why do Names defined in the current module lack a module name?
by Johan Tibell 05 Apr '13

05 Apr '13

Hi, I'm writing an app that uses the GHC API to extract names from modules. I've written a little AST traversal that finds all Names in the type-checked AST and writes them to a file. I noticed that every Name defined in the current module (i.e. Names generated for top-level function definitions) lack a module name i.e. nameModule_maybe return Nothing. Why is this? Should I just assume that every time nameModule_maybe return Nothing the module name is in fact the name of the current module being compiled? -- Johan

3 13

Re: Linker error in stage2
by PHO 05 Apr '13

05 Apr '13

From: Gabor Greif <ggreif(a)gmail.com> Subject: Re: Linker error in stage2 Date: Thu, 4 Apr 2013 14:42:48 +0200 > Thanks a lot! This worked, but now we have the libffi-related problem > on install: > > /home/ggreif/lib/ghc-7.7.20130403/bin/ghc-pkg: error while loading > shared libraries: libHSterminfo-0.3.2.5-ghc7.7.20130403.so: cannot > open shared object file: No such file or directory > make[1]: *** [install_packages] Error 127 > > This is described in another mail thread, so I'll relax now. I'm glad to hear that. Created a ticket: http://hackage.haskell.org/trac/ghc/ticket/7813 _______________________________________________________ - PHO - http://cielonegro.org/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72

2 1

Cross Compilation
by Trevor Elliott 05 Apr '13

05 Apr '13

Hi Everyone, We're starting to update the HaLVM, which produces Xen binaries from haskell programs, to a more current version of GHC. Currently, we build a stage1 compiler manually, with some patches to the RTS, and trick it into thinking that it's actually stage2 so that we can use template haskell. Ideally, we would like to look at Xen as a cross compilation target, as that provides a bit of a better path for keeping up to date with changes in GHC. After reading some of the documentation on the developers wiki about cross compilation, it wasn't clear if template haskell is usable by a stage1 compiler built where target is not host, is this still the case? If so, what sort of changes would need to be made to enable this, and is it something that we could contribute to? Galois has a little time allocated for updating the HaLVM, and would like to position ourselves so that staying up to date with GHC releases is easier in the future :) Thanks! --trevor

3 4

[RFC] Bang constraint
by Gabor Greif 05 Apr '13

05 Apr '13

Now that Constraint kinds are pretty much into the mainstream, can we consider the '!' annotation in data declarations as a magic constraint? Not unlike NFData, but only ensuring that said value is in WHNF. So the following definitions would be semantically identical > newtype Foo a = Foo a > data Foo a = Foo !a > data Foo a = (!a) => Foo a > data FooC :: (* -> Constraint) -> * -> * where > Foo :: c a => a -> FooC c a > type Foo a = FooC ! a It just occured to me and seemed plausible at first thought, but feel free to flame me because of the magic-ness. Cheers, Gabor

4 4

[PATCH 2/2] add arm-unknown-linux to platforms which do not support shared libs
by Karel Gardas 04 Apr '13

04 Apr '13

This patch disables shared libs support on arm-unknown-linux platform. It unbreaks ghc-stage2 on this platform after recent Ian's changes in dynamic/shared libs domain. The reason why ghc-stage2 fails when linked with shared libs is still unknown so this is just a workaround at the moment, but it at least recovers previous "correct" behavior of ghc-stage2 on ARM/Linux --- mk/config.mk.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mk/config.mk.in b/mk/config.mk.in index de55f0d..2a03ecf 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -95,7 +95,7 @@ TargetElf = YES endif # Some platforms don't support shared libraries -NoSharedLibsPlatformList = +NoSharedLibsPlatformList = arm-unknown-linux ifeq "$(SOLARIS_BROKEN_SHLD)" "YES" NoSharedLibsPlatformList += i386-unknown-solaris2 -- 1.7.3.2

1 0