- ghc-devs - Haskell.org

Re: [commit: ghc] master: Build fix for dyn way on Windows; patch from nus (c39d315)
by Bill Tutt 17 Feb '13

17 Feb '13

On Sat, Feb 16, 2013 at 5:04 PM, Ian Lynagh <igloo(a)earth.li> wrote: > diff --git a/rts/Prelude.h b/rts/Prelude.h > index dcd7b94..89e80a0 100644 > --- a/rts/Prelude.h > +++ b/rts/Prelude.h > @@ -93,6 +93,7 @@ PRELUDE_INFO(base_GHCziStable_StablePtr_con_info); > > #define runSparks_closure > DLL_IMPORT_DATA_REF(base_GHCziConcziSync_runSparks_closure) > #define ensureIOManagerIsRunning_closure > DLL_IMPORT_DATA_REF(base_GHCziConcziIO_ensureIOManagerIsRunning_closure) > +#define ioManagerCapabilitiesChanged_closure > DLL_IMPORT_DATA_REF(base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure) > #define runHandlers_closure > DLL_IMPORT_DATA_REF(base_GHCziConcziSignal_runHandlers_closure) > > #define flushStdHandles_closure > DLL_IMPORT_DATA_REF(base_GHCziTopHandler_flushStdHandles_closure) > > diff --git a/rts/Schedule.c b/rts/Schedule.c > index f39ef96..ea779dd 100644 > --- a/rts/Schedule.c > +++ b/rts/Schedule.c > @@ -2070,7 +2070,7 @@ setNumCapabilities (nat new_n_capabilities > USED_IF_THREADS) > // Notify IO manager that the number of capabilities has changed. > rts_evalIO( > &cap, > - &base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure, > + > DLL_IMPORT_DATA_REF(base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure), > NULL); > Shouldn't this use the new #define you added to Prelude.h just above? This bit in rts\Win32\ThrIOManager.c should also use the Prelude.h macro: #if defined(COMPILING_WINDOWS_DLL) # if defined(x86_64_HOST_ARCH) rts_evalIO(&cap,__imp_base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL); # else rts_evalIO(&cap,_imp__base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL); # endif #else rts_evalIO(&cap,&base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL); #endif Bill

2 1

validate failure due to haddock
by Andreas Voellmy 16 Feb '13

16 Feb '13

Hi, I just ran ./sync-all pull and ran validate on Linux. I got the following error, apparently due to something missing in haddock: "/home/andi/temp/ghc-build/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock-prologue.txt" --optghc=-static --optghc=-H32m --optghc=-O --optghc=-Werror --optghc=-Wall --optghc=-H64m --optghc=-O0 --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-O --optghc=-dcore-lint --optghc=-fno-warn-deprecated-flags --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hisuf --optghc=hi --optghc=-osuf --optghc=o --optghc=-hcsuf --optghc=hc libraries/ghc-prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 78% ( 7 / 9) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /338) in 'GHC.PrimopWrappers' 30% (160 /527) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: /home/andi/temp/ghc-build/inplace/lib/html/Ocean.std-theme/ocean.css: copyFile: does not exist (No such file or directory) make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1 make[1]: *** Deleting file `libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock' make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 -Andi

1 0

Re: Heads-up: new parallel I/O manager merged
by Bill Tutt 16 Feb '13

16 Feb '13

Yes, it should. Here's the combined patch that just succeded in being built. Bill On Sat, Feb 16, 2013 at 11:26 AM, Andreas Voellmy <andreas.voellmy(a)gmail.com > wrote: > > > in rts/ThrIOManager.hs >> > > Sorry, this should have been rts/win32/ThrIOManager.c. >

1 0

Re: [commit: ghc] master: Find LLVM tools when version number at end (e.g., llc-3.0) (#7661) (64aaaa1)
by Ian Lynagh 16 Feb '13

16 Feb '13

On Wed, Feb 13, 2013 at 07:11:11PM -0800, David Terei wrote: > > +AC_DEFUN([FIND_LLVM_PROG],[ > + FP_ARG_WITH_PATH_GNU_PROG_OPTIONAL([$1], [$2], [$3]) > + if test "$1" == ""; then > + GOOD_PATH=`echo $PATH | tr ':,;' ' '` Hmm. I don't think we'll ever have a $PATH containing a path like c:/..., but there could certainly be paths containing spaces. > + $1=`${FindCmd} ${GOOD_PATH} -type f -perm +111 -maxdepth 1 -regex '.*/$3-[[0-9]]\.[[0-9]]' | ${SortCmd} -n | tail -1` This feels rather unpleasant to me. Is it likely that someone will have programs called llc-3.0 etc, but no llc? If not, I'd suggest that we just detect llc and they can override which llc gets used with a --with-llc flag if they want to. In fact, i think we should do that regardless. After all, we don't try searching for gcc-4.6 etc either. Thanks Ian

2 1

GHC failing to build due to errors in DPH?
by Iavor Diatchki 15 Feb '13

15 Feb '13

Hello, I am trying to build GHC head and get the following error: libraries/dph/dph-lifted-base/Data/Array/Parallel/PArray/Reference.hs:50:11: Ambiguous occurrence `fromList' It could refer to either `Data.Array.Parallel.PArray.Reference.fromList', defined at libraries/dph/dph-lifted-base/Data/Array This is using the stage 2 compiler and, I am guessing, is due to an interaction with the overloaded lists extension. I just deleted dph completely, and used `sync-all get` to get a fresh copy, but I get the same error. It looks like the nightly builds are working, so am I doing something wrong? More generally, I don't really need DPH, so is there an easy way to disable building it? -Iavor

