September 2018 - ghc-devs

RE: Hadrian
by Andrey Mokhov 04 Sep '18

04 Sep '18

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://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#ver… 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://github.com/snowleopard/hadrian/blob/master/README.md How to use UserSettings: https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md An overview of build flavours: https://github.com/snowleopard/hadrian/blob/master/doc/flavours.md 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

3 3

Re: Unpacking coercions
by Ryan Scott 04 Sep '18

04 Sep '18

If we can gain some performance from this, then I'm generally supportive of this idea. I'm still of the belief that we could teach GHC to unpack boxed equality constraints, but your idea would definitely be the simpler one to implement. Ryan S.

2 1

Call for Presentations on Secure Compilation (PriSC Workshop @ POPL'19)
by Dominique Devriese 04 Sep '18

04 Sep '18

(apologies if you receive multiple copies of this announcement) ======================================================================= Call for Presentations on Secure Compilation (PriSC Workshop @ POPL'19) ======================================================================= The emerging field of secure compilation aims to preserve security properties of programs when they have been compiled to low-level languages such as assembly, where high-level abstractions don’t exist, and unsafe, unexpected interactions with libraries, other programs, the operating system and even the hardware are possible. For unsafe source languages like C, secure compilation requires careful handling of undefined source-language behavior (like buffer overflows and double frees). Formally, secure compilation aims to protect high-level language abstractions in compiled code, even against adversarial low-level contexts, thus enabling sound reasoning about security in the source language. A complementary goal is to keep the compiled code efficient, often leveraging new hardware security features and advances in compiler design. Other necessary components are identifying and formalizing properties that secure compilers must possess, devising efficient security mechanisms (both software and hardware), and developing effective verification and proof techniques. Research in the field thus puts together advances in compiler design, programming languages, systems security, verification, and computer architecture. ============================================================= 3rd Workshop on Principles of Secure Compilation (PriSC 2019) ============================================================= The Workshop on Principles of Secure Compilation (PriSC) is a relatively new, informal 1-day workshop without any proceedings. The goal is to bring together researchers interested in secure compilation and to identify interesting research directions and open challenges. The 3rd edition of PriSC will be held in Lisbon, together with the ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL), 2019. The exact date will be either January 13 or January 19 (to be decided by the POPL organizers). More information is available at http://popl19.sigplan.org/track/prisc-2019 Important Dates * Presentation proposal submission deadline: 17 October 2018, AoE * Presentation proposal notification: 10 November 2018 * PriSC Workshop takes place: either Sunday, 13 January 2019 or Saturday 19 January 2019 (to be decided by the POPL organizers) ================================================= Presentation Proposals and Attending the Workshop ================================================= Anyone interested in presenting at the workshop should submit an extended abstract (up to 2 pages, details below) covering past, ongoing, or future work. Any topic that could be of interest to secure compilation is in scope. Secure compilation should be interpreted very broadly to include any work in security, programming languages, architecture, systems or their combination that can be leveraged to preserve security properties of programs when they are compiled or to eliminate low-level vulnerabilities. Presentations that provide a useful outside view or challenge the community are also welcome. This includes presentations on new attack vectors such as microarchitectural side-channels, whose defenses could benefit from compiler techniques. Specific topics of interest include but are not limited to: * attacker models for secure compiler chains. * secure compiler properties: fully abstract compilation and similar properties, memory safety, control-flow integrity, preservation of safety, information flow and other (hyper-)properties against adversarial contexts, secure multi-language interoperability. * secure interaction between different programming languages: foreign function interfaces, gradual types, securely combining different memory management strategies. * enforcement mechanisms and low-level security primitives: static checking, program verification, typed assembly languages, reference monitoring, program rewriting, software-based isolation/hiding techniques (SFI, crypto-based, randomization-based, OS/hypervisor-based), security-oriented architectural features such as Intel’s SGX, MPX and MPK, capability machines, side-channel defenses, object capabilities. * experimental evaluation and applications of secure compilers. * proof methods relevant to compilation: (bi)simulation, logical relations, game semantics, trace semantics, multi-language semantics, embedded interpreters. * formal verification of secure compilation chains (protection mechanisms, compilers, linkers, loaders), machine-checked proofs, translation validation, property-based testing. ============================================ Guidelines for Submitting Extended Abstracts ============================================ Extended abstracts should be submitted in PDF format and not exceed 2 pages. They should be formatted in two-column layout, 10pt font, and be printable on A4 and US Letter sized paper. We recommend using the new acmart LaTeX style in sigplan mode: http://www.sigplan.org/sites/default/files/acmart/current/acmart-sigplanpro… Submissions are not anonymous and should provide sufficient detail to be assessed by the program committee. Presentation at the workshop does not preclude publication elsewhere. Please submit your extended abstracts at https://prisc19.hotcrp.com/. ============================ Contact and More Information ============================ For questions please contact the workshop chairs, Dominique Devriese ( dominique.devriese(a)cs.kuleuven.be) and Deepak Garg (dg(a)mpi-sws.org) To make sure you receive such announcements in the future please subscribe to the following low-traffic mailing list: https://lists.gforge.inria.fr/mailman/listinfo/prisc-announce

1 0

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