April 2014 - ghc-devs

update "latest" user manual
by Richard Eisenberg 22 Apr '14

22 Apr '14

Hi devs, I’m not sure who is responsible for this (Austin? Herbert?), but http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html links to v7.8.1, though 7.8.2 is available. We should update. Thanks, Richard

3 3

Strange behaviour in my signum
by Alexander Berntsen 21 Apr '14

21 Apr '14

I started preparing patches for #7858. My abs patch works well, my signum patch not at all. The gist of the bug is that abs and signum return erroneous values for for the input -0.0. abs (-0.0 :: Float) should return 0.0, not -0.0. My patch fixes this. For signum the situation is reverse. My patch does *not* fix this. It does not work using GHC nor GHCi (GHCi -ddump-simpl demonstrated below). The code for my signum is correct, as may be demonstrated by putting signumFix x | x == 0.0 = x | isNaN x = x | x > 0.0 = 1 | otherwise = negate 1 in a file signumfix.hs and :l signumfix.hs into GHCi. signumFix (-0.0 :: Float) should now return -0.0, where signum returns 0.0 with the same argument. Following this email come the patches. Please review the second patch. If you can spot what I am doing wrong, I would be grateful. Prelude> abs (-0.0 :: Float) ==================== Simplified expression ==================== let { it_aqt :: GHC.Types.Float [LclId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] it_aqt = GHC.Num.abs @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Num.negate @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aqt) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_aqt `cast` (UnivCo representational GHC.Types.Float () :: GHC.Types.Float ~# ())) (GHC.Types.[] @ ()))) 0.0 Prelude> signum (-0.0 :: Float) ==================== Simplified expression ==================== let { it_aKQ :: GHC.Types.Float [LclId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] it_aKQ = GHC.Num.signum @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Num.negate @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aKQ) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_aKQ `cast` (UnivCo representational GHC.Types.Float () :: GHC.Types.Float ~# ())) (GHC.Types.[] @ ()))) 0.0 Alexander Berntsen (2): Make Prelude.abs handle -0.0 correctly (#7858) Make Prelude.signum handle -0.0 correctly (#7858) libraries/base/GHC/Float.lhs | 28 ++++++++++++++++++---------- libraries/base/changelog.md | 2 ++ 2 files changed, 20 insertions(+), 10 deletions(-) -- 1.8.3.2

2 3

RE: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for validate (6074c5d)
by Simon Peyton Jones 21 Apr '14

21 Apr '14

There is much more to change, right? * The code in the compiler that implements -fwarn-amp * Actually making Applicative a superclass of monad Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 20 April 2014 07:02 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for | validate (6074c5d) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/6074c5da7f48f10e9b3b88d14607e | c4955735931/ghc | | >--------------------------------------------------------------- | | commit 6074c5da7f48f10e9b3b88d14607ec4955735931 | Author: Austin Seipp <austin(a)well-typed.com> | Date: Sun Apr 20 01:00:44 2014 -0500 | | Remove -fno-warn-amp sledgehammers for validate | | GHC should now fully compliant with respect to the Applicative | Monad | proposal (including all upstream libraries), and does not need to | suppress this warning anymore. | | Signed-off-by: Austin Seipp <austin(a)well-typed.com> | | | >--------------------------------------------------------------- | | 6074c5da7f48f10e9b3b88d14607ec4955735931 | mk/validate-settings.mk | 2 -- | 1 file changed, 2 deletions(-) | | diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index | 8797bf9..cac938d 100644 | --- a/mk/validate-settings.mk | +++ b/mk/validate-settings.mk | @@ -32,7 +32,6 @@ SRC_HC_OPTS += $(WERROR) -Wall | | GhcStage1HcOpts += -fwarn-tabs | GhcStage2HcOpts += -fwarn-tabs | -GhcStage2HcOpts += -fno-warn-amp # Temporary sledgehammer until we | sync upstream. | | utils/hpc_dist-install_EXTRA_HC_OPTS += -fwarn-tabs | | @@ -46,7 +45,6 @@ GhcStage2HcOpts += -O -dcore-lint # running of the | tests, and faster building of the utils to be installed | | GhcLibHcOpts += -O -dcore-lint | -GhcLibHcOpts += -fno-warn-amp # Temporary sledgehammer until we | sync upstream. | | # We define DefaultFastGhcLibWays in this style so that the value is | # correct even if the user alters DYNAMIC_GHC_PROGRAMS. | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

