January 2013 - ghc-devs

RE: Syntax error in perf/should_run/all.T
by Simon Peyton-Jones 21 Jan '13

21 Jan '13

That's odd. It validated for me... maybe those tests aren't run. Anyway, there was a missing paren, now fixed. Apologies Simon | -----Original Message----- | From: Edward Z. Yang [mailto:ezyang@MIT.EDU] | Sent: 18 January 2013 21:29 | To: Simon Peyton-Jones | Cc: ghc-devs(a)haskell.org | Subject: Syntax error in perf/should_run/all.T | | Looks like this hunk is not quite correct: | | commit 52234dfedb9ad07585271f33513fb2c9e5012e1a | Author: Simon Peyton Jones <simonpj(a)microsoft.com> | Date: Thu Jan 17 13:52:35 2013 +0000 | | Adjust performance bounds slightly | | diff --git a/tests/perf/should_run/all.T b/tests/perf/should_run/all.T | index 08ff230..cdb8852 100644 | --- a/tests/perf/should_run/all.T | +++ b/tests/perf/should_run/all.T | @@ -227,9 +227,10 @@ test('T5536', | 1250000000)), | # expected value: 1246287228 (i386/Linux) | if_wordsize(64, | - stats_num_field('bytes allocated', 2480000000, | - 2510000000)), | - # expected value: 2492589480 (amd64/Linux) | + stats_range_field('bytes allocated', 892399040, 5), | + # expected value: 2,492,589,480 | (amd64/Linux) | + # 17/1/13: 892,399,040 | (x86_64/Linux) | + # (new demand analyser) | | The file now syntax errors for me. | | Edward

1 0

Handling in Android in Cabal
by Nathan Hüsken 20 Jan '13

20 Jan '13

Hey, I was just looking into how to add support to detect android as the OS in Cabal. I found this comment: --TODO: decide how to handle Android and iOS. -- They are like Linux and OSX but with some differences. -- Should they be separate from linux/osx, or a subtype? -- e.g. should we have os(linux) && os(android) true simultaneously? I want to add android to the list of os known by cabal because I need to switch on it in the cabal file of haskeline to get it compiled on android. But I would think that most of the time the same settings that work for linux also work for android. So my vote would be to make android a "subtype" of linux. Regards, Nathan

1 0

Re: [commit: ghc] master: Tidy up cross-compiling (109a1e5)
by Simon Marlow 20 Jan '13

20 Jan '13

