- ghc-devs - Haskell.org

Unpacking coercions
by David Feuer 03 Sep '18

03 Sep '18

I had an idea for how we might be able to unpack coercions in a limited and conservative way that doesn't get into the general problems of unpacking constraints. Would this make sense? 1. Move the definition of Coercion from Data.Type.Coercion to GHC.Magic 2. Magically change the type of the Coercion constructor from Coercion :: Coercible a b => Coercion a b to Coercion :: a ~R# b => Coercion a b Now a strict Coercion field will unpack to nothing.

1 0

RE: [commit: ghc] master: make iToBase62's inner loop stricter in one of its arguments (ed78951)
by Simon Peyton Jones 03 Sep '18

03 Sep '18

Alp, Is this related to #15570. If so, it'd be good to make that connection. S | -----Original Message----- | From: ghc-commits <ghc-commits-bounces(a)haskell.org> On Behalf Of | git(a)git.haskell.org | Sent: 02 September 2018 22:16 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: make iToBase62's inner loop stricter in | one of its arguments (ed78951) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fed789516e201e4fad771e5588da47a62e53b42b | 8%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Cea714d654b04488aada9 | 08d6111955e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636715197856324 | 232&sdata=3Oo7y3FCIzEZVAWc%2FPl6ZXwji2QM2CWWAI3UfHqxDn0%3D&reserv | ed=0 | | >--------------------------------------------------------------- | | commit ed789516e201e4fad771e5588da47a62e53b42b8 | Author: Alp Mestanogullari <alp(a)well-typed.com> | Date: Sun Sep 2 22:06:55 2018 +0200 | | make iToBase62's inner loop stricter in one of its arguments | | Summary: | hadrian's support for dynamic ways is currently broken (see | hadrian#641 [1]). | The stage 1 GHCs that hadrian produces end up producing bad code for | the `iToBase62` function after a few optimisation passes. | | In the case where `quotRem` returns (overflowError, 0), | GHC isn't careful enough to realise q is _|_ and happily inlines, | distributes and floats code around until we end up trying to access | index `minBound :: Int` of an array of 62 chars, as a result of | inlining | the definition of `quotRem` for Ints, in particular the minBound | branch [2]. | | I will separately look into reproducing the bad transformation on a | small | self-contained example and filling a ticket. | | [1]: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fissues%2F641&data=02%7C01%7Csimonpj%40mi | crosoft.com%7Cea714d654b04488aada908d6111955e2%7C72f988bf86f141af91ab2d7c | d011db47%7C1%7C0%7C636715197856324232&sdata=a7dM0YbraOY69xKhJcwVuQqBn | 3n3nTdVuMFNjie6iHA%3D&reserved=0 | [2]: | https://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/GHC/Real.hs#l36 | 6 | | Test Plan: fixes hadrian#641 | | Reviewers: bgamari, tdammers | | Reviewed By: tdammers | | Subscribers: tdammers, rwbarton, carter | | Differential Revision: https://phabricator.haskell.org/D5106 | | | >--------------------------------------------------------------- | | ed789516e201e4fad771e5588da47a62e53b42b8 | compiler/basicTypes/Unique.hs | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) | | diff --git a/compiler/basicTypes/Unique.hs | b/compiler/basicTypes/Unique.hs index 4a709d2..b5c0fce 100644 | --- a/compiler/basicTypes/Unique.hs | +++ b/compiler/basicTypes/Unique.hs | @@ -325,7 +325,7 @@ iToBase62 n_ | go n cs | n < 62 | = let !c = chooseChar62 n in c : cs | | otherwise | - = go q (c : cs) where (q, r) = quotRem n 62 | + = go q (c : cs) where (!q, r) = quotRem n 62 | !c = chooseChar62 r | | chooseChar62 :: Int -> Char | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7Cea714d654b04488aada9 | 08d6111955e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636715197856324 | 232&sdata=5oKSdyvdcyJlPR%2FtNUNuptlsFuv9jJA%2FVmc7AOid5mc%3D&rese | rved=0

1 0

cc1plus.exe of bundled mingw-w64 segfaults
by Shao, Cheng 02 Sep '18

02 Sep '18

Hi folks, I'm building a Haskell/C++ hybrid project with a recent revision of ghc on Windows, and noticed that cc1plus.exe always segfaults. The same code builds fine on AppVeyor however and currently I have no clue why it ceases to work on my machine. Is anyone else experiencing a similar problem? I'm not sure if it's worth a trac ticket. Using cc1plus.exe from a newer version of mingw-w64-x86_64-gcc works on my machine, but weird linker errors arise when I attempt to use the newer gcc toolchain to override the bundled one. Is there a way to manually specify mingw-w64 tarball version/urls when configuring ghc? I notice there's an "--enable-distro-toolchain" flag, does it work with building a bindist? Thank you. Regards, Shao Cheng