RE: [commit: ghc] master: Deprecate the AMP warnings. (3608f65)
by Simon Peyton Jones 21 Apr '14

21 Apr '14

I think we can go further: we can remove the code that implements -fwarn-amp. I agree that the flag itself should remain for a cycle, deprecated, as a no-op. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 20 April 2014 22:56 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Deprecate the AMP warnings. (3608f65) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/3608f657d55b7ea7dd711556a4faf | 6a15c509163/ghc | | >--------------------------------------------------------------- | | commit 3608f657d55b7ea7dd711556a4faf6a15c509163 | Author: Austin Seipp <austin(a)well-typed.com> | Date: Sun Apr 20 01:10:15 2014 -0500 | | Deprecate the AMP warnings. | | Now that we're in development mode, Applicative will soon be a | superclass of Monad in HEAD. So let's go ahead and deprecate the | -fno-warn-amp flag, remove the checks, and tweak a few tests | | Signed-off-by: Austin Seipp <austin(a)well-typed.com> | | | >--------------------------------------------------------------- | | 3608f657d55b7ea7dd711556a4faf6a15c509163 | compiler/main/DynFlags.hs | 4 +- | compiler/typecheck/TcRnDriver.lhs | 215 +----------- | -------- | docs/users_guide/flags.xml | 2 +- | .../tests/ghci.debugger/scripts/break006.stderr | 4 +- | .../tests/ghci.debugger/scripts/print019.stderr | 2 +- | .../should_fail/overloadedlistsfail01.stderr | 2 +- | testsuite/tests/rename/should_compile/T7145b.hs | 3 - | .../tests/rename/should_compile/T7145b.stderr | 2 +- | .../tests/simplCore/should_compile/spec001.hs | 3 +- | .../tests/typecheck/should_compile/holes2.stderr | 2 +- | testsuite/tests/typecheck/should_fail/T5095.stderr | 2 - | .../tests/typecheck/should_fail/tcfail072.stderr | 2 +- | .../tests/typecheck/should_fail/tcfail133.stderr | 2 +- | .../tests/typecheck/should_fail/tcfail181.stderr | 1 - | 14 files changed, 14 insertions(+), 232 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 3608f657d55b7ea7dd711556a4faf6a15c509163 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

Heap usage of GHC increased in 7.8 vs. 7.6
by Simon Marlow 19 Apr '14

19 Apr '14

I noticed that T1969 is failing again, and decided to do a little investigation. The maximum residency when compiling T1969 with HEAD compared with 7.6.3 looks like this: 7.6.3: 10,473,920 HEAD: 13,783,536 This is with +RTS -h -i0.01 to avoid sampling errors as much as possible. The figures are pretty accurate, and the heap profiles confirm it: we're using a lot more heap now. -ddump-if-trace shows that HEAD is reading more interface files: Renamer stats: 10 interfaces read 6 type/class/variable imported, out of 1361 read 0 instance decls imported, out of 105 read 0 rule decls imported, out of 53 read vs. with 7.6.3: Renamer stats: 8 interfaces read 2 type/class/variable imported, out of 828 read 0 instance decls imported, out of 40 read 0 rule decls imported, out of 45 read The extra interface files are Control.Applicative and Control.Monad. So the question is, why are we now reading these on *every* compilation? (T1969 imports only the Prelude). Presumably this is something to do with the AMP warnings, but can't we lazily load these interfaces when they're needed? Cheers, Simon

3 4

Proposal - Foreign enum support
by Merijn Verstraaten 19 Apr '14

19 Apr '14

