- ghc-devs - Haskell.org

Vector primops sizes
by Michael Baikov 14 Feb '13

14 Feb '13

Recently merged vector primops support only 16 bytes operands - Int32 x 4, Double x 2 and so on. Current AVX instructions support 256 bit operands and with simple cut'n'paste work it's possible to support at least Double x 4 operands. I made those changes and GHC generates (using llvm) proper AVX code using ymm registers. Also it might make sense to support primops for vector types larger than any currently supported primitive types - I have those changes in my branch as well and llvm generates pretty good code as well - those changes might be useful to provide access for llvm shufflevector instruction or writing high performance processing of large vectors - with less potential overhead. Do we want to support larger vectors directly or ghc should be made smart enough to fuse operations with vector primops performed in parallel into larger vectors/registers for llvm? Do we want to provide access to llvm shufflevector instruction?

5 7

[PATCH] base: use --target as target, not uname
by Sergei Trofimovich 14 Feb '13

14 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Fixed bootstrap failure on linux for --target=mingw32 Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- configure.ac | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b679520..7553a7a 100644 --- a/configure.ac +++ b/configure.ac @@ -5,17 +5,23 @@ AC_CONFIG_SRCDIR([include/HsBase.h]) AC_CONFIG_HEADERS([include/HsBaseConfig.h include/EventConfig.h]) +AC_CANONICAL_BUILD +AC_CANONICAL_HOST +AC_CANONICAL_TARGET + AC_ARG_WITH([cc], [C compiler], [CC=$withval]) AC_PROG_CC() -case `uname -s` in - MINGW*|CYGWIN*) +AC_MSG_CHECKING(for WINDOWS platform) +case $host in + *mingw32*|*cygwin*) WINDOWS=YES;; *) WINDOWS=NO;; esac +AC_MSG_RESULT($WINDOWS) # do we have long longs? AC_CHECK_TYPES([long long]) -- 1.8.1.2

3 4

[PATCH] Fix comment to use correct option name
by shelarcy 14 Feb '13

14 Feb '13

Hello, Source Code Comments decribe wrong (old) option name in two place. I made patch to fix that. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

2 1

[PATCH] hsc2hs: use configuration of current compiler, not built
by Sergei Trofimovich 13 Feb '13

13 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Fixed bootstrap failure on linux for --target=mingw32 of such kind: "/usr/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -static -H32m -O -w -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.0 -package containers-0.5.0.0 -package directory-1.2.0.0 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/Paths_hsc2hs.o utils/hsc2hs/dist/build/Main.o: In function `s4cN_info': (.text+0x182): undefined reference to `GetModuleFileNameW' Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- Main.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Main.hs b/Main.hs index 30b3a2d..5309179 100644 --- a/Main.hs +++ b/Main.hs @@ -11,7 +11,7 @@ -- See the documentation in the Users' Guide for more details. #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) -#include "../../includes/ghcconfig.h" +#include "ghcconfig.h" #endif import Control.Monad ( liftM, forM_ ) -- 1.8.1.1

2 2

Re: GHC 7.8 release?
by Simon Marlow 13 Feb '13

13 Feb '13

On 13/02/13 07:06, wren ng thornton wrote: > On 2/12/13 3:37 AM, Simon Marlow wrote: >> One reason for the major version bumps is that base is a big >> conglomeration of modules, ranging from those that hardly ever change >> (Prelude) to those that change frequently (GHC.*). For example, the new >> IO manager that is about to get merged in will force a major bump of >> base, because it changes GHC.Event. The unicode support in the IO >> library was similar: although it only added to the external APIs that >> most people use, it also changed stuff inside GHC.* that we expose for a >> few clients. >> >> The solution to this would be to split up base further, but of course >> doing that is itself a major upheaval. However, having done that, it >> might be more feasible to have non-API-breaking releases. > > While it will lead to much wailing and gnashing of teeth in the short > term, if it's feasible to break GHC.* off into its own package, then I > think we should. The vast majority of base seems quite stable or else is > rolling along at a reasonable pace. And yet, every time a new GHC comes > out, there's a new wave of fiddling the knobs on cabal files because > nothing really changed. On the other hand, GHC.* moves rather quickly. > Nevertheless, GHC.* is nice to have around, so we don't want to just > hide that churning. The impedance mismatch here suggests that they > really should be separate packages. I wonder whether GHC.* should be > moved in with ghc-prim, or whether they should remain separate... > > But again, this depends on how feasible it would be to actually split > the packages apart. Is it feasible? So I think we'd need to add another package, call it ghc-base perhaps. The reason is that ghc-prim sits below the integer package (integer-simple or integer-gmp). It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. In fact, maybe you want to do it exactly like this for simplicity - all the code goes in ghc-base. There would be some impact on compilation time, as we'd have twice as many interfaces to read. I believe Ian has done some experiments with splitting base further, so he might have more to add here. Cheers, Simon

5 4