1 1

CI failures on OSX
by Andreas Klebinger 02 Sep '18

02 Sep '18

Hello devs, OSX CI seems to have testsuite failures since at least 44ba66527ae2 <https://phabricator.haskell.org/rGHC44ba66527ae207ce2dd64eb2bce14656d474f6d1> (but likely caused by something else) and started sometime after 966aa7818222 <https://phabricator.haskell.org/rGHC966aa7818222a8637b56ca32b3892901de1bf5d4> going by the Phab history. So seems to have been caused by one of the commits on Aug 22. Could anyone with an Mac take a look there? Cheers Andreas

1 0

Compile times: Average vs worst case runtime
by Andreas Klebinger 01 Sep '18

01 Sep '18

Hello Devs, I developed a patch improving on GHC's code layout during GSoC: https://ghc.haskell.org/trac/ghc/ticket/15124 The gains are pretty nice with most library benchmarks showing improvments in the 1-2% range or more. Even compile times went down comparing head vs stage2 built with, and using my patch! Making compilation of nofib overall faster by 0.5-1% depending on the exact setup. Now the bad news: In some cases the algorithm has bad big O performance, in practice this seems to be code with things like cases with 200+ alternatives. Where these cases also represent most of the code compiled. The worst case I saw was doubled compile time in a Module which only consisted of a 500 deep if/else chain only selecting an value. While there are some small optimizations possible to improve on this I don't expect to make these edge cases much faster overall. However it will also be possible to fall back to the old behavior to avoid the large compile times for modules known to trigger this edge case. Which brings me to my main question: When should we use the new code layout. 1. Always since on average both compile and runtime is faster. 2. -O1/O2 since users often use this when performance matters. 3. -O2 since users expect compilation times to blow up with it? 4. Never as users experience compile time slowdowns when they hit these edge cases. I'm would prefer 2. 3. 1. 4. in that order but I wonder what the wider community is thinking. Cheers Andreas

2 3

RE: Hadrian
by Andrey Mokhov 30 Aug '18

30 Aug '18