5 4

RE: GHC failing to build due to errors in DPH?
by Simon Peyton-Jones 15 Feb '13

15 Feb '13

Sorry about that... I don’t know haw my validate worked. Anyway all good. Simon From: Ian Lynagh Sent: ‎15‎ ‎February‎ ‎2013 ‎20‎:‎10 To: Iavor Diatchki CC: ghc-devs(a)haskell.org Subject: Re: GHC failing to build due to errors in DPH? On Fri, Feb 15, 2013 at 11:09:33AM -0800, Iavor Diatchki wrote: > > I am trying to build GHC head and get the following error: > > libraries/dph/dph-lifted-base/Data/Array/Parallel/PArray/Reference.hs:50:11: > Ambiguous occurrence `fromList' > It could refer to either > `Data.Array.Parallel.PArray.Reference.fromList', > defined at > libraries/dph/dph-lifted-base/Data/Array I've just pushed a fix for this. Thanks Ian _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

RE: OverloadedLists
by Simon Peyton-Jones 15 Feb '13

15 Feb '13

| Finally I managed to build again (don't know what's wrong with my | system, I built on a virtual machine instead now), and the tests pass. I | attached the four patches, they were created with git diff --no-prefix, | and their name specifies the submodule they are to be applied to. I hope | it isn't to late to include them in 7.8. Should I publish them somewhere | else also, or is this fine? Great. It's done! Thanks for all your work on this. Would you like to update the wiki page? http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists You probably don't want to mention your repo any more; and please just check the rest to make sure it's accurate. I did quite a bit of refactoring, especially to the type checking of arithmetic sequences, which had lots of duplication; fixed the documentation which was out of date; fixed various error message changes in the main testsuite; and committed. Simon commit 3234a4ade7204c4206831b4c1dc4a8b23624cc6b Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu Feb 14 13:04:14 2013 +0000 Add OverloadedLists, allowing list syntax to be overloaded This work was all done by Achim Krause <achim.t.krause(a)gmail.com> George Giorgidze <giorgidze(a)gmail.com> Weijers Jeroen <jeroen.weijers(a)uni-tuebingen.de> It allows list syntax, such as [a,b], [a..b] and so on, to be overloaded so that it works for a variety of types. The design is described here: http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists Eg. you can use it for maps, so that [(1,"foo"), (4,"bar")] :: Map Int String The main changes * The ExplicitList constructor of HsExpr gets witness field * Ditto ArithSeq constructor * Ditto the ListPat constructor of HsPat Everything else flows from this. compiler/deSugar/Check.lhs | 15 ++-- compiler/deSugar/Coverage.lhs | 16 +++- compiler/deSugar/DsArrows.lhs | 2 +- compiler/deSugar/DsExpr.lhs | 42 +++++++---- compiler/deSugar/DsMeta.hs | 7 +- compiler/deSugar/Match.lhs | 31 ++++++-- compiler/hsSyn/Convert.lhs | 6 +- compiler/hsSyn/HsExpr.lhs | 12 ++- compiler/hsSyn/HsPat.lhs | 12 ++- compiler/hsSyn/HsUtils.lhs | 6 +- compiler/main/DynFlags.hs | 2 + compiler/parser/Parser.y.pp | 12 ++-- compiler/parser/RdrHsSyn.lhs | 4 +- compiler/prelude/PrelNames.lhs | 26 ++++++- compiler/prelude/TysWiredIn.lhs | 2 +- compiler/rename/RnEnv.lhs | 18 +++-- compiler/rename/RnExpr.lhs | 45 +++++++---- compiler/rename/RnPat.lhs | 21 ++++- compiler/typecheck/TcExpr.lhs | 111 ++++++++++++++++---------- compiler/typecheck/TcHsSyn.lhs | 30 ++++++-- compiler/typecheck/TcHsType.lhs | 2 +- compiler/typecheck/TcPat.lhs | 14 +++- compiler/typecheck/TcRnDriver.lhs | 2 +- compiler/typecheck/TcRnTypes.lhs | 2 + compiler/utils/Outputable.lhs | 4 +- docs/users_guide/flags.xml | 7 ++ docs/users_guide/glasgow_exts.xml | 157 +++++++++++++++++++++++++++++++++++++ 27 files changed, 469 insertions(+), 139 deletions(-)

