- ghc-devs - Haskell.org

Pattern synonyms for 7.8?
by Dr. ERDI Gergo 29 Jan '14

29 Jan '14

Hi, When I started working on pattern synonyms (#5144) back in August, it seemed the GHC 7.8 freeze was imminent, so I was planning for a first version in 7.10/8.0 (whatever it will be called). However, since not much has happened re: 7.8 since then (at least not much publicly visible), and on the other hand, my implementation of pattern synonyms is ready, I am now starting to wonder if it could be squeezed into 7.8. What are your thoughts on this? Thanks, Gergo

11 13

Re: 7.8 branch is created, HEAD is now open, and a note on merges
by Kazu Yamamoto 29 Jan '14

29 Jan '14

Austin, > For the record, this error occurs fairly late in the ./validate script > - it's for testing the in-place binary distribution after a build, but > before the testsuite is run. In the mean time, you can just do 'cd > testsuite && make fast' to run all your tests after you have seen this > error. I simply do not have a sensible, easy fix right now. OK. I understand. P.S. I obtained Mac pro. Building and validating GHC on Mac pro are very quick. So, if necessary, please feel free to ask me to check building or validating GHC on Mac anytime. --Kazu

3 3

fPIC issues
by Jan Stolarek 28 Jan '14

28 Jan '14

A couple of days ago I realized that I can't compile latest HEAD on my Debian Squeeze laptop. Some -fPIC issues prevented compilation of integer-gmp library. I reported this as #8666. Today I got another PIC-related error on a different machine with openSUSE 11.4: /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: dist/build/compile/compile-tmp/Data/Singletons/Core.dyn_o: re location R_X86_64_PC32 against undefined symbol `DataziSingletonsziTypes_Proved_con_info' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status This happened with HEAD when I tried to compile testsuite configured via cabal file (on 7.6.3 all is fine): test-suite compile type: exitcode-stdio-1.0 ghc-options: -Wall -O0 -main-is Test.Main default-language: Haskell2010 main-is: Test/Main.hs Before I fil in another bug report could someone offer me a straightforward explanation of what is this whole -fPIC thing? Why does it break my code? Is this a known issue? Is there any kind of workaround for this? Janek

3 4

GHC API: Using runGhc twice or from multiple threads?
by Benno Fünfstück 26 Jan '14

26 Jan '14

Hello, is the following safe to do? main = do runGhc libdir $ do ... runGhc libdir $ do ... Or will this cause trouble? Is there state that is shared between the two calls? And what about this one: main = do forkIO $ runGhc libdir $ do ... forkIO $ runGhc libdir $ do ...

4 5

Re: [commit: ghc] master: Fix more 32 bit performance fallout. (c5088e2)
by Simon Marlow 24 Jan '14

24 Jan '14

On 22/01/14 23:32, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/c5088e299a66109346057afc151c33e47… > >> --------------------------------------------------------------- > > commit c5088e299a66109346057afc151c33e47b850b92 > Author: Austin Seipp <austin(a)well-typed.com> > Date: Wed Jan 22 17:30:54 2014 -0600 > > Fix more 32 bit performance fallout. > > Some of these are actually worse than I thought upon inspection, but > after a little digging I haven't found exactly what has caused them. > Some were certainly bitrotted, but others seem updated more recently, so > something has slipped. > > I'll be filing a ticket about these. Please do! These look very bad indeed. Cheers, Simon

1 1

Re: A modest proposal (re the Platform)
by Jens Petersen 24 Jan '14

24 Jan '14

On 20 January 2014 17:29, Andres Löh <andres.loeh(a)gmail.com> wrote: > (2) Simply because GHC 7.8 is itself so long delayed and so full of > new features, I think it's realistic to assume that quite a few > library glitches will appear even after it's released. Also, GHC bugs > may be found only after formal release (despite all the hammering, the > use of GHC pre release isn't quite comparable with the amount of > testing it gets afterwards; IMHO, there might very well be need for a > GHC 7.8.2). I'm all for trying to get an HP based on GHC 7.8 out as > possible, but how soon would that actually happen, realistically? > I know I already said "+1" but this is also a very valid standpoint. I guess the question is how long does HP want to wait for a stable ghc-7.8 release? There were already a number of important library updates planned for the HP release with ghc-7.6.3 - doing things more incrementally is also good I believe. Also as Andres mentioned in view of Mavericks. I know it is difficult but if ghc and haskell-platform could align their schedules better then things might be easier to plan in the future. Jens

4 5

feedback on adding CPP program / flags to ghc settings file patch please :) (it works now!)
by Carter Schonwald 23 Jan '14

23 Jan '14

Hey all, the patch for augmenting the ghc settings file to help decouple CPP from the C Compiler choice now works, on both the configure/autconf and ghc builds and uses it correctly fronts! It also results in removing the cRAWCPP variable from Config.hs, which I think is a good thing! (removes a hack / potential source of cruft). I'd love some feedback/ suggestions for this patch please. I'd also like to thank Peter Trommler for helping me debug / fix up my incorrect m4/autoconf component of the patch. the point of this patch is to make it very easy to provide a GHC that by default uses a different program for "Haskell CPP" than for compiling C code (which can only be done currently via a wrapper script hack thats a bit fragile, or via passing -pgmP everywhere! ) *https://ghc.haskell.org/trac/ghc/ticket/8683#comment:11 <https://ghc.haskell.org/trac/ghc/ticket/8683#comment:11>* thanks -Carter

1 0

32-bit Linux perf numbers
by Mateusz Kowalczyk 23 Jan '14

23 Jan '14

Hi, I just ran validate on 32-bit Linux with the latest HEAD. Here's the end of the log: > Unexpected results from: > TEST="T1969 haddock.Cabal haddock.base" > > OVERALL SUMMARY for test run started at Thu Jan 23 13:35:12 2014 GMT > 0:18:40 spent to go through > 3881 total tests, which gave rise to > 15164 test cases, of which > 11619 were skipped > > 28 had missing libraries > 3456 expected passes > 58 expected failures > > 3 caused framework failures > 0 unexpected passes > 3 unexpected failures > > Unexpected failures: > perf/compiler T1969 [stat not good enough] (normal) > perf/haddock haddock.Cabal [stat not good enough] (normal) > perf/haddock haddock.base [stat not good enough] (normal) I think that the Haddock numbers were adjusted recently (and no further changes have been made to Haddock since) but it seems that it was not enough. T1969 also seems to need inspection: should I be filing a bug for that? You can see the full log at http://fuuzetsu.co.uk/misc/validate23012014 Perhaps there should be a separate thread about this but what's happening with the nightly builds that would catch these? The builds have been stopped for months now and it doesn't seem like they'll ever resume at this rate. I can offer a 32-bit Linux box to run a validate build daily if finding the machines to build on is a problem. Thanks -- Mateusz K.

1 0

m4 / autconf help? (WIP patch for improving the CPP sitch)
by Carter Schonwald 22 Jan '14

22 Jan '14

Hey all, I"ve a WIP patch https://ghc.haskell.org/trac/ghc/ticket/8683 for making it easy to separately specify the CPP program command and associated flags in the ghc settings file. The haskell code part, for handling the dynflags / parsing the settings file etc tests out fine, i'm a bit stumped on how to get autoconf /m4 to work correctly for instantiating the desired values into the settings.intemplate though! (which happens at configure time) any help / wisdom? thanks! -Carter

1 0

Re: [commit: ghc] master: Add Windows to NoSharedLibsPlatformList (4af1e76)
by kyra 21 Jan '14

21 Jan '14

Does this mean we have no 64-bit windows support for 7.8 (only dynamic-linked compiler works on 64-bit windows)? On 1/13/2014 10:28, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3fb1394dd… > >> --------------------------------------------------------------- > commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d > Author: Austin Seipp <austin(a)well-typed.com> > Date: Mon Jan 13 00:21:18 2014 -0600 > > Add Windows to NoSharedLibsPlatformList > > We're punting on full -dynamic and -dynamic-too support for Windows > right now, since it's still unstable. Also, ensure "Support dynamic-too" > in `ghc --info` is set to "NO" for Cabal. > > See issues #7134, #8228, and #5987 > > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >> --------------------------------------------------------------- > 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d > compiler/main/DynFlags.hs | 4 +++- > mk/config.mk.in | 19 ++++--------------- > 2 files changed, 7 insertions(+), 16 deletions(-) > > diff --git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs > index 06d1ed9..734e7e9 100644 > --- a/compiler/main/DynFlags.hs > +++ b/compiler/main/DynFlags.hs > @@ -3563,7 +3563,7 @@ compilerInfo dflags > ("Support SMP", cGhcWithSMP), > ("Tables next to code", cGhcEnableTablesNextToCode), > ("RTS ways", cGhcRTSWays), > - ("Support dynamic-too", "YES"), > + ("Support dynamic-too", if isWindows then "NO" else "YES"), > ("Support parallel --make", "YES"), > ("Dynamic by default", if dYNAMIC_BY_DEFAULT dflags > then "YES" else "NO"), > @@ -3574,6 +3574,8 @@ compilerInfo dflags > ("LibDir", topDir dflags), > ("Global Package DB", systemPackageConfig dflags) > ] > + where > + isWindows = platformOS (targetPlatform dflags) == OSMinGW32 > > #include "../includes/dist-derivedconstants/header/GHCConstantsHaskellWrappers.hs" > > diff --git a/mk/config.mk.in b/mk/config.mk.in > index f61ecc0..59d48c4 100644 > --- a/mk/config.mk.in > +++ b/mk/config.mk.in > @@ -94,22 +94,11 @@ else > TargetElf = YES > endif > > -# Currently, on Windows, we artificially limit the unfolding creation > -# threshold to minimize the number of exported symbols on Windows > -# platforms in the stage2 DLL. This avoids a hard limit of 2^16 > -# exported symbols in the windows dynamic linker. > -# > -# This is a pitifully low threshold (the default is 750,) but it > -# reduced the symbol count by about ~7,000, bringing us back under the > -# limit (for now.) > -# > -# See #5987 > -ifeq "$(TargetOS_CPP)" "mingw32" > -GhcStage2HcOpts += -funfolding-creation-threshold=100 > -endif > - > # Some platforms don't support shared libraries > -NoSharedLibsPlatformList = arm-unknown-linux powerpc-unknown-linux > +NoSharedLibsPlatformList = arm-unknown-linux \ > + powerpc-unknown-linux \ > + x86_64-unknown-mingw32 \ > + i386-unknown-mingw32 > > ifeq "$(SOLARIS_BROKEN_SHLD)" "YES" > NoSharedLibsPlatformList += i386-unknown-solaris2 > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 7