> How do I "pass --verbose to Hadrian"? Like this: cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." -V Everything after "--" in this command line are flags passed to Hadrian. Everything before are flags passed to Cabal. (I hope we'll fix the "build.sh" script for you soon, so you don't need to go via Cabal.) I just tried this with {-# OPTIONS_GHC -dverbose-core2core #-} and this did also print out a lot of Core. And a lot more stuff (somehow this seems to cause further recompilation). > https://ghc.haskell.org/trac/ghc/wiki/Building/Hadrian/QuickStart Artem -- thanks! I forgot to mention this wiki page, which indeed looks Cheers, Andrey -----Original Message----- From: Simon Peyton Jones [mailto:simonpj@microsoft.com] Sent: 30 August 2018 13:00 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Alp Mestanogullari <alp(a)well-typed.com> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: RE: Hadrian | If you want to see all command lines, you can pass '--verbose' or '-V' | flag to Hadrian and it will then print out everything it does. But I am not invoking Hadrian. I am saying (on your instructions) cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." How do I "pass --verbose to Hadrian"? | -----Original Message----- | From: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> | Sent: 30 August 2018 12:26 | To: Simon Peyton Jones <simonpj(a)microsoft.com>; Alp Mestanogullari | <alp(a)well-typed.com> | Cc: ghc-devs <ghc-devs(a)haskell.org> | Subject: RE: Hadrian | | Simon, | | If you want to see all command lines, you can pass '--verbose' or '-V' | flag to Hadrian and it will then print out everything it does. | | But you can also choose which particular command lines to print in | UserSettings, see: | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md%23verbose-command- | lines&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508 | d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671225140342623 | 1&sdata=tMYhmIGMeVbBYjAtxWQTY5%2F4Kyfc4m981N4OTowGkbQ%3D&reserved | =0 | | So, you can do: | | verboseCommand = input "//GHC/Real.hs" | | Or, alternatively, | | verboseCommand = output "//GHC/Real.hi" | | Both should produce the same result (in theory). | | In general, we have the following documents on Hadrian: | | The README: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2FREADME.md&data=02%7C01%7 | Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f988bf86f | 141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=7WigmQG7lbDd | eyhYCSaKOQEb0eeZcn0iXAbAKdwZ5A4%3D&reserved=0 | How to use UserSettings: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269 | efd508d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671225140 | 3426231&sdata=tRu2lO%2F6TNV3ao5tzNKO%2FAHJMWsxKX%2BqExHn78nuCvU%3D&am | p;reserved=0 | An overview of build flavours: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fflavours.md&data=0 | 2%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f | 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=Esye | DdAKLV9DC3PUwkqsuQ4zGoOYKcaJeEov1BAH8lU%3D&reserved=0 | | I hope the more Hadrian gets used, the more complete the documentation | will become. | | Cheers, | Andrey | | From: Simon Peyton Jones [mailto:simonpj@microsoft.com] | Sent: 30 August 2018 12:19 | To: Simon Peyton Jones <simonpj(a)microsoft.com>; Alp Mestanogullari | <alp(a)well-typed.com>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> | Cc: ghc-devs <ghc-devs(a)haskell.org> | Subject: RE: Hadrian | | Sigh. As an inconvenient workaround, I tried adding {-# OPTIONS_GHC - | dverbose-core2core #-} to GHC.Real, and then doing | cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." | in hadrian/ | That did recompile GHC.Real - but all the debug output disappeared! | I tried adding {-# OPTIONS_GHC -ddebug-output #-} as well, but that | didn't work. | I'm stuck - any ideas? | Simon | | From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Simon Peyton | Jones via ghc-devs | Sent: 30 August 2018 12:12 | To: Alp Mestanogullari <alp(a)well-typed.com>; Andrey Mokhov | <andrey.mokhov(a)newcastle.ac.uk> | Cc: ghc-devs <ghc-devs(a)haskell.org> | Subject: Hadrian | | Alp, Andrey | The old build system printed out every command line; and I often copy- | paste that info to build single modules. | Eg currently, when trying to understand #15570 I see a suspicious | GHC.Real.hi. So I want to manually recompile GHC.Real (from base), | adding some debug flags. How can I get the right command line to do that | from the build log? | Where is the "how to use Hadrian" wiki page? I know you've been writing | one. | Simon

1 0

Hadrian
by Simon Peyton Jones 30 Aug '18

30 Aug '18

Alp, Andrey The old build system printed out every command line; and I often copy-paste that info to build single modules. Eg currently, when trying to understand #15570 I see a suspicious GHC.Real.hi. So I want to manually recompile GHC.Real (from base), adding some debug flags. How can I get the right command line to do that from the build log? Where is the "how to use Hadrian" wiki page? I know you've been writing one. Simon

1 1

Haskell DLL (using FFI) causes memory leak.
by Ольга Филиппская 28 Aug '18

28 Aug '18

Hello. *Summary: *memory is consumed without releasing when a Haskell DLL (that uses FFI) is loaded and unloaded in an endless loop. *Details*: I'm working on a C++ project relying on a DLL that uses Haskell code. The DLL was built with GHC 8.0.1 x64, OS is Windows 7. (Newer versions of GHC - 8.2.1 and later - do not allow you to build such DLLs due to some bugs: ticket #1 <https://ghc.haskell.org/trac/ghc/ticket/14472#no2> , ticker #2 <https://ghc.haskell.org/trac/ghc/ticket/14784#no1>). The C++ project was built with MSVC compiler 2015. We noticed that memory is not released when the library is unloaded. I've constructed a baseline example to reproduce the bug. It has three files: the first one is *HaskellSources.hs*(see attachments). It contains one foreign export function foo. This foreign export function is necessary to reproduce the bug. The second file is *CWrapper.cpp*. I intentionally didn't include any Haskell function export because they make no difference for this example. The last file is the code of the main program (see *main.cpp*) that loads the library and unloads it at once in an endless loop. There are two cases: whether HaskellExports.o is included into the library or not. 1. HaskellExports.o is not included into the library (see attached build script* build_no_hs.sh*). Everything works just fine (i.e. amount of memory consumed by the app is the same before DLL loading and right after unloading.) 2. HaskellExports.o is included into the library (see *build_w_hs.sh*). Memory is not released after unloading the DLL, after repeated load/unload cycles memory consumption keeps growing until finally the application crashes. Is this a known problem? Is it tracked in your bugtracker? (Or maybe it is not a problem at all and I'm doing it wrong). Thank you for your time. -- *Olga Philippskaya.*

4 6

Re: Bump base version
by Ryan Scott 27 Aug '18

27 Aug '18

I'm confused. base-4.12.0.0 hasn't been released yet, so can't we just make this StableName change a part of 4.12.0.0? (Regardless of what we choose, we should make sure to advertise this change in base's changelog—currently it's unmentioned.) Ryan S.

2 2

GHC 8.6.1 release status
by Ben Gamari 25 Aug '18

25 Aug '18

Hi everyone, I was getting ready to prepare the final 8.6.1 release tarballs when Herbert pointed out that the testsuite of his cryptohash-sha256 package currently segfaults. This appears to be a rather serious, non-deterministic regression. I've opened #15544 to track this and will delay the final 8.6.1 release until this is resolved. Cheers, - Ben

8 11