4 5

Re: [commit: ghc] master: Find LLVM tools when version number at end (e.g., llc-3.0) (#7661) (64aaaa1)
by Ian Lynagh 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 07:21:54PM +0100, Karel Gardas wrote: > On 02/15/13 07:03 PM, Ian Lynagh wrote: > >>+ $1=`${FindCmd} ${GOOD_PATH} -type f -perm +111 -maxdepth 1 -regex '.*/$3-[[0-9]]\.[[0-9]]' | ${SortCmd} -n | tail -1` > > > >This feels rather unpleasant to me. Is it likely that someone will have > >programs called llc-3.0 etc, but no llc? > > Yes, Ubuntu 12.04 LTS installs LLVM 3.0 package in a way that, the > package binaries are installed into /usr/lib/llvm-3.0 directory and > inside /usr/bin there are llc-3.0 and opt-3.0 links created linking > to ../lib/llvm-3.0/bin/{llc|opt}. > > So David is fixing real-world issue here. But if you install 'llvm' (rather than 'llvm-3.0') then you get a /usr/bin/llc Analogously, on ubuntu, if you install 'gcc' then you get /usr/bin/gcc, but if you install 'gcc-4.6' then you get /usr/bin/gcc-4.6; but we don't search for gcc-* executables. Thanks Ian

2 1

Re: [commit: ghc] simd: Fixup stack spills when generating AVX instructions. (b787b5d)
by David Terei 15 Feb '13

15 Feb '13

Do we have a longer term solution for this? I love the SIMD work, so please don't take this as a complaint, I agree with getting it done for now with the mangler and truth is it's doubtful we'll et around to adding TNTC support to LLVM anytime soon, so mangler is here to stay for now. BUT. I would like to see some thought about how in an ideal world with lots of free time to hack on GHC we'd kill the mangler. Do we know that plan for this patch? If so it may be nice to document it somewhere and perhaps create a trac ticket. On 14 February 2013 23:16, Geoffrey Mainland <gmainlan(a)microsoft.com> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : simd > > http://hackage.haskell.org/trac/ghc/changeset/b787b5d1e687fb28643cdd6a847cc… > >>--------------------------------------------------------------- > > commit b787b5d1e687fb28643cdd6a847ccc26bb014a79 > Author: Geoffrey Mainland <gmainlan(a)microsoft.com> > Date: Sat Nov 26 12:45:23 2011 +0000 > > Fixup stack spills when generating AVX instructions. > > LLVM uses aligned AVX moves to spill values onto the stack, which requires > 32-bye aligned stacks. Since the stack in only 16-byte aligned, LLVM inserts > extra instructions that munge the stack pointer. This is very very bad for the > GHC calling convention, so we tell LLVM to assume the stack is 32-byte > aligned. This patch rewrites the spill instructions that LLVM generates so they > do not require an aligned stack. > >>--------------------------------------------------------------- > > compiler/llvmGen/LlvmMangler.hs | 38 ++++++++++++++++++++++++++++++++++++++ > 1 files changed, 38 insertions(+), 0 deletions(-) > > diff --git a/compiler/llvmGen/LlvmMangler.hs b/compiler/llvmGen/LlvmMangler.hs > index 83a2be7..745dcc6 100644 > --- a/compiler/llvmGen/LlvmMangler.hs > +++ b/compiler/llvmGen/LlvmMangler.hs > @@ -20,6 +20,10 @@ import System.IO > import Data.List ( sortBy ) > import Data.Function ( on ) > > +#if x86_64_TARGET_ARCH > +#define REWRITE_AVX > +#endif > + > -- Magic Strings > secStmt, infoSec, newLine, textStmt, dataStmt, syntaxUnified :: B.ByteString > secStmt = B.pack "\t.section\t" > @@ -47,6 +51,7 @@ llvmFixupAsm dflags f1 f2 = {-# SCC "llvm_mangler" #-} do > w <- openBinaryFile f2 WriteMode > ss <- readSections r w > hClose r > + let fixed = (map rewriteAVX . fixTables) ss > let fixed = fixTables ss > mapM_ (writeSection w) fixed > hClose w > @@ -90,6 +95,39 @@ writeSection w (hdr, cts) = do > B.hPutStrLn w hdr > B.hPutStrLn w cts > > +#if REWRITE_AVX > +rewriteAVX :: Section -> Section > +rewriteAVX = rewriteVmovaps . rewriteVmovdqa > + > +rewriteVmovdqa :: Section -> Section > +rewriteVmovdqa = rewriteInstructions vmovdqa vmovdqu > + where > + vmovdqa, vmovdqu :: B.ByteString > + vmovdqa = B.pack "vmovdqa" > + vmovdqu = B.pack "vmovdqu" > + > +rewriteVmovap :: Section -> Section > +rewriteVmovap = rewriteInstructions vmovap vmovup > + where > + vmovap, vmovup :: B.ByteString > + vmovap = B.pack "vmovap" > + vmovup = B.pack "vmovup" > + > +rewriteInstructions :: B.ByteString -> B.ByteString -> Section -> Section > +rewriteInstructions matchBS replaceBS (hdr, cts) = > + (hdr, loop cts) > + where > + loop :: B.ByteString -> B.ByteString > + loop cts = > + case B.breakSubstring cts matchBS of > + (hd,tl) | B.null tl -> hd > + | otherwise -> hd `B.append` replaceBS `B.append` > + loop (B.drop (B.length matchBS) tl) > +#else /* !REWRITE_AVX */ > +rewriteAVX :: Section -> Section > +rewriteAVX = id > +#endif /* !REWRITE_SSE */ > + > -- | Reorder and convert sections so info tables end up next to the > -- code. Also does stack fixups. > fixTables :: [Section] -> [Section] > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

Advice needed: programmatically generating primops?
by Geoffrey Mainland 15 Feb '13

15 Feb '13

Hi All, There is a huge amount of boilerplate involved in adding a full complement of vector primops to GHC. I would like to reduce this boilerplate by programmatically generating the vector primops. My plan is to add utils/genvecprimops and #include its output into primops.txt.pp. Does this sound reasonable? Any objections? While I'm at it, is there any related cleanup I could undertake? Thanks, Geoff

5 6