Re: [commit: ghc] master: add $(CrossCompilePrefix) to hp2ps (#7639) (b0fad0c)
by Gabor Greif 13 Feb '13

13 Feb '13

Hi Simon, all, this reminds me of a local patch (see below), that allows one to keep different 'build.mk' customizations for cross targets and normal builds at the same time, so the error-prone manual swapping of these is automated. OK to push? Cheers, Gabor ##################################################### [ggreif-hc_stm-r6.0][!1180] git show b716a1132010cccbf87612b4c1b0816c0585eb91 commit b716a1132010cccbf87612b4c1b0816c0585eb91 Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Nov 23 17:54:00 2012 +0100 allow different customizations per cross target diff --git a/mk/custom-settings.mk b/mk/custom-settings.mk index e64bb36..3390888 100644 --- a/mk/custom-settings.mk +++ b/mk/custom-settings.mk @@ -5,7 +5,7 @@ ifeq "$(Validating)" "YES" include mk/validate-settings.mk -include mk/validate.mk else --include mk/build.mk +-include mk/$(CrossCompilePrefix)build.mk endif ifeq "$(BINDIST)" "YES" On 2/1/13, Simon Marlow <marlowsd(a)gmail.com> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/b0fad0c580e0dd52d73743a877608… > >>--------------------------------------------------------------- > > commit b0fad0c580e0dd52d73743a877608af60408ec89 > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Thu Jan 31 12:05:03 2013 +0000 > > add $(CrossCompilePrefix) to hp2ps (#7639) > >>--------------------------------------------------------------- > > utils/hp2ps/ghc.mk | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/utils/hp2ps/ghc.mk b/utils/hp2ps/ghc.mk > index 59791c8..097f912 100644 > --- a/utils/hp2ps/ghc.mk > +++ b/utils/hp2ps/ghc.mk > @@ -16,7 +16,7 @@ utils/hp2ps_dist_C_SRCS = AreaBelow.c Curves.c > Error.c Main.c \ > Axes.c Dimensions.c Key.c PsFile.c > Shade.c \ > Utilities.c > utils/hp2ps_dist_EXTRA_LIBRARIES = m > -utils/hp2ps_dist_PROG = hp2ps$(exeext) > +utils/hp2ps_dist_PROG = $(CrossCompilePrefix)hp2ps$(exeext) > utils/hp2ps_dist_INSTALL = YES > utils/hp2ps_dist_INSTALL_INPLACE = YES > > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 5

RE: [GHC] #7631: Allow to differentiate between newtypes and datatypes when using Generics
by Simon Peyton-Jones 13 Feb '13

13 Feb '13

Thanks for fixing Pedro Our usual test-case nomenclature would be to use "T7631" as the test name. Not worth changing now. Simon | -----Original Message----- | From: ghc-tickets-bounces(a)haskell.org [mailto:ghc-tickets-bounces@haskell.org] | On Behalf Of GHC | Sent: 13 February 2013 10:44 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #7631: Allow to differentiate between newtypes and | datatypes when using Generics | | #7631: Allow to differentiate between newtypes and datatypes when using | Generics | ---------------------------------+------------------------------------------ | Reporter: Feuerbach | Owner: dreixel | Type: feature request | Status: closed | Priority: normal | Component: libraries (other) | Version: 7.7 | Resolution: fixed | Keywords: generics | Os: Unknown/Multiple | Architecture: Unknown/Multiple | Failure: None/Unknown | Blockedby: | Blocking: | Related: | | ---------------------------------+------------------------------------------ | Changes (by dreixel): | | * status: new => closed | * resolution: => fixed | | | Comment: | | Done. New test is `GenNewtype`. | | -- | Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7631#comment:4> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0

Re: RFC: Singleton equality witnesses
by Gabor Greif 13 Feb '13

13 Feb '13

Richard and all, sorry for reviving such an ancient thread, but I'd like to move this forward a bit :-) In the meantime Iavor has added the (:~:) GADT, so I can reuse it. It has been commented that it could (finally) end up in GHC.Exts, but for now I want my changes minimized. I have added the class @SingEquality@ and have implemented the @sameSing@ method in terms of Iavor's functions. This is rather pretty now. Here is the patch: ------------------------------------------------------ $ git show 0eacf265255b9c5e0191b6a5100f3076b8eb5520 commit 0eacf265255b9c5e0191b6a5100f3076b8eb5520 Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Nov 30 12:23:28 2012 +0100 Introduce the SingEquality class with customizable witness type and a sameSing method that may produce the latter. diff --git a/GHC/TypeLits.hs b/GHC/TypeLits.hs index f8b759e..5546a5a 100644 --- a/GHC/TypeLits.hs +++ b/GHC/TypeLits.hs @@ -30,7 +30,7 @@ module GHC.TypeLits , type (-) -- * Comparing for equality - , type (:~:) (..), eqSingNat, eqSingSym + , type (:~:) (..), eqSingNat, eqSingSym, SingEquality (..) -- * Destructing type-nat singletons. , isZero, IsZero(..) @@ -56,6 +56,7 @@ import Unsafe.Coerce(unsafeCoerce) -- import Data.Bits(testBit,shiftR) import Data.Maybe(Maybe(..)) import Data.List((++)) +import Control.Monad (guard, return, (>>)) -- | (Kind) A kind useful for passing kinds as parameters. data OfKind (a :: *) = KindParam @@ -133,6 +134,11 @@ class (kparam ~ KindParam) => SingE (kparam :: OfKind k) where type DemoteRep kparam :: * fromSing :: Sing (a :: k) -> DemoteRep kparam +class (kparam ~ KindParam, SingE (kparam :: OfKind k)) => SingEquality (kparam :: OfKind k) where + type SameSing kparam :: k -> k -> * + type SameSing kparam = (:~:) + sameSing :: Sing a -> Sing b -> Maybe (SameSing kparam a b) + instance SingE (KindParam :: OfKind Nat) where type DemoteRep (KindParam :: OfKind Nat) = Integer fromSing (SNat n) = n @@ -141,6 +147,12 @@ instance SingE (KindParam :: OfKind Symbol) where type DemoteRep (KindParam :: OfKind Symbol) = String fromSing (SSym s) = s +instance SingEquality (KindParam :: OfKind Nat) where + sameSing = eqSingNat + +instance SingEquality (KindParam :: OfKind Symbol) where + sameSing = eqSingSym + {- | A convenient name for the type used to representing the values for a particular singleton family. For example, @Demote 2 ~ Integer@, and also @Demote 3 ~ Integer@, but @Demote "Hello" ~ String@. -} ------------------------------------------------------ Regarding Richard's decidable equality suggestion, I think this would be the next step. IIRC, empty case expressions have been implemented, so GHC HEAD should be prepared. What do you think? Okay to push in this form? Cheers, Gabor On 12/5/12, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > I don't think anything here is *high priority*, just musings on how best to > move forward. > > About empty case, consider this: > >> data a :~: b where >> Refl :: a :~: a >> >> absurd :: True :~: False -> a > > Now, I want to write a term binding for absurd. GHC can figure out that > (True :~: False) is an empty type. So, if we have (absurd x = case x of …), > there are no valid patterns, other than _, that could be used. Instead of > writing (absurd _ = undefined), I would much prefer to write (absurd x = > case x of {}). Why? If I compile with -fwarn-incomplete-patterns and > -Werror, then the latter has no possible source of partiality and yet > compiles. The former looks dangerous, and GHC doesn't check to make sure > that, in fact, the function can never get called. > > The bottom line, for me at least, is that I want to avoid the partial > constructs (incomplete patterns, undefined, etc) in Haskell as much as > possible, especially when I'm leveraging the type system to a high degree. > The lack of empty case statements forces me to use undefined where it isn't > really necessary. > > I'll leave it to others to comment on TypeRep, as I'm a little hazy there > myself. > > Richard > >

5 14

[PATCH] GHC_CONVERT_VENDOR: allow 'w64' vendor, like x86_64-w64-mingw32
by Sergei Trofimovich 12 Feb '13

12 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Gentoo calls 'w64' a mingw flavour with mingw-w64 runtime. Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- aclocal.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aclocal.m4 b/aclocal.m4 index 9f9593a..30d492c 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -1812,7 +1812,7 @@ case "$1" in # converts vendor from gnu to ghc naming, and assigns the result to $target_var AC_DEFUN([GHC_CONVERT_VENDOR],[ case "$1" in - pc|gentoo) # like i686-pc-linux-gnu and i686-gentoo-freebsd8 + pc|gentoo|w64) # like i686-pc-linux-gnu, i686-gentoo-freebsd8, x86_64-w64-mingw32 $2="unknown" ;; softfloat) # like armv5tel-softfloat-linux-gnueabi -- 1.8.1.1

2 1

RE: GHC 7.8 release?
by Simon Peyton-Jones 12 Feb '13

12 Feb '13

(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. These must be social questions (what I was earlier calling “signposting”) rather than technical ones. For example, you say that (b) is not subject to any variety of reason, and yet no linux distribution tracks HEAD, does it? They don’t openly insult anyone who points to a release just because HEAD has new cool stuff! No, they track things we call “releases”. Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP. Or something. I’m just looking for a way to reconcile · Release early, release often · Stability for the Haskell Platform It seems to me that such a reconciliation is within reach, and is actually very close to what we do, if we only signpost what is what far more vigorously and clearly than we do now. But maybe I’m wrong. Simon From: Brandon Allbery [mailto:allbery.b@gmail.com] Sent: 11 February 2013 01:15 To: Simon Peyton-Jones Cc: Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; kostirya(a)gmail.com; glasgow-haskell-users; ghc-devs(a)haskell.org; Edsko de Vries Subject: Re: GHC 7.8 release? On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: What causes the "wave of package updates"? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. (a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason. It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com<mailto:allbery.b@gmail.com> ballbery(a)sinenomine.net<mailto:ballbery@sinenomine.net> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

8 9