RE: Starting GHC development.
None seem to fail on my (Linux) box. It'd be good if someone felt able to dig into the ones that are failing. If there is a good reason we should open a ticket and mark them as expect_broken( ticket-number ). Thanks! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Mateusz Kowalczyk | Sent: 12 January 2014 10:30 | To: Daniil Frumin | Cc: ghc-devs | Subject: Re: Starting GHC development. | | On 12/01/14 10:25, Daniil Frumin wrote: | Does anyone actually know which tests are supposed to fail on | 'validate'? | | | AFAIK the official stance is that you should see 0 failures. | Unofficially it seems that there's leniency and the tree seems to be in | a state with few tests failing consistently. It might be just my machine | though, but whenever I post my build logs, there seems to be no sense of | urgency to investigate so it does not seem like anyone cares or the | issue is known/being worked on. | | Unfortunately, the side effect of this (and what put me off when I tried | to write some stuff for GHC months ago) was that a new developer comes, | tries to build clean tree and it fails. It's pretty discouraging. | | -- | Mateusz K. | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Starting GHC development.
On 13/01/14 08:42, Simon Peyton Jones wrote: None seem to fail on my (Linux) box. It'd be good if someone felt able to dig into the ones that are failing. If there is a good reason we should open a ticket and mark them as expect_broken( ticket-number ). Thanks! Simon Hm. I checked a log from 6 days ago and here's the end of it: Unexpected failures: perf/compilerT1969 [stat too good] (normal) perf/compilerT3064 [stat not good enough] (normal) perf/compilerT3294 [stat not good enough] (normal) perf/compilerT4801 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) perf/should_run lazy-bs-alloc [stat too good] (normal) We already know that the 32-bit Linux values for Haddock need updating but I have no idea about other ones. I will validate with a clean tree in the following few days and will pester the list with any failures but perhaps for the tests above, the numbers simply need updating. I do not know, I don't think there's any information anywhere about this. Perhaps there indeed aren't any problems but simply outdated tests. Can someone pitch in? Note that to a newcomer, a perf failure is still a failure especially considering that the bottom of the log tells you to fix these before sending any patches. I think fixing these is a little bit out of scope for a newcomer. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Enable TypeHoles by default?
Perhaps we should let type holes be used for one release (so we can get some feedback) before turning it on by default? On Mon, Jan 13, 2014 at 9:57 AM, Simon Peyton Jones simo...@microsoft.comwrote: This would be fine by me – it’s a “user-experience” question. It would slightly threaten the notion that GHC is, by default, a Haskell-2010 compiler; that is, it accepts H-2010 programs and rejects non-H2010 programs. But I think it would be an acceptable bending of this principle, if people wanted it. Maybe ask ghc-users? Simon *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Krzysztof Gogolewski *Sent:* 12 January 2014 22:56 *To:* ghc-devs@haskell.org *Subject:* Enable TypeHoles by default? Hello, I propose to enable -XTypeHoles in GHC by default. Unlike other -X* flags, holes do not really change meaning of the program, they only change error messages. Instead of _x not in scope, we effectively get _x not in scope, its expected type is a - a. You get it only if you precede the identifier not in scope with underscore, so in some sense you declare the intention of using holes. Two possible issues: (a) If you use -fdefer-type-errors, then a program might compile, while previously it did not. However, we should facilitate compiling with defer-type-errors, so I don't think this is a disadvantage. (b) The identifier _ becomes both a pattern and a hole by default, which might confuse new users. Reply: I have never seen anyone ask why code such as Just _ - _ does not work. IMO the productivity boost by having holes by default outweighs those two objections. I am open to hearing any other possible issues others might find. The change is trivial implementation-wise; add Opt_TypeHoles to the list in languageExtensions Nothing in DynFlags. -KG ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Add Windows to NoSharedLibsPlatformList (4af1e76)
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, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d/ghc --- commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d Author: Austin Seipp aus...@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 aus...@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-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Enable TypeHoles by default?
* Simon Peyton Jones simo...@microsoft.com [2014-01-13 08:57:51+] This would be fine by me - it's a user-experience question. It would slightly threaten the notion that GHC is, by default, a Haskell-2010 compiler; that is, it accepts H-2010 programs and rejects non-H2010 programs. But that's not the case even now, is it? Particularly due to NondecreasingIndentation. Roman signature.asc Description: Digital signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Add Windows to NoSharedLibsPlatformList (4af1e76)
The 64bit GHC 7.6.3 windows compiler was not dynamically linked, although it did have -dynamic libraries (although using them is a pain in Windows.) It loaded static object files (you can verify this yourself: 'ghc -O foo.hs ghci foo' will load the object file, but 'ghc -dynamic -O foo.hs ghci foo' will not and instead interpret.) Relatedly, -dynamic-too is also broken on windows, but it's more of an optimization than anything. 7.8 won't have a dynamically linked GHCi for Windows and it won't have -dynamic-too (i.e. essentially the same as 7.6.) Linux, OS X will have both. At this exact moment, -dynamic also seems busted on Windows and I'm looking into fixing it. This will just help me in the mean time to clean up the tree and keep it building for others. On Mon, Jan 13, 2014 at 4:01 AM, kyra ky...@mail.ru wrote: 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, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d/ghc --- commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d Author: Austin Seipp aus...@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 aus...@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-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Alex unicode trick
On 07/01/2014 18:18, Mateusz Kowalczyk wrote: Ah, I think I understand now. If this is the case, at least the ‘alexGetChar’ could be removed, right? Is Alex 2.x compatibility necessary for any reason whatsoever? Yes, the backwards compatibility could be removed now that we require a very recent version of Alex. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Starting GHC development.
On 03/01/2014 18:43, Mateusz Kowalczyk wrote: On 03/01/14 13:27, Simon Peyton-Jones wrote: [snip] Thank you. We need lots of help! [snip] While I hate to interrupt this thread, I think this is a good chance to mention something. I think the big issue for joining GHC development is the lack of communication on the mailing list. There are many topics where a person has a problem with GHC tree (can't validate/build, some tests are failing), posts to GHC devs seeking help and never gets a reply. This is very discouraging and often makes it outright impossible to contribute. An easy example is the failing tests one: unfortunately some tests are known to fail, but they are only known to fail to existing GHC devs. A new person tries to validate clean tree, gets test failures, asks for help on GHC devs, doesn't get any, gives up. Personally I only just read your question about validating Haddock. I didn't know the answer, but I would have suggested a few things to try - it looks like your local package database has some broken packages, perhaps. I'm not sure what the post-testsuite package check is, so I would have to go and look. Generally, the following things might help if you get no answer on the mailing list: - ask in #ghc - search the ticket database (Google with 'site:ghc.haskell.org') - poke around in the code yourself There are not supposed to be any failing tests in validate. If there are, it is a bug: see if someone else has reported it, and if not, report it yourself. Thanks for trying to make GHC better. There are gaps in our support infrastructure, which is unfortunate but typical for an open source project, so sometimes you might have to fix something that wasn't on your critical path. Rest assured that we're very grateful when people do this! Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC API: Using runGhc twice or from multiple threads?
On 07/01/2014 13:55, Benno Fünfstück wrote: 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? The main restriction here is that you can only set the static flags once, because they depend on some global mutable state (the GLOBAL_VARs that Simon mentioned). And what about this one: main = do forkIO $ runGhc libdir $ do ... forkIO $ runGhc libdir $ do ... The problem with this is the RTS linker, which is a single piece of shared global state. We could actually fix that if it became important. If you're not running interpreted code, this should be fine (apart from the static flags issue mentioned above). Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern synonyms for 7.8?
Hi, On Thu, 9 Jan 2014, Austin Seipp wrote: Hi Gergo, I went ahead and pushed the preliminary work to a new branch in the official repositories. GHC, haddock and testsuite now have a 'wip/pattern-synonyms' branch, where you can test the code: https://github.com/ghc/ghc/commits/wip/pattern-synonyms https://github.com/ghc/haddock/commits/wip/pattern-synonyms https://github.com/ghc/testsuite/commits/wip/pattern-synonyms So what's the intended workflow for me from now on? Will master be regularly merged into this branch? Should I base my future work (like fixing the outstanding issues your mail detailed) on top of this branch and continue pushing to my github repo? Thanks, Gergo -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' Why experiment on animals when there are so many lawyers? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Add Windows to NoSharedLibsPlatformList (4af1e76)
More on this: On 1/13/2014 14:51, kyra wrote: The last would be better, because dynamic-linked Windows GHC has longer load time (which can jump to intolerable 2-3 secs, which happens, I guess, when we approach 64k exported symbols limit). which can jump to intolerable 2-3 secs refers to different *builds* of GHC. Some builds had load times in the order of tenths of a second, some - up to 2-3 secs. For example ghc-7.7.20131210 load time was more than 2 secs. When I've rebuilt it lowering funfolding-creation-threshold significantly, load time lowered to tenths of a second. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern synonyms for 7.8?
On 13/01/14 11:06, Dr. ERDI Gergo wrote: On Mon, 13 Jan 2014, Dr. ERDI Gergo wrote: I went ahead and pushed the preliminary work to a new branch in the official repositories. GHC, haddock and testsuite now have a 'wip/pattern-synonyms' branch, where you can test the code: https://github.com/ghc/ghc/commits/wip/pattern-synonyms https://github.com/ghc/haddock/commits/wip/pattern-synonyms https://github.com/ghc/testsuite/commits/wip/pattern-synonyms So what's the intended workflow for me from now on? Will master be regularly merged into this branch? Should I base my future work (like fixing the outstanding issues your mail detailed) on top of this branch and continue pushing to my github repo? Oh and also, how do I reword the commit message of the single squashed commit? I'm asking because there are some small fixes I'd like to do on the message. Thanks, Gergo You can do an interactive rebase and stop at the commit you want to change. Then use git commit --ammend to change the message. You probably don't want to be changing history too much though, it's a pain for anyone working on the same branch. On a somewhat related note, you should probably update your Haddock changes on top of the current master. Let me know if you have problems merging it on top. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: testsuite change
Hello Simon, On 2014-01-13 at 13:08:02 +0100, Simon Peyton Jones wrote: I did 'git pull' in my source tree and got the error below. What do I do now? the easist is to just move the testsuite folder out the way; e.g. mv testsuite/ testsuite-old/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: testsuite change
and then? are all those untracked files really untracked? I definitely didn't add them! Have they been lost from the tree somehow? | -Original Message- | From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com] | Sent: 13 January 2014 12:16 | To: Simon Peyton Jones | Cc: ghc-devs@haskell.org | Subject: Re: testsuite change | | Hello Simon, | | On 2014-01-13 at 13:08:02 +0100, Simon Peyton Jones wrote: | I did 'git pull' in my source tree and got the error below. What do | I do now? | | the easist is to just move the testsuite folder out the way; | | e.g. mv testsuite/ testsuite-old/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: testsuite change
..and indeed, having followed your advice, the new tree contains the claimed not-present files. So all seems well. But it's a mystery to me. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon | Peyton Jones | Sent: 13 January 2014 12:19 | To: Herbert Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: RE: testsuite change | | and then? are all those untracked files really untracked? I definitely | didn't add them! Have they been lost from the tree somehow? | | | | -Original Message- | | From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com] | | Sent: 13 January 2014 12:16 | | To: Simon Peyton Jones | | Cc: ghc-devs@haskell.org | | Subject: Re: testsuite change | | | | Hello Simon, | | | | On 2014-01-13 at 13:08:02 +0100, Simon Peyton Jones wrote: | | I did 'git pull' in my source tree and got the error below. What | | do I do now? | | | | the easist is to just move the testsuite folder out the way; | | | | e.g. mv testsuite/ testsuite-old/ | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Enable TypeHoles by default?
Maybe I'm missing something here, but how does specifying TypeHoles make GHC not compliant with Haskell 2010? Turning on TypeHoles should change only error messages. The set of programs that compile (and their meanings) should remain unchanged, by my understanding. I'm mildly in favor of this change, but I agree that perhaps a conversation on the users list and/or waiting a cycle isn't a bad idea. Richard On Jan 13, 2014, at 4:51 AM, Simon Marlow marlo...@gmail.com wrote: On 12/01/2014 22:56, Krzysztof Gogolewski wrote: I propose to enable -XTypeHoles in GHC by default. GHC supports strict Haskell 2010 by default, and enabling any extensions breaks that property. That's why we don't have any extensions on by default. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: [commit: ghc] master: Add Windows to NoSharedLibsPlatformList (4af1e76)
I think Austin (and the rest of us) would be thrilled if you felt able to help with dynamic linking on Windows. Thank you. I'm utterly ignorant of the details, but it would be SO GREAT to have some help on this. Austin can fill you in. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of kyra | Sent: 13 January 2014 10:52 | To: ghc-devs@haskell.org | Subject: Re: [commit: ghc] master: Add Windows to | NoSharedLibsPlatformList (4af1e76) | | Statically linked 64-bit Windows GHC does not work because of #7134. | Even LARGEADDRESSAWARE flag disabling (extremely bad hack itself) does | not work anymore both on Windows 7 and Windows 8. | | Or is there another (besides dynamic linking) plan to attack #7134? | | I could step in to try to help with any of these, but I'd want to get | more guidance then - either on enabling dll-relating things (for some | time age I've tried to find better ghc-to-dlls decomposition using dll- | split tool, but quickly found we can't do better than it is now, perhaps | GHC itself needs some refactoring to solve this problem), or fixing | #7134 in some other way. The last would be better, because dynamic- | linked Windows GHC has longer load time (which can jump to intolerable | 2-3 secs, which happens, I guess, when we approach 64k exported symbols | limit). | | On 1/13/2014 14:31, Austin Seipp wrote: | The 64bit GHC 7.6.3 windows compiler was not dynamically linked, | although it did have -dynamic libraries (although using them is a pain | in Windows.) It loaded static object files (you can verify this | yourself: 'ghc -O foo.hs ghci foo' will load the object file, but | 'ghc -dynamic -O foo.hs ghci foo' will not and instead interpret.) | Relatedly, -dynamic-too is also broken on windows, but it's more of an | optimization than anything. | | 7.8 won't have a dynamically linked GHCi for Windows and it won't have | -dynamic-too (i.e. essentially the same as 7.6.) Linux, OS X will have | both. | | At this exact moment, -dynamic also seems busted on Windows and I'm | looking into fixing it. This will just help me in the mean time to | clean up the tree and keep it building for others. | | On Mon, Jan 13, 2014 at 4:01 AM, kyra ky...@mail.ru wrote: | 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, g...@git.haskell.org wrote: | Repository : ssh://g...@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3f | b1394dd8b56c8d/ghc | | --- | commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d | Author: Austin Seipp aus...@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 aus...@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 |
Re: Enable TypeHoles by default?
Perhaps already as part of such a feedback round/bikeshedding opportunity, I'm wondering if I'm the only one who finds the name TypeHoles confusing, since as far as I understand, the extension enables holes in *expressions*, not types... I would personally find something like TypedHoles (note the added d) or ExpressionHoles or something similar more intuitive. Not that I have strong feelings about this, though... Note that I haven't actually tried the extension yet, but from the description, it seems like a very nice addition to GHC, so kudos to whoever did the work... Regards, Dominique 2014/1/13 Richard Eisenberg e...@cis.upenn.edu: Maybe I'm missing something here, but how does specifying TypeHoles make GHC not compliant with Haskell 2010? Turning on TypeHoles should change only error messages. The set of programs that compile (and their meanings) should remain unchanged, by my understanding. I'm mildly in favor of this change, but I agree that perhaps a conversation on the users list and/or waiting a cycle isn't a bad idea. Richard On Jan 13, 2014, at 4:51 AM, Simon Marlow marlo...@gmail.com wrote: On 12/01/2014 22:56, Krzysztof Gogolewski wrote: I propose to enable -XTypeHoles in GHC by default. GHC supports strict Haskell 2010 by default, and enabling any extensions breaks that property. That's why we don't have any extensions on by default. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Folding constants for floats
Hi, I'm cutting my teeth on some constant folding for floats in the cmm. I have a question regarding the ticket I'm tackling: Should floats be folded with infinite precision (and later truncated to the platform float size) -- most useful/accurate, or folded with the platform precision, i.e. double, losing accuracy but keeping consistent behaviour with -O0 -- most correct? I would prefer the first case because it's *much* easier to implement than the second, and it'll probably rot less. Regards. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Enable TypeHoles by default?
| Perhaps already as part of such a feedback round/bikeshedding | opportunity, I'm wondering if I'm the only one who finds the name | TypeHoles confusing, since as far as I understand, the extension | enables holes in *expressions*, not types... I would personally find | something like TypedHoles (note the added d) or ExpressionHoles or | something similar more intuitive. I certainly don't mind adding TypedHoles as a synonym, use it in the user manual, and deprecate TypeHoles (and remove it later). If (a) no one objects and (b) someone wants to send a patch. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Dominique Devriese | Sent: 13 January 2014 12:56 | To: ghc-devs@haskell.org | Subject: Re: Enable TypeHoles by default? | | Perhaps already as part of such a feedback round/bikeshedding | opportunity, I'm wondering if I'm the only one who finds the name | TypeHoles confusing, since as far as I understand, the extension | enables holes in *expressions*, not types... I would personally find | something like TypedHoles (note the added d) or ExpressionHoles or | something similar more intuitive. Not that I have strong feelings about | this, though... Note that I haven't actually tried the extension yet, | but from the description, it seems like a very nice addition to GHC, so | kudos to whoever did the work... | | Regards, | Dominique | | 2014/1/13 Richard Eisenberg e...@cis.upenn.edu: | Maybe I'm missing something here, but how does specifying TypeHoles | make GHC not compliant with Haskell 2010? Turning on TypeHoles should | change only error messages. The set of programs that compile (and their | meanings) should remain unchanged, by my understanding. | | I'm mildly in favor of this change, but I agree that perhaps a | conversation on the users list and/or waiting a cycle isn't a bad idea. | | Richard | | On Jan 13, 2014, at 4:51 AM, Simon Marlow marlo...@gmail.com wrote: | | On 12/01/2014 22:56, Krzysztof Gogolewski wrote: | I propose to enable -XTypeHoles in GHC by default. | | GHC supports strict Haskell 2010 by default, and enabling any | extensions breaks that property. That's why we don't have any | extensions on by default. | | Cheers, |Simon | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Pattern synonyms for 7.8?
Check out TcRnDriver.tcRnDeclsi. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 13 January 2014 12:49 | To: Austin Seipp | Cc: Joachim Breitner; GHC Devs | Subject: Re: Pattern synonyms for 7.8? | | On Thu, 9 Jan 2014, Austin Seipp wrote: | | 1) As Richard pointed out, the docs are under docs/users_guide, as | well as the release notes. Please feel free to elaborate however you | want on the feature and the bulletpoint for the release notes. | | Hope to get around to these in the weekend. | | 2) The failures are indeed a result of your code, in particular: | |driver T4437 [bad stdout] (normal) |generics GenDerivOutput [stderr mismatch] (normal) |generics GenDerivOutput1_0 [stderr mismatch] (normal) |generics GenDerivOutput1_1 [stderr mismatch] (normal) |rename/should_compile T7336 [stderr mismatch] (normal) | | Fixed these. | | 3) It seems GHCi does not support declaring pattern synonyms at the | REPL. I'm not sure if it's intentional, but if it goes in like this, | please be sure to document it in the release notes. We can file a | ticket later for supporting pattern synonyms at the REPL. | | It's definitely not intentional and I have no idea why it would be so. | Isn't GHCi a fairly thin wrapper around the GHC internals? Is there any | wiki page detailing the differences in GHCi vs GHC code paths? | | Thanks, | Gergo | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: High-level Cmm code and stack allocation
Thanks. Reading what you write below, I can see two possible motivations. 1. Reduce stack sizes. 2. Eliminate memory moves For (1) do we have any data to show that the non-overlap of areas was giving rise to unacceptably big stacks? For (2) that is indeed clever, but it's pretty serendipitous: it relies on the overlap being just so, so that coincidentally y gets stored in the same place as it was loaded from. I imagine that you don't plan the stack layout to cause that to happen; it's just a coincidence. Do we have any data to show that the coincidence happens with any frequency? Also, as you note, we lose the opportunity for certain sorts of code motion, perhaps increasing register pressure a lot. So there is a downside too. You seldom do things without a very good reason, so I feel I must be missing something. Simon | -Original Message- | From: Simon Marlow [mailto:marlo...@gmail.com] | Sent: 10 January 2014 17:00 | To: Simon Peyton Jones; Herbert Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: Re: High-level Cmm code and stack allocation | | So stack areas are still a great abstraction, the only change is that | they now overlap. It's not just about stack getting too big, I've | copied the notes I made about it below (which I will paste into the code | in due course). The nice property that we can generate well-defined Cmm | without knowing explicit stack offsets is intact. | | What is different is that there used to be an intermediate state where | live variables were saved to abstract stack areas across calls, but Sp | was still not manifest. This intermediate state doesn't exist any more, | the stack layout algorithm does it all in one pass. To me this was far | simpler, and I think it ended up being fewer lines of code than the old | multi-phase stack layout algorithm (it's also much faster). | | Of course you can always change this. My goal was to get code that was | at least as good as the old code generator and in a reasonable amount of | time, and this was the shortest path I could find to that goal. | | Cheers, | Simon | | e.g. if we had | | x = Sp[old + 8] | y = Sp[old + 16] | | Sp[young(L) + 8] = L | Sp[young(L) + 16] = y | Sp[young(L) + 24] = x | call f() returns to L | | if areas semantically do not overlap, then we might optimise this to | | Sp[young(L) + 8] = L | Sp[young(L) + 16] = Sp[old + 8] | Sp[young(L) + 24] = Sp[old + 16] | call f() returns to L | | and now young(L) cannot be allocated at the same place as old, and we | are doomed to use more stack. | |- old+8 conflicts with young(L)+8 |- old+16 conflicts with young(L)+16 and young(L)+8 | | so young(L)+8 == old+24 and we get | | Sp[-8] = L | Sp[-16] = Sp[8] | Sp[-24] = Sp[0] | Sp -= 24 | call f() returns to L | | However, if areas are defined to be possibly overlapping in the | semantics, then we cannot commute any loads/stores of old with young(L), | and we will be able to re-use both old+8 and old+16 for young(L). | | x = Sp[8] | y = Sp[0] | | Sp[8] = L | Sp[0] = y | Sp[-8] = x | Sp = Sp - 8 | call f() returns to L | | Now, the assignments of y go away, | | x = Sp[8] | Sp[8] = L | Sp[-8] = x | Sp = Sp - 8 | call f() returns to L | | | Conclusion: | |- T[old+N] aliases with U[young(L)+M] for all T, U, L, N and M |- T[old+N] aliases with U[old+M] only if the areas actually overlap | | this ensures that we will not commute any accesses to old with | young(L) or young(L) with young(L'), and the stack allocator will get | the maximum opportunity to overlap these areas, keeping the stack use to | a minimum and possibly avoiding some assignments. | | | | On 10/01/2014 16:35, Simon Peyton Jones wrote: | Oh, ok. Alas, a good chunk of my model of Cmm has just gone out of | the window. I thought that areas were such a lovely, well-behaved | abstraction. I was thrilled when we came up with them, and I'm very | sorry to see them go. | | There are no many things that I no longer understand. I now have no | idea how we save live variables over a call, or how multiple returned | values from one call (returned on the stack) stay right where they are | if they are live across the next call. | | What was the actual problem? That functions used too much stack, so | the stack was getting too big? But a one slot area corresponds exactly | to a live variable, so I don't see how the area abstraction could | possibly increase stack size. And is stack size a crucial issue anyway? | | Apart from anything else, areas would have given a lovely solution to | the problem this thread started with! | | I guess we can talk about this when you next visit? But some | documentation would be welcome. | | Simon | | | -Original Message- | | From: Simon Marlow [mailto:marlo...@gmail.com] | | Sent: 10 January 2014 16:24 |
Re: Folding constants for floats
This is actually a bit more subtle than you'd think. Are those constants precise and exact? (There's certainly floating point code that exploits the cancellations in the floating point model) There's many floating point computations that can't be done with exact rational operations. There's also certain aspects that are target dependent like operations having 80bit vs 64bit precision. (Ie using the old intel fp registers vs sse2 and newer) What's the ticket you're working on? Please be very cautious with floating point, any changes to the meaning that aren't communicated by the programs author could leave a haskeller numerical analyst scratching their head. For example, when doing these floating point computations, what rounding modes will you use? On Monday, January 13, 2014, Kyle Van Berendonck wrote: Hi, I'm cutting my teeth on some constant folding for floats in the cmm. I have a question regarding the ticket I'm tackling: Should floats be folded with infinite precision (and later truncated to the platform float size) -- most useful/accurate, or folded with the platform precision, i.e. double, losing accuracy but keeping consistent behaviour with -O0 -- most correct? I would prefer the first case because it's *much* easier to implement than the second, and it'll probably rot less. Regards. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Folding constants for floats
Oh I see the ticket. Are you focusing on adding hex support to Double# and Float# ? That would be splendid. We currently don have a decent way of writing nan, and the infinities. That would be splendid. On Monday, January 13, 2014, Carter Schonwald wrote: This is actually a bit more subtle than you'd think. Are those constants precise and exact? (There's certainly floating point code that exploits the cancellations in the floating point model) There's many floating point computations that can't be done with exact rational operations. There's also certain aspects that are target dependent like operations having 80bit vs 64bit precision. (Ie using the old intel fp registers vs sse2 and newer) What's the ticket you're working on? Please be very cautious with floating point, any changes to the meaning that aren't communicated by the programs author could leave a haskeller numerical analyst scratching their head. For example, when doing these floating point computations, what rounding modes will you use? On Monday, January 13, 2014, Kyle Van Berendonck wrote: Hi, I'm cutting my teeth on some constant folding for floats in the cmm. I have a question regarding the ticket I'm tackling: Should floats be folded with infinite precision (and later truncated to the platform float size) -- most useful/accurate, or folded with the platform precision, i.e. double, losing accuracy but keeping consistent behaviour with -O0 -- most correct? I would prefer the first case because it's *much* easier to implement than the second, and it'll probably rot less. Regards. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Extending fold/build fusion
I've hesitated to reply, because I have lots of questions but no time to
investigate in. I'm looking at your wiki page
https://github.com/takano-akio/ww-fusion
* Does your proposed new fold' run faster than the old one? You give
no data.
* The new foldl' is not a good consumer in the foldr/build sense,
which a big loss. What if you say fold' k z [1..n]; you want the intermediate
list to vanish.
* My brain is too small to truly understand your idea. But since
foldrW is non-recursive, what happens if you inline foldrW into fold', and then
simplify? I'm betting you get something pretty similar to the old foldl'. Try
in by hand, and with GHC and let's see the final optimised code.
* Under motivation you say GHC generates something essentially
like... and then give some code. Now, if GHC would only eta-expand 'go' with
a second argument, you'd get brilliant code. And maybe that would help lots of
programs, not just this one. It's a slight delicate transformation but I've
often thought we should try it; c.f #7994, #5809
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Akio Takano
Sent: 09 January 2014 13:25
To: ghc-devs
Subject: Re: Extending fold/build fusion
Any input on this is appreciated. In particular, I'd like to know: if I
implement the idea as a patch to the base package, is there a chance it is
considered for merge?
-- Takano Akio
On Fri, Jan 3, 2014 at 11:20 PM, Akio Takano
tkn.a...@gmail.commailto:tkn.a...@gmail.com wrote:
Hi,
I have been thinking about how foldl' can be turned into a good consumer, and I
came up with something that I thought would work. So I'd like to ask for
opinions from the ghc devs: if this idea looks good, if it is a known bad idea,
if there is a better way to do it, etc.
The main idea is to have an extended version of foldr:
-- | A mapping between @a@ and @b@.
data Wrap a b = Wrap (a - b) (b - a)
foldrW
:: (forall e. Wrap (f e) (e - b - b))
- (a - b - b) - b - [a] - b
foldrW (Wrap wrap unwrap) f z0 list0 = wrap go list0 z0
where
go = unwrap $ \list z' - case list of
[] - z'
x:xs - f x $ wrap go xs z'
This allows the user to apply an arbitrary worker-wrapper transformation to
the loop.
Using this, foldl' can be defined as
newtype Simple b e = Simple { runSimple :: e - b - b }
foldl' :: (b - a - b) - b - [a] - b
foldl' f initial xs = foldrW (Wrap wrap unwrap) g id xs initial
where
wrap (Simple s) e k a = k $ s e a
unwrap u = Simple $ \e - u e id
g x next acc = next $! f acc x
The wrap and unwrap functions here ensure that foldl' gets compiled into a loop
that returns a value of 'b', rather than a function 'b - b', effectively
un-CPS-transforming the loop.
I put preliminary code and some more explanation on Github:
https://github.com/takano-akio/ww-fusion
Thank you,
Takano Akio
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: High-level Cmm code and stack allocation
Using more stack generally (but not always) implies extra memory traffic. I noticed it happening a lot, but I didn't make measurements - we never had a way to generate code with just this one thing changed, because the new code generator had lots of issues with bad code, and this was just one. We can think of stack allocation as a black box: it takes Cmm in which (a) variables live across calls and (b) stack references are to [Old+n] or [Young+n], and returns Cmm in which (a) variables do not live across calls, and (b) all stack references are explicit offsets from Sp. The internals of this box are what has changed. Most users of Cmm don't need to care, because you can write optimisations on both the pre-stack-allocated Cmm and the post-stack-allocated Cmm without knowing anything about how stack allocation works. Indeed CmmSink (now) works on both forms. The stack area idea exposed some of the internals of this box; I don't think that's necessarily a good thing. There was *another* form of Cmm, in which (a) variables do not live across calls, and (b) stack references are to [Old+n], [Young+n] or [Sp(var)]. There was a (beautifully simple) spill pass using Hoopl that inserted spills at the definition site; unfortunately to generate good code you often have to move the spills somewhere else. And that's really hard, because code motion interacts in complex ways with stack layout: making a bad code motion decision can increase your stack requirements. This is a pretty good summary of what I was finding difficult here. It was not possible to generate good code without doing some optimisation on this intermediate stage, yet by doing stack allocation in a different way it was much easier to get good code. So the new stack allocator just walks through the code spilling, reloading, and allocating stack frames as it goes and making intelligent decisions about not spilling things if they're already on the stack. This does a really good job, and it was easy to add a couple of important special cases for common things. There's plenty of room to do something better. However, what we have now generates good code from the kind of things that the code generator generates (since that's what I tuned it for, by peering at lots of Cmm and tweaking things), so any improvements won't see much benefit for typical Haskell code. I have some more docs for the stack layout code that I'll push shortly. Cheers, Simon On 13/01/2014 15:20, Simon Peyton Jones wrote: Thanks. Reading what you write below, I can see two possible motivations. 1. Reduce stack sizes. 2. Eliminate memory moves For (1) do we have any data to show that the non-overlap of areas was giving rise to unacceptably big stacks? For (2) that is indeed clever, but it's pretty serendipitous: it relies on the overlap being just so, so that coincidentally y gets stored in the same place as it was loaded from. I imagine that you don't plan the stack layout to cause that to happen; it's just a coincidence. Do we have any data to show that the coincidence happens with any frequency? Also, as you note, we lose the opportunity for certain sorts of code motion, perhaps increasing register pressure a lot. So there is a downside too. You seldom do things without a very good reason, so I feel I must be missing something. Simon | -Original Message- | From: Simon Marlow [mailto:marlo...@gmail.com] | Sent: 10 January 2014 17:00 | To: Simon Peyton Jones; Herbert Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: Re: High-level Cmm code and stack allocation | | So stack areas are still a great abstraction, the only change is that | they now overlap. It's not just about stack getting too big, I've | copied the notes I made about it below (which I will paste into the code | in due course). The nice property that we can generate well-defined Cmm | without knowing explicit stack offsets is intact. | | What is different is that there used to be an intermediate state where | live variables were saved to abstract stack areas across calls, but Sp | was still not manifest. This intermediate state doesn't exist any more, | the stack layout algorithm does it all in one pass. To me this was far | simpler, and I think it ended up being fewer lines of code than the old | multi-phase stack layout algorithm (it's also much faster). | | Of course you can always change this. My goal was to get code that was | at least as good as the old code generator and in a reasonable amount of | time, and this was the shortest path I could find to that goal. | | Cheers, | Simon | | e.g. if we had | | x = Sp[old + 8] | y = Sp[old + 16] | | Sp[young(L) + 8] = L | Sp[young(L) + 16] = y | Sp[young(L) + 24] = x | call f() returns to L | | if areas semantically do not overlap, then we might optimise this to | | Sp[young(L) + 8] = L | Sp[young(L) + 16] = Sp[old + 8] | Sp[young(L) + 24] =
Re: Enable TypeHoles by default?
I have re-sent the question to glasgow-haskell-users; to avoid duplication, let's continue the thread there. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Folding constants for floats
Hi, I'd like to work on the primitives first. They are relatively easy to implement. Here's how I figure it; The internal representation of the floats in the cmm is as a Rational (ratio of Integers), so they have infinite precision. I can implement all the constant folding by just writing my own operations on these rationals; ie, ** takes the power of the top/bottom and reconstructs a new Rational, log takes the difference between the log of the top/bottom etc. This is all very easy to fold. I can encode errors in the Rational where infinity is 0 %: 0 and NaN is 0 %: 0. Since the size of floating point constants is more of an architecture specific thing, and floats don't wrap around like integers do, it would make more sense (in my opinion) to only reduce the value to the architecture specific precision (or clip it to a NaN or such) in the **final** stage as apposed to trying to emulate the behavior of a double native to the architecture (which is a very hard thing to do, and results in precision errors -- the real question is, do people want precision errors when they write literals in code, or are they really looking for the compiler to do a better job than them at making sure they stay precise?) On Tue, Jan 14, 2014 at 3:27 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Oh I see the ticket. Are you focusing on adding hex support to Double# and Float# ? That would be splendid. We currently don have a decent way of writing nan, and the infinities. That would be splendid. On Monday, January 13, 2014, Carter Schonwald wrote: This is actually a bit more subtle than you'd think. Are those constants precise and exact? (There's certainly floating point code that exploits the cancellations in the floating point model) There's many floating point computations that can't be done with exact rational operations. There's also certain aspects that are target dependent like operations having 80bit vs 64bit precision. (Ie using the old intel fp registers vs sse2 and newer) What's the ticket you're working on? Please be very cautious with floating point, any changes to the meaning that aren't communicated by the programs author could leave a haskeller numerical analyst scratching their head. For example, when doing these floating point computations, what rounding modes will you use? On Monday, January 13, 2014, Kyle Van Berendonck wrote: Hi, I'm cutting my teeth on some constant folding for floats in the cmm. I have a question regarding the ticket I'm tackling: Should floats be folded with infinite precision (and later truncated to the platform float size) -- most useful/accurate, or folded with the platform precision, i.e. double, losing accuracy but keeping consistent behaviour with -O0 -- most correct? I would prefer the first case because it's *much* easier to implement than the second, and it'll probably rot less. Regards. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] platformFromTriple: fix to recognize Solaris triple (i386-pc-solaris2.11)
Hello Karel, On 2014-01-13 at 18:13:55 +0100, Karel Gardas wrote: Hello Herbert, the fix in a little bit extended version is already up-stream: https://github.com/haskell/cabal/commit/98a3feb23364897779dd665758949555a84dc5b8 well, it's a first step that's in the master branch, but GHC HEAD currently tracks the stable Cabal branch (currently this is 1.18[1]) as we want GHC to ship with a proper release of the Cabal lib. What is the process to ask ghc developers to update from upstream? You'll need to persuade the Cabal devs to make the fix above available in a stable branch; if the fix makes it into a Cabal release in time for the final GHC 7.8 release, it will most likely be part of 7.8. However, I don't know if there's a concrete plan for a Cabal-1.18.1.3 release currently. [1]: https://github.com/haskell/cabal/commits/1.18 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Folding constants for floats
On 01/13/2014 05:21 PM, Kyle Van Berendonck wrote: Hi, I'd like to work on the primitives first. They are relatively easy to implement. Here's how I figure it; The internal representation of the floats in the cmm is as a Rational (ratio of Integers), so they have infinite precision. I can implement all the constant folding by just writing my own operations on these rationals; ie, ** takes the power of the top/bottom and reconstructs a new Rational, log takes the difference between the log of the top/bottom etc. This is all very easy to fold. What about sin(), etc? I don't think identities will get you out of computing at least some irrational numbers. (Maybe I'm missing your point?) Since the size of floating point constants is more of an architecture specific thing IEEE 754 is becoming more and more ubiquitous. As far as I know, Haskell Float is always IEEE 754 32-bit binary floating point and Double is IEEE 754 64-bit binary floating point, on machines that support this (including x86_64, ARM, and sometimes x86). Let's not undermine this progress. and floats don't wrap around like integers do, it would make more sense (in my opinion) to only reduce the value to the architecture specific precision (or clip it to a NaN or such) in the **final** stage as apposed to trying to emulate the behavior of a double native to the architecture (which is a very hard thing to do, and results in precision errors GCC uses MPFR to exactly emulate the target machine's rounding behaviour. the real question is, do people want precision errors when they write literals in code, Yes. Look at GCC. If you don't pass -ffast-math (which says you don't care if floating-point rounding behaves as specified), you get the same floating-point behaviour with and without optimizations. This is IMHO even more important for Haskell where we tend to believe in deterministic pure code. -Isaac ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
