- Glasgow-haskell-users

RE: The role of INLINE and INLINABLE on recursive functions
by Simon Peyton-Jones 09 Jun '11

09 Jun '11

INLINE: - no effect for a recursive function - for a non-recursive function, always inline a call that (a) is applied to as many args as the LHS of the defn (b) has some interesting context. Ie (\y x-> f x y) doesn't inline f INLINEABLE a) For type-class overloaded functions (including recursive ones) - makes them auto-specialise at call sites in other modules - allows SPECIALISE pragmas for them in other modules b) For non-recursive functions, makes GHC willing, but not super-eager, to inline at call sites. Ie just use GHC's usual inlining rules. The difference from not having the pragma is that the *original* RHS is inlined (if GHC decides to) rather than the optimised RHS. Does that help? The dual role of INLINEABLE is a bit confusing. And the utility of (b) isn't clear to me. Simon | -----Original Message----- | From: Johan Tibell [mailto:johan.tibell@gmail.com] | Sent: 09 June 2011 12:06 | To: Simon Peyton-Jones | Subject: The role of INLINE and INLINABLE on recursive functions | | Hi, | | This comment on Trac got me curious: | | "Ok, we looked at this, and it turns out that 6.12.3 desugars `forever` | differently: in 6.12, a local recursive `let` was introduced, which meant | that `forever` could be inlined (and hence specialised) at every call | site, whereas in 7.0 the desugarer leaves the function as a top-level | recursive function which cannot be inlined. | | The solution is to add an `INLINABLE` pragma for `forever`, which will | allow it to be specialised at a call site." | | What's the meaning of INLINE or INLINABLE on a recursive function? | Normally we don't inline recursive functions (when would we stop | inlining?) so it's unclear to me what the meaning of the pragmas would | be in this cases. I know that INLINABLE on a recursive function that | takes a type class dictionary leads to call site specialization of | that function (but not "inlining"). | | People often use this transformation to get recursive functions inlined: | | f = ... f ... | | f_transformed = go | where go = ... go ... | {-# INLINE f_transformed #-} | | Could we get the same result by just adding an INLINE pragma to the original f? | | Cheers, | Johan

3 2

crash caused by generic visitor (?)
by Ranjit Jhala 09 Jun '11

09 Jun '11

Hi all, I'm trying to extract the set of identifiers that are read in given source file. To this end, I wrote the following code (full source at end.) ------------------------------------------------------------------------ main = do fname <- (!! 0) `fmap` getArgs tcm <- loadTypecheckedSource fname putStrLn $ showPpr tcm -- this works fine putStrLn $ showPpr $ allIds tcm -- this causes the crash return () allIds :: Data a => a -> [Id] allIds = listify (\x -> case (x :: Id) of _ -> True) ------------------------------------------------------------------------ and where: loadTypecheckedSource :: FilePath -> IO TypecheckedSource unfortunately, when I compile and run it, I get the dreaded: Bug: Bug: panic! (the 'impossible' happened) (GHC version 7.0.3 for i386-unknown-linux): placeHolderNames Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Turns out that the problem is when the file contains a type annotation. That is, ./Bug Test00.hs crashes, when Test00.hs is: module Test where x :: Int x = 0 but does not crash when the file is: module Test where x = 0 Can anyone tell me why listify chokes in the latter case? (And how one might get around the problem?) I include the full source below (compiled with: ghc --make Bug, using ghc 7.0.3) Thanks! Ranjit. ------------------------------------------------------------------------------------------------------ import GHC import Outputable import DynFlags (defaultDynFlags) import GHC.Paths (libdir) import System.Environment (getArgs) import Control.Monad import qualified Data.List as L import Data.Data import Data.Generics.Schemes (listify) main = do fname <- (!! 0) `fmap` getArgs tcm <- loadTypecheckedSource fname putStrLn $ showPpr tcm -- this works fine putStrLn $ showPpr $ allIds tcm -- this causes the crash return () allIds :: Data a => a -> [Id] allIds = listify (\x -> case (x :: Id) of _ -> True) loadTypecheckedSource :: FilePath -> IO TypecheckedSource loadTypecheckedSource fname = defaultErrorHandler defaultDynFlags $ runGhc (Just libdir) $ do df <- getSessionDynFlags setSessionDynFlags df tgt <- guessTarget fname Nothing setTargets [tgt] load LoadAllTargets res <- load LoadAllTargets if failed res then pprPanic "Load Failed!!" (text "AAARGH!") else tm_typechecked_source `fmap` getTypecheckedModule fname findModSummary :: GhcMonad m => FilePath -> m ModSummary findModSummary fname = do msums <- depanal [] False case L.find ((fname ==) . ms_hspp_file) msums of Just msum -> return msum Nothing -> pprPanic "ModuleName Lookup Failed!!" (text "AARGHC!") getTypecheckedModule :: GhcMonad m => FilePath -> m TypecheckedModule getTypecheckedModule = findModSummary >=> parseModule >=> typecheckModule

2 2

getCPUTime implementation incorrect?
by Evan Laforge 07 Jun '11

07 Jun '11

I've just noticed that getCPUTime is returning erratic results for me: GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Loading package filepath-1.2.0.0 ... linking ... done. Prelude> :m System.CPUTime Prelude System.CPUTime> getCPUTime 9696631700340362000000 Prelude System.CPUTime> getCPUTime 1333572622260398592000000 Prelude System.CPUTime> getCPUTime 21577331579851694000000 Prelude System.CPUTime> getCPUTime 21577331579861838000000 Prelude System.CPUTime> getCPUTime 1061231477620269514000000 Prelude System.CPUTime> getCPUTime 9965140170836829000000 This is ghc 7.0.3, OS X 10.6.7, and it's the x86_64 version downloaded from http://www.haskell.org/ghc/download_ghc_7_0_3 So, I looked at the CPUTime.hsc source in the base library, and it uses CTime to get tv_sec and tv_usec fields from the struct timeval. Unfortunately, and I never knew this, tv_usec is not time_t, but is suseconds_t. On my OS X, these are different types: time_t is 64 bits but suseconds_t is 32 bits. After writing my own getCPUTime that uses Int32 for tv_usec it's back to working again. But the proper way to do this is probably to introduce CSUSeconds (I'm guessing it stands for signed microseconds), which I guess means editing the autoconfig to put a new define in HsBaseConfig.h. I dont know anything about autoconfig, but it's probably easy enough for someone is :)

2 2

Compiling 32-bit GHC on a 64-bit Mac
by Johan Tibell 06 Jun '11

06 Jun '11

Hi, I need to reproduce a bug that only appears on 32-bit machines. I don't own such a machine but I was hoping I could compile a 32-bit GHC on my Mac and debug using that. What changes do I need to make (e.g. to build/mk) to build a 32-bit GHC? Cheers, Johan

3 3

ANNOUNCE: GHC 7.0.4 Release Candidate 1
by Ian Lynagh 04 Jun '11

04 Jun '11

We are pleased to announce the first release candidate for GHC 7.0.4: http://www.haskell.org/ghc/dist/7.0.4-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Release notes: * A floating point regression in 7.0.3 affecting x86 has been fixed (#5149). * The GHCi linker now handles partially stripped object files (#5004). This fixes loading the ghc package in ghci when it's been stripped, which is often the case in Linux distribution packages. * A runtime system bug with large heaps has been fixed (#5086). * A runtime system bug when heap profiling has been fixed (#5127). * A runtime system bug when heap profiling has been fixed (#5127). * A runtime system bug, which caused incorrect results and segfaults when using FFI callbacks, has been fixed. * A runtime system bug, which occasionally caused parallel programs to <<loop>> when using -feager-blackholing, has been fixed (#5226). * Incorrect directory permissions when installing have been fixed (#4982). * Some improvements have been made to the new Cabal testsuite support. * Cabal is now 1.10.2.0 (was 1.10.1.0). Thanks Ian, on behalf of the GHC team

2 1

Re: ld weirdness in unstable
by Joachim Breitner 02 Jun '11

02 Jun '11

Dear Joey, strange observation... for more eyes looking at it, I’m replying with full-quote to the GHC mailing list as well. (That list is subscriber-only, AFAIK, in case you want to follow up there). Am Mittwoch, den 01.06.2011, 19:09 -0400 schrieb Joey Hess: > I've noticed this problem with ld process size recently while doing > edit-compile-debug development cycles with git-annex on unstable. > > Normally, ld runs in seconds, using maybe 170 mb or memory according to > top, but I suspect real memory is somewhat less. > > Sometimes I get into a state where every link takes minutes, and > apparently uses somewhat more memory and typically triggers the OOM > killer. > > Whenever this happens, I have to `make clean; make` and then it seems > back to normal. > > The build is being driven by ghc --make. And the best way to trigger it > seems to be to make changes to types, or other changes to core > modules that cause a fan-out effect where ghc needs to rebuild lots of > other modules. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

Addr# field in ForeignPtr
by Roman Leshchinskiy 01 Jun '11

01 Jun '11

Hi all, GHC defines ForeignPtr as: data ForeignPtr a = ForeignPtr Addr# ForeignPtrContents -- we cache the Addr# in the ForeignPtr object, but attach -- the finalizer to the IORef (or the MutableByteArray# in -- the case of a MallocPtr). The aim of the representation -- is to make withForeignPtr efficient; in fact, withForeignPtr -- should be just as efficient as unpacking a Ptr, and multiple -- withForeignPtrs can share an unpacked ForeignPtr. Note -- that touchForeignPtr only has to touch the ForeignPtrContents -- object, because that ensures that whatever the finalizer is -- attached to is kept alive. Is it ok to modify the Addr# field? Or do the libraries assume that it always points to the start of the block described by ForeignPtrContents? Changing the Addr# field would be quite useful for pointing to the middle of a memory block. For instance, Storable vectors are currently defined as: data Vector a = Vector {-# UNPACK #-} !(Ptr a) {-# UNPACK #-} !Int {-# UNPACK #-} !(ForeignPtr a) If I could use the Addr# field of the ForeignPtr, I could get rid of the Ptr. Alternatively, I could define my own version of ForeignPtr if only ForeignPtrContents was exported (abstractedly would be enough). Roman

2 1

testsuite, failures galore
by Daniel Fischer 01 Jun '11

01 Jun '11

So my last testsuite run (validate --slow) with a new HEAD produced 651 unexpected failures :( Okay, the thing is that I forgot to add EXTRA_HC_OPTS=-optl-lz, see http://hackage.haskell.org/trac/ghc/ticket/3756 So, unless I miscounted, 611 of those were in way threaded1 due to: > Linking arrowrun001 ... > /usr/lib/gcc/i586-suse-linux/4.5/../../../libbfd.a(compress.o): In > function `bfd_uncompress_section_contents': > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:96:0: > undefined reference to `inflateInit_' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:106:0: > undefined reference to `inflateReset' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:103:0: > undefined reference to `inflate' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:108:0: > undefined reference to `inflateEnd' > > collect2: ld gab 1 als Ende-Status zurück > > *** unexpected failure for arrowrun001(threaded1) The ticket has low priority, but if anybody has an idea how to check whether libbfd depends on libz in the configure script, I'd appreciate it. Of the remaining 40 unexpected failures, 14 were due to the removal of datatype contexts (tcrun006 and tcrun029), 7 (tcrun007) were due to a parse error because -XGenerics does nothing anymore (so ghc couldn't parse "{|"), 3 due to a missing Show instance in dph. The remaining may or may not be serious, looking at them now.

3 10

Manipulating DynFlags importPaths
by Joshua Ball 31 May '11

31 May '11

Hi, What's the right way to alter the importPaths in the DynFlags? The following program freezes: -- requires ghc package import GHC import DynFlags ( defaultDynFlags ) main = defaultErrorHandler defaultDynFlags $ do runGhc (Just "/home/jball/lib/ghc-7.0.3") $ do dflags <- getSessionDynFlags let dflags = dflags { importPaths = ["/alt/path"] } setSessionDynFlags dflags I am using ghc 7.0.3, as you might have guessed. Josh "Ua" Ball

1 1

shared libraries on OS X
by John Lato 28 May '11

28 May '11

Hello, I recently tried to build ghc on OS X Snow Leopard as 64-bit with shared library support. I had to self-compile gmp and modify mk/build.mk (I later saw that Edward Amsden blogged about the same experience, http://blog.edwardamsden.com/2011/04/howto-install-ghc-703-on-os-x-64-bit.h…) and it seemed to work, but executables don't run. For example, with this small program: > import qualified Data.Vector.Unboxed as V > main = let vec = V.replicate 10 (1 :: Int) in print $ V.sum vec I get this result: Mac-1:~ johnlato$ ghc -O -dynamic foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... Mac-1:~ johnlato$ ./foo dyld: Library not loaded: /private/var/folders/aJ/aJF0t1uBF7WDCz1PZV0A0U+++TI/-Tmp-/vector-0.7.0.176669/vector-0.7.0.1/dist/build/libHSvector-0.7.0.1-ghc7.0.3.dylib Referenced from: /Users/johnlato/./foo Reason: image not found Trace/BPT trap It seems that dyld is looking into build folders for the libraries. If I set DYLD_LIBRARY_PATH before compiling it appears to work: Mac-1:~ johnlato$ export DYLD_LIBRARY_PATH=~/.cabal/lib/vector-0.7.0.1/ghc-7.0.3/:~/.cabal/lib/primitive-0.3.1/ghc-7.0.3/ Mac-1:~ johnlato$ ghc -O -dynamic foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... Mac-1:~ johnlato$ ./foo 10 This seems to be required for any libraries I've installed via cabal-install --user, which quickly becomes onerous. Could anyone give me some advice on how to make this work properly (e.g. without manually setting DYLD_LIBRARY_PATH)? Thanks, John

1 0