- ghc-devs - Haskell.org

compiling GHC: undefined references
by Németh Boldizsár 19 Jan '18

19 Jan '18

Dear GHC Devs, This is my first time trying to compile GHC on my machine and I need a little help to go on. I ran into a problem, I get a lot of undefined reference errors when linking. A sample of these: ghc\stage2\build\Main.o:fake:(.text+0x1f3): undefined reference to `ghczmprim_GHCziTypes_ZC_con_info' ghc\stage2\build\Main.o:fake:(.text+0x340): undefined reference to `ghczmprim_GHCziTypes_ZMZN_closure' ghc\stage2\build\Main.o:fake:(.text+0x498): undefined reference to `ghczmprim_GHCziTypes_False_closure' ghc\stage2\build\Main.o:fake:(.text+0x4c0): undefined reference to `ghczmprim_GHCziTypes_True_closure' Before the errors I have a warning: Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. The only change I made is fixing some simple type errors in utils/ghc-cabal/Main.hs that stopped compilation. Commit ID is: cf2c029ccdb967441c85ffb66073974fbdb20c20 Best Regards, Boldizsár

1 0

Versioning of libraries bundled with GHC pre-releases
by Ben Gamari 17 Jan '18

17 Jan '18

TL;DR. We propose to start following the PVP for core libraries shipped with GHC alpha release. Let us know what you think. Hello everyone, GHC has recently been reworking its release policy, increasing the release cadence to two releases per year. We hope that this change facilitates earlier and more thorough testing of GHC. Of course, a compiler is worth little if no real-world packages can be built with it. Historically library maintainers have been reluctant to offer releases claiming compatibility with pre-release GHCs due to the lax versioning guarantees offered by such pre-releases. Specifically, changes to libraries shipped with GHC pre-releases have historically not had proper distinct version numbers, causing unnecessary breakage for released code (e.g. [1]). To make maintainers feel more at ease with releasing libraries compatible with GHC alpha releases, we propose to start using the Package Versioning Policy (PVP) [2] to version GHC's core libraries with each alpha release. That is, libraries which are not source-identical will get at very least a minor bump with each alpha release. By "core libraries" we mean the set of: * base * template-haskell * integer-gmp * integer-simple * hpc * ghci * ghc-compact * all GHC dependencies not maintained by GHC HQ * ghc-prim * ghc-boot * ghc-boot-th Following the PVP will allow maintainers to safely release libraries to Hackage without fear that they will break when the final GHC 8.4.1 release is made, easing the testing process for everyone. If you have an opinion one way or another on this matter please do share it on this list. Cheers, - Ben [1] https://github.com/tibbe/hashable/issues/143 [2] https://pvp.haskell.org/

2 2

RE: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by Simon Peyton Jones 17 Jan '18

17 Jan '18

| Simon, we were wrong about CorePrep not dropping unfoldings for exported | ids, it really drops all unfoldings. I'd forgotten that. Notes are so useful! | Are there any other reasons for not doing this in CorePrep? Can we maybe | implement a pass before CorePrep just for cost center collection? Currently CorePrep is just in a unique-supply monad. But I guess you could add a writer monad to allow us to collect cost centres. That should not be hard. Alternatively, a separate pass (run only if we have profiling). I don’t feel strongly. A separate pass run always seems overkill somehow. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 17 January 2018 06:54 | Subject: Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors | | #5889: -fno-prof-count-entries leads to linking errors | -------------------------------------+---------------------------------- | -------------------------------------+--- | Reporter: akio | Owner: bgamari | Type: bug | Status: new | Priority: highest | Milestone: 8.4.1 | Component: Compiler | Version: 8.3 | Resolution: | Keywords: | Operating System: Linux | Architecture: x86_64 | | (amd64) | Type of failure: GHC rejects | Test Case: | valid program | profiling/should_compile/T5889 | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Wiki Page: | | -------------------------------------+---------------------------------- | -------------------------------------+--- | | Comment (by osa1): | | Simon, we were wrong about CorePrep not dropping unfoldings for exported | ids, it really drops all unfoldings. There's a note | | {{{ | {- Note [Drop unfoldings and rules] | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | We want to drop the unfolding/rules on every Id: | | - We are now past interface-file generation, and in the | codegen pipeline, so we really don't need full unfoldings/rules | | - The unfolding/rule may be keeping stuff alive that we'd like | to discard. See Note [Dead code in CorePrep] | | - Getting rid of unnecessary unfoldings reduces heap usage | | - We are changing uniques, so if we didn't discard unfoldings/rules | we'd have to substitute in them | | HOWEVER, we want to preserve evaluated-ness; see Note [Preserve | evaluated-ness in CorePrep] | | Note [Preserve evaluated-ness in CorePrep] | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | We want to preserve the evaluated-ness of each binder (via | evaldUnfolding) for two reasons | | * In the code generator if we have | case x of y { Red -> e1; DEFAULT -> y } | we can return 'y' rather than entering it, if we know | it is evaluated (Trac #14626) | | * In the DataToTag magic (in CorePrep itself) we rely on | evaluated-ness. See Note Note [dataToTag magic]. | -} | }}} | | I can also clearly see that in the code we don't distinguish exported | from non-exported, we just zap all unfoldings (see `cpCloneBndrs` and | `zapUnfolding`). | | So it seems to me like we may have to collect cost centers before or | during CorePrep. I vaguely remember discussing this in the meeting and | one of the arguments against this was that `CorePrep` is already complex | enough so if possible it'd be nice to avoid making it even more complex. | Are there any other reasons for not doing this in CorePrep? Can we maybe | implement a pass before CorePrep just for cost center collection? | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.hask | ell.org%2Ftrac%2Fghc%2Fticket%2F5889%23comment%3A29&data=02%7C01%7Csimonp | j%40microsoft.com%7C4c0906a7bcde47e7d7ac08d55d77108f%7C72f988bf86f141af91 | ab2d7cd011db47%7C1%7C0%7C636517688316807916&sdata=5eSk5giuvhClD%2BxskYvyc | f9qqTyYn%2Fwy3%2FxSuDoXMQA%3D&reserved=0> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.hask | ell.org%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C4c0906a7bcde47e | 7d7ac08d55d77108f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365176883 | 16817923&sdata=aandvbx2KYXpNrhNPodNIt%2FtxpY2yT4YytP0PTyIkDQ%3D&reserved= | 0> | The Glasgow Haskell Compiler

1 0

Are join points inlined differently from normal bindings?
by Matthew Pickering 16 Jan '18

16 Jan '18

I have quite a complicated program which relies on the optimiser inlining very aggressively. In 8.0.2, it works fine and produces the core I am expecting. In 8.2.2, one of the bindings is identified as a join point and then not inlined when doing so would lead to the same code. Bumping the unfolding-use-threshold to 10 (from 8) causes it to be inlined and produces the right core. Here is the core for reference - https://gist.github.com/mpickering/be30105b97fa7e4149c9fa935d72cd1c I haven't dug into which exact part of my program introduces this join point but this seems like a regression from 8.0.2. However, I make a mailing list post as I unsure how to expect the inliner to treat join points. Questions. 1. Does the inliner treat join point bindings differently to normal bindings? 2. How can I stop the compiler introducing this join point which seems to get in the way of the inliner? Cheers, Matt

2 1

RE: Implementing pattern synonym constructor signatures
by Simon Peyton Jones 16 Jan '18

16 Jan '18

0. Parsing. I wasn't actually able to find the code that parses pattern synonyms. Can someone point me in the right direction? Parser.y line 1356, production ‘patteron_synonym_decl’ looks plausible. Currently we have data HsPatSynDir id = Unidirectional | ImplicitBidirectional | ExplicitBidirectional (MatchGroup id (LHsExpr id)) so in the bidirectional case all we have a MatchGroup, built with mkPatSynMatchGroup. To serve the proposal we need an optional signature in there too. 1. When there is a constructor signature, it needs to be used for the construction function instead of the pattern signature. Can someone give point me in the right direction about how to do this? TcPatSyn.tcPatSynBuilderBind is a good place to start. 2. When there is a constructor signature but no pattern signature, what should we do? I think "give up" sounds okay for now. I don’t understand. Can you give an example? Simon From: David Feuer [mailto:david@well-typed.com] Sent: 15 January 2018 19:11 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: ghc-devs(a)haskell.org Subject: Implementing pattern synonym constructor signatures Over the past week I've started digging into the code that implements pattern synonyms with an eye toward implementing the pattern synonym construction function signature proposal. I think I understand a decent amount of what's going on most places. However, I don't understand enough about type checking to have any idea about what needs to change where or how. There are several things that need to be addressed: 0. Parsing. I wasn't actually able to find the code that parses pattern synonyms. Can someone point me in the right direction? 1. When there is a constructor signature, it needs to be used for the construction function instead of the pattern signature. Can someone give point me in the right direction about how to do this? 2. When there is a constructor signature but no pattern signature, what should we do? I think "give up" sounds okay for now. 3. A pattern synonym without a constructor signature needs to be treated as it is today, so the machinery for matching things up needs to remain available. David Feuer Well-Typed, LLP

2 1

Implementing pattern synonym constructor signatures
by David Feuer 16 Jan '18

16 Jan '18

Over the past week I've started digging into the code that implements pattern synonyms with an eye toward implementing the pattern synonym construction function signature proposal. I think I understand a decent amount of what's going on most places. However, I don't understand enough about type checking to have any idea about what needs to change where or how. There are several things that need to be addressed: 0. Parsing. I wasn't actually able to find the code that parses pattern synonyms. Can someone point me in the right direction? 1. When there is a constructor signature, it needs to be used for the construction function instead of the pattern signature. Can someone give point me in the right direction about how to do this? 2. When there is a constructor signature but no pattern signature, what should we do? I think "give up" sounds okay for now. 3. A pattern synonym without a constructor signature needs to be treated as it is today, so the machinery for matching things up needs to remain available. David FeuerWell-Typed, LLP

2 3

pattern signatures
by Richard Eisenberg 10 Jan '18

10 Jan '18

Hi devs, Is a pattern signature a) something you put after `pattern P ::` ? b) something you put after `::` in a pattern, as in `foo (Proxy :: Proxy a)` ? I've seen the term "pattern signature" apply to both, and I've been tripped up by this. Does anyone have terminology that unambiguously separates these two constructs that we can all adopt? Thanks! Richard

7 7

Backing up and downloading Trac contents?
by Niklas Hambüchen 07 Jan '18

07 Jan '18

Working on something today, it came to my mind how much useful information is stored in Trac and how much time would get lost if it went down, corrupted or missing. With the source code there's no such issue as with git being a DVCS, everybody has the full history. But not so with Trac. Are there backups of Trac? Are there some publicly available ones that one could download and thus conveniently use offline? Thanks!

3 2

Spectre mitigation
by Demi Obenour 06 Jan '18

06 Jan '18

The recent “Spectre” bug requires that speculative execution of indirect branches be disabled. For GHC, this will require passing a flag to LLVM and fixing the NCG to emit suitable calling sequences. This will be a disaster for the STG execution model, because it disables CPU branch prediction for indirect calls and jumps. This is a big argument in favor of doing a CPS→SSA conversion in the backend.

5 9

Can't push to staging area?
by Bartosz Nitka 05 Jan '18

05 Jan '18

I'm trying to update a diff and I run into this: $ arc diff Linting... LINT OKAY No lint problems. Running unit tests... No unit test engine is configured for this project. PUSH STAGING Pushing changes to staging area... sudo: a password is required fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. STAGING FAILED Unable to push changes to the staging area. Usage Exception: Failed to push changes to staging area. Correct the issue, or use --skip-staging to skip this step. I believe that it worked for me before with my setup, and I seem to be in compliance with https://ghc.haskell.org/trac/ghc/wiki/Phabricator#Startingoff:Fixingabugsub… Any ideas? Thanks, Bartosz

4 6