Cross-post to haskell-prime in case there's any interest for including this into the report's FFI specification. Proposal - Foreign enum support =============================== At the moment the FFI does not have a convenient way with interacting enums (whether proper enums or CPP defines) in C (like languages). Both enums and CPP defined enums are major parts of large C APIs and they are thus crucial to writing foreign bindings. A few examples: SDL_image defines the following enum: typedef enum { IMG_INIT_JPG = 0x00000001, IMG_INIT_PNG = 0x00000002, IMG_INIT_TIF = 0x00000004, IMG_INIT_WEBP = 0x00000008 } IMG_InitFlags; OpenCL specifies the following typedefs + CPP defined enum: typedef uint32_t cl_uint __attribute__((aligned(4))); typedef cl_uint cl_platform_info; /* cl_platform_info */ #define CL_PLATFORM_PROFILE 0x0900 #define CL_PLATFORM_VERSION 0x0901 #define CL_PLATFORM_NAME 0x0902 #define CL_PLATFORM_VENDOR 0x0903 #define CL_PLATFORM_EXTENSIONS 0x0904 OpenCL functions will return the above CPP defines as return values of type cl_platform_info. Current Solutions ----------------- In many cases someone wrapping such a C library would like to expose these enums as a simple sum type as this has several benefits: type safety, the ability to use haskell constructors for pattern matching, exhaustiveness checks. Currently the GHC FFI, as specified by Haskell2010, only marshalls a small set of foreign types and newtypes with exposed constructors of these types. As such there seem two approaches to wrap these enums: 1. Implement an ADT representing the enum and write a manual conversion function between the ADT and the corresponding C type (e.g. CInt -> Foo and Foo -> CInt). 2. Use a tool like c2hs to automatically generate the ADT and conversion function. In both cases the foreign functions are imported using the corresponding C type in their signature (reducing type safety) and the user is forced write trivial wrappers for every imported function to convert the ADT to the relevant C type and back. This is both tedious to write and costly in terms of code produced, in case of c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for every argument/result even though this could trivially be a no-op. Worse, since c2hs uses the Enum class for it's conversion to/from C types it generates Enum instances like: instance Enum Foo where fromEnum Bar = 1 fromEnum Baz = 1337 toEnum 1 = Bar toEnum 1337 = Baz toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ show unmatched) Since succ/pred and enumFromTo's default implementations assume enums convert to continuous sequence of Int this means the default generated enum instances crash. This problem could be overcome by making c2hs' code generation smarter, but this does not eliminate the tediousness of wrapping all foreign imported functions with marshalling wrappers, NOR does it eliminate the overhead of all this useless marshalling. Proposal -------- Add a new foreign construct for enums, the syntax I propose below is rather ugly and ambiguous and thereforeopen to bikeshedding, but I prefer explaining based on a concrete example. foreign enum CInt as Foo where Bar = 1 Baz Quux = 1337 Xyzzy = _ This would introduce a new type 'Foo' with semantics approximately equivalent too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo 1; pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _". Explicit listing of the value corresponding to a constructor should be optional, missing values should just increment by one from the previous (like C), if the initial value is missing, it should assume to start from 0. Values do not need to be contiguous. Users should be able to use these constructors as normal in pattern match (really, this mostly follows to semantics of the above pattern synonyms). The foreign import/export functionality should invisibly marshall Foo to the underlying foreign type (as is done for newtypes). I'm unsure about the support for a wildcard constructor like Xyzzy. If there is support for a wildcard, it should be optional. On the upside a wildcard means the marshalling is no longer a partial function. The downside is that it makes desugaring the use of enums in patterns harder. It seems clear that f Xyzzy = {- ... -} f Bar = {- ... -} f Baz = {- ... -} f Quux = {- ... -} Should not have the same semantics as: f (Foo _) = {- ... -} f (Foo 1) = {- ... -} f (Foo 2) = {- ... -} f (Foo 1337) = {- ... -} So in the presence of wildcards, the Foo enum can't trivially be desugared into pattern synonyms after checking exhaustiveness. Pros: 1. Foreign imports are slightly more type safe, as one can now write: foreign import ccall "someFoo.h" someFoo :: Foo -> Ptr () -> IO () Preventing users from passing an arbitrary CInt to an argument expecting a specific enum. 2. No need to write marshalling functions to/from ADT to obtain exhaustiveness checks and pattern matching 3. Cheaper as marshalling Foo to CInt is a no-op 4. toEnum/fromEnum can simply map to contiguous sequence of Int as this Int mapping is no longer used for marshalling Cons: 1. Non-standard extension of the FFI 2. Someone has to implement it 3. Wildcards constructors would present difficulties desugaring pattern matches to a simple newtype. 4. ?? What Would Need to be Done? --------------------------- 1. Parser needs to be extended to deal with parsing of enum declarations. 2. Pattern matches of an enum type need to be checked for exhaustiveness and desugared to the underlying type's representation. 3. Extend foreign imports/exports to marshall enums properly. If there's no objections I'm willing to take a stab at implementing this, although I'd probably need some help with GHC's internals (although I could bug #ghc for that). Cheers, Merijn