On 17/01/13 14:00, Simon Peyton-Jones wrote: > Would it be worth transferring that comment into the building guide (a cross-compiling page perhaps). The distinction is subtle and the information is useful > > There is http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation > but I'm not sure it has this info Oh yes, I plan to fix the wiki. It needs more than just an update for this change though... the CrossCompilation page is really a design document, not a user guide, we need some proper documentation. Cheers, Simon > Simon > > | -----Original Message----- > | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- > | bounces(a)haskell.org] On Behalf Of Simon Marlow > | Sent: 17 January 2013 12:57 > | To: ghc-commits(a)haskell.org > | Subject: [commit: ghc] master: Tidy up cross-compiling (109a1e5) > | > | Repository : ssh://darcs.haskell.org//srv/darcs/ghc > | > | On branch : master > | > | http://hackage.haskell.org/trac/ghc/changeset/109a1e53287f50103e8a5b5922 > | 75940b6e3dbb53 > | > | >--------------------------------------------------------------- > | > | commit 109a1e53287f50103e8a5b592275940b6e3dbb53 > | Author: Simon Marlow <marlowsd(a)gmail.com> > | Date: Thu Jan 17 11:52:15 2013 +0000 > | > | Tidy up cross-compiling > | > | We have two cases: > | 1. building a cross-compiler > | 2. compiling GHC to run on a foreign platform > | > | These two are done with almost the same setup: (1) is the stage 1 > | compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES. > | > | The only difference between (1) and (2) is that you if you set up > | the > | build for (1), then it stops before stage 2 and you can 'make > | install' > | to install stage 1. > | > | Unfortunately, (2) didn't work, and the build system code needed > | some > | tidying up. > | > | Change to the way the build is set up: > | > | Before > | ------ > | > | To build a cross-compiler: > | ./configure --target=<..> > | > | To compile a foreign GHC: > | ./configure --host=<..> --target=<..> > | > | Now > | --- > | > | To build a cross-compiler: > | ./configure --target=<..> > | And set "Stage1Only=YES" in mk/build.mk > | > | To compile a foreign GHC: > | ./configure --target=<..> > | > | aclocal.m4 | 28 ++++++++---- > | compiler/ghc.mk | 99 ++++++++++++++++++++---------------- > | ------ > | configure.ac | 35 ++++----------- > | ghc.mk | 10 ++-- > | ghc/ghc.mk | 2 +- > | libraries/primitive | 1 - > | libraries/vector | 1 - > | mk/config.mk.in | 27 +++++++----- > | rules/build-package-data.mk | 7 +++- > | settings.in | 1 + > | utils/ghc-pkg/ghc.mk | 4 +- > | 11 files changed, 107 insertions(+), 108 deletions(-) > | > | > | Diff suppressed because of size. To see it, use: > | > | git show 109a1e53287f50103e8a5b592275940b6e3dbb53 > | > | _______________________________________________ > | ghc-commits mailing list > | ghc-commits(a)haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-commits >

2 9

[PATCH] do not use CLK_TCK on Solaris host
by Karel Gardas 19 Jan '13

19 Jan '13

This patch fixes Solaris cross-compilation issue as CLK_TCK is not constant on Solaris and hsc2hs chokes on it when cross-compiling from i386-solaris to x86_64-solaris. --- System/CPUTime.hsc | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/System/CPUTime.hsc b/System/CPUTime.hsc index 8934a7e..270fd13 100644 --- a/System/CPUTime.hsc +++ b/System/CPUTime.hsc @@ -39,7 +39,7 @@ import CPUTime ( getCPUTime, cpuTimePrecision ) #ifdef __GLASGOW_HASKELL__ import Foreign.Safe import Foreign.C -#if !defined(CLK_TCK) +#if !defined(CLK_TCK) || solaris2_HOST_OS import System.IO.Unsafe (unsafePerformIO) #endif @@ -187,7 +187,10 @@ cpuTimePrecision = round ((1000000000000::Integer) % fromIntegral (clockTicks)) #ifdef __GLASGOW_HASKELL__ clockTicks :: Int clockTicks = -#if defined(CLK_TCK) +-- CLK_TCK is no longer a constant on Solaris so avoid to use it +-- this way. In fact it's defined in a way like syscall below in +-- Solaris' <time.h> +#if defined(CLK_TCK) && ! solaris2_HOST_OS (#const CLK_TCK) #else unsafePerformIO (sysconf (#const _SC_CLK_TCK) >>= return . fromIntegral) -- 1.7.3.2

2 2

[PATCH 2/2] do not use timer_create function on Solaris OS
by Karel Gardas 18 Jan '13

18 Jan '13

--- rts/posix/Itimer.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/rts/posix/Itimer.c b/rts/posix/Itimer.c index 80b3b56..b99ff89 100644 --- a/rts/posix/Itimer.c +++ b/rts/posix/Itimer.c @@ -73,6 +73,24 @@ * etc.). */ +#if defined(solaris2_HOST_OS) +/* USE_TIMER_CREATE is usually disabled for Solaris. In fact it is + supported well on this OS, but requires additional privilege. When + user does not have it, then the testing configure program fails + which results in USE_TIMER_CREATE not defined. + On the other hand when we cross-compile, then we optimistically + assume usage of timer_create function. The problem is that if we + cross compile for example from i386-solaris2 to x86_64-solaris2, + then the build fails with error like this: + +ghc-stage2: timer_create: Not owner + + which happens on first ghc-stage2 invocation. So to support + cross-compilation to Solaris we manually undefine USE_TIMER_CREATE + here */ +#undef USE_TIMER_CREATE +#endif /* solaris2_HOST_OS */ + #if defined(USE_TIMER_CREATE) # define ITIMER_SIGNAL SIGVTALRM #elif defined(HAVE_SETITIMER) -- 1.7.3.2