5 6

Cannot locally 'sync-all get'
by Daniel Fischer 19 Apr '14

19 Apr '14

Like so often, ./sync-all pull failed today in my local clones, first with "... not on a branch", after sync-all checkout master, with "fatal: Reference ... not a tree". (Aside, that nonsense didn't happen before the introduction of submodules.) The usual remedy is rm -rf ./clone git clone ./ghc ./clone cd clone ./sync-all get but today it failed with > Klone nach 'libraries/xhtml'... > Fertig. > Unterprojekt-Pfad: 'libraries/xhtml': > 'fb9e0bbb69e15873682a9f25d39652099a3ccac1' ausgecheckt fatal: Projektarchiv > '/home/dafis/GHC/./haddock.git' existiert nicht. Klonen von > '/home/dafis/GHC/./haddock.git' in Unterprojekt-Pfad 'utils/haddock' > fehlgeschlagen git failed: 256 at ./sync-all line 123. Any idea what's up? Cheers, Daniel

2 2

RE: OverloadedRecordFields
by Simon Peyton Jones 18 Apr '14

18 Apr '14

Adam I'm very happy to hear that... good stuff. I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day. So I suggest we plan to merge after 7.8 is out. Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense Simon | -----Original Message----- | From: Adam Gundry [mailto:adam@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | > Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | > | > Simon | > | > | -----Original Message----- | > | From: Adam Gundry [mailto:adam@well-typed.com] | > | Sent: 17 January 2014 10:15 | > | To: Simon Peyton Jones | > | Subject: OverloadedRecordFields | > | | > | Hi Simon, | > | | > | I'm conscious that things have gone off the boil a little wrt | > | OverloadedRecordFields, partially as a consequence of the delayed | > | 7.8 release but also my lack of time for other projects since | > | starting work for Well-Typed. With that in mind, I'd like to propose | > | a plan to get back on track: | > | | > | 1. Revert to the three-parameter story, where we have | > | | > | t ~ FldTy r f => Has r f t | > | | > | rather than | > | | > | Has r f. | > | | > | The two-parameter version generates significantly worse error | > | messages, and there are some other unresolved problems, so I'm not | > | sure it is worth the minor simplification. | > | | > | 2. Roll back some of the refactoring that I've struggled to get | > | right (in particular, trying to make the generated FldTy/UpdTy | > | axioms implicitTyThings). We can always revisit this in the future | though. | > | | > | 3. Merge HEAD into my branch: I suspect this will be a bit painful | > | by now, but presumably with 7.8 imminent there won't be many major | > | changes coming for a while? | > | | > | 4. Review the proposed changes with you and fix any show-stopping | > | problems. | > | | > | 5. Merge into HEAD after 7.8 is released. | > | | > | Does this sound plausible? I'm happy to Skype if you like. | > | | > | Cheers, | > | | > | Adam | > | | > | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but | > | Neil Ghani has got me some funding to work with them both on units | > | of measure for Haskell. We are still sorting out the details, but I | > | hope it might be possible to work on some kind of plugin mechanism | > | for GHC's constraint solver, along the lines that Iavor has been | > | investigating, if that would be of interest? | > | | > | -- | > | Adam Gundry, Haskell Consultant | > | Well-Typed LLP, http://www.well-typed.com/ | > | | | -- | Adam Gundry, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/

4 4

strip related failure [was: Re: solaris-x86-head (Solaris/x86 HEAD (Karel Gardas)), build 32, Failure]
by Karel Gardas 18 Apr '14

18 Apr '14

Folks, last two/three builds on Solaris builder fails due to a reason that someone added (probably) stripping of installed libraries. My bet is on 8992d5269804b727fb77249511e89df678526907 -- hence ccing you Herbert, but I'm not sure... The problem is that invoked strip command line is incompatible with Solaris' strip which then fails with: strip: --strip-unneeded: cannot open file: No such file or directory the problem is usage of --strip-unneeded command-line argument? It looks like this argument is supported by just GNU strip. Do we really need to use it? If not, removing this may solve the issue. If yes, then I'll need to come with some workaround for Solaris... Detailed log of failure is at the bottom of http://haskell.inf.elte.hu/builders/solaris-x86-head/32/20.html Thanks! Karel On 04/18/14 05:03 AM, Builder wrote: > solaris-x86-head (Solaris/x86 HEAD (Karel Gardas)), build 32 > > Build failed > Details: http://haskell.inf.elte.hu/builders/solaris-x86-head/32.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > touching clean-check files | Success > setting version date | Success > booting | Success > configuring | Success > creating check-remove-before | Success > compiling | Success > creating check-remove-after | Success > compiling testremove | Success > simulating clean | Success > checking clean | Success > making bindist | Success > making srcdist | Success > uploading bindist | Success > uploading srcdist | Success > uploading tarball source | Success > testing bindist | Failure: Just (ExitFailure 2) > > Build failed > Details: http://haskell.inf.elte.hu/builders/solaris-x86-head/32.html > > > > > _______________________________________________ > ghc-builds mailing list > ghc-builds(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-builds

3 4

GHC's performance
by Simon Peyton Jones 18 Apr '14

18 Apr '14

Friends The thread below concerns GHC's performance. I'm writing to ask for your help. In developing GHC we always run 'validate', which runs a lot of regression tests. A few of those are performance tests, but because we do so frequently, none of these performance tests run for long, and none depend on other packages. And they tend to test something very specific. What we lack is a sustained effort to track a) The performance of GHC itself b) The performance of GHC-compiled programs At GHC HQ we *aspire* to track this stuff, but in practice we simply don't. Bug-fixing, portability, etc etc always ends up taking priority. But it's a pity that we don't. For example, Michal's comment below (that his GHC-compiled program has run 10-20% faster with each release of GHC from 6.12) is fantastic -- but we have no data to back it up, or know whether it's just Michael, or more widely true. I also suspect that sometimes we regress and don't know it. People do report this (e.g. #8971), but it's a bit random. Again, it would be great to have a more systematic way to know. In many cases it might be easy to fix; but we can only fix if we know. We have the nofib suite, and we take that very seriously, but it is showing its age, uses no advanced features, and I'm not sure how representative it is any more. Johan Tibell and Bryan O'Sullivan agreed to become GHC's Performance Tsars a year or two ago, with a view to focusing on (b) at least, but they are both extremely busy. And I don't think they even attempt to focus on (a). So I'm wondering: would anyone like to help here? It would mean * Soliciting and gathering together some more substantial benchmarks * Gathering performance numbers * Yelling quickly if the numbers go bad. * Investigating why (e.g. no one has seriously profiled GHC itself for a while, both space and time. I bet there are improvements to be had there.) Maybe it could be part of the new buildbot team's work? Certainly it'd make sense to use the same nightly-build infrastructure. Anyway, I'm advertising that there's an un-met need, and I'd love some help. Thanks Simon | -----Original Message----- | From: Michal J. Gajda [mailto:mjgajda@gmail.com] | Sent: 10 April 2014 07:26 | To: ghc-devs(a)haskell.org; Sergei Trofimovich; Manuel Chakravarty; Simon | Peyton Jones | Subject: Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc- | ,citeproc / highlighting-kate | | Dear Devs, | | On 04/10/2014 09:09 AM, ghc-devs-request(a)haskell.org wrote: | > Filed the reproducer as a new ticket: | > https://ghc.haskell.org/trac/ghc/ticket/8980 | > | > [ Looks like highlighting-kate asks to be added to | > compiler performance benchmarks (are there such ones?) | > It tends to stress ghc all the time: | > http://hackage.haskell.org/trac/ghc/ticket/3664 | > ] | Please consider adding hPDB too, if you want to stress the optimizer. | It shows GHC optimizer at its best, with at least 10-20% improvement in | every major version of | the compiler since 6.12. Unfortunately at cost of very long compile | times. | Please let me know if I should submit a driver code for automatic | benchmarks it (it is in hPDB-examples.) Thanks! | >> > SpecConstr is too aggressive: it sometimes blows up the program | badly and we have no good | solution. See Trac #7898, #7068, #7944, #5550, #8836. | And #8960, where GHC runs out of memory. (Only in 7.8.) Should be easy | to reproduce by just `cabal install hPDB`. | >> > I notice that the latter three are actually fixed in 7.8, so worth | trying that. If it | still fails, do add instructions to reproduce to one of the above open | tickets, or make a new one. | >> > | >> > Meanwhile you can use -fno-spec-constr to simply switch it off for | offending modules. That should get you going. | -- | Best regards | Michal

4 6