1 0

[PATCH 1/2] fix rts/Linker compilation issues on AMD64/Solaris platform
by Karel Gardas 18 Jan '13

18 Jan '13

--- rts/Linker.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/rts/Linker.c b/rts/Linker.c index fa1de89..b97a30c 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -4088,6 +4088,7 @@ ocResolve_PEi386 ( ObjectCode* oc ) #elif defined(x86_64_HOST_ARCH) # define ELF_TARGET_X64_64 # define ELF_64BIT +# define ELF_TARGET_AMD64 /* Used inside <elf.h> on Solaris 11 */ #elif defined(powerpc64_HOST_ARCH) # define ELF_64BIT #endif -- 1.7.3.2

1 0

Massive detabbing of the source
by Jan Stolarek 18 Jan '13

18 Jan '13

I thought I could clean up the source code from all the tabs and then remove {-# OPTIONS -fno-warn-tabs #-} pragmas + comment below it. This is a massive change though (140 files would be affected) and I suspect it could potentially be a problem to others working on the source (could cause some merge problems). So, can I just proceed with cleaning up all those 140 files and then send a single patch or should I devide this task into smaller ones (e.g. a single patch for every directory in the $(TOP)/compiler/) or should I just give up on this idea? Janek

6 10

validate failures
by Simon Marlow 17 Jan '13

17 Jan '13

Lots of validate failures today (x86-64/Linux): Unexpected failures: indexed-types/should_compile Gentle [exit code non-0] (normal) perf/compiler T5030 [stat not good enough] (normal) polykinds T6068 [bad stderr] (ghci) rename/should_fail rnfail055 [stderr mismatch] (normal) typecheck/should_compile tc235 [exit code non-0] (normal) typecheck/should_fail T5684 [stderr mismatch] (normal) Many of them seem to be of this kind: + Illegal instance declaration for `HasSingleton + (Maybe ak) (Maybe a) mp' + Multiple uses of this instance may be inconsistent + with the functional dependencies of the class. + In the instance declaration for `HasSingleton (Maybe a) mp' Anyone know why this is? Cheers, Simon

3 2

HEAD build fails on OS X
by Johan Tibell 17 Jan '13

17 Jan '13

Hi, I'm currently getting the following failure on OS X: rts_dist_HC rts/dist/build/sm/GCAux.thr_o In file included from rts/sm/GC.c:25:0: rts/sm/GCUtils.h: In function ‘recordMutableGen_GC’: rts/sm/GCUtils.h:55:0: error: ‘gctKey’ undeclared (first use in this function) rts/sm/GCUtils.h:55:0: error: (Each undeclared identifier is reported only once rts/sm/GCUtils.h:55:0: error: for each function it appears in.) make[1]: *** [rts/dist/build/sm/GC.thr_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 I wonder if 520dc1d245fa5d965bdc7e97231e868de7c1dd9e, which moved around some includes in that directory, is to blame. -- Johan

2 6

Re: time submodule not accepting patches
by Ian Lynagh 17 Jan '13

17 Jan '13

On Mon, Jan 14, 2013 at 12:23:31PM +0000, José Pedro Magalhães wrote: > > I cannot push any patch to the time submodule of the GHC repo. For > instance, creating > a new branch succeeds locally, and succeeds in pushing, but the branch is > never created > on the remote. Also, no commit email is generated. Could this be fixed? Ah, its post-update hook wasn't enabled. Does it work now? Thanks Ian

2 1