Re: Hadrian
Hi, two things. a) why a git subtree if we keep working on github with hadrian, wouldn't that imply using a submodule? We use submodules for all the other ghc boot libs that are not part of the tree and are developed on github as well, no? As far as I understand a subtree, it's essentially integrating everything into the main tree. So this looks more like the submodule to subtree conversion, when hadrian development is switched over to phabricator? b) should we really hardcode the full url to hadrian tickets? wouldn't hadrian/#xxx suffice? Assuming for a moment hadrian would move into the github.com/haskell org or something, while the linkes would likely (due to githubs url redirection) keep on working, until someone recreates a snowleopard/hardian repo, but not necessarily correct anymore. Anyway, let's do this now rather than later. Cheers, moritz > On Oct 20, 2017, at 7:06 AM, Andrey Mokhov > wrote: > > Hi Ben, > >> Well, the GitHub repo will still exist. Is that enough? > > Yes, but I think I'll need to do some clean up in the code so that it's > obvious where to look for answers. For example, here is a random comment from > a Hadrian source file: > > -- Objdump is only required on OpenBSD and AIX, as mentioned in #211. > > The reader might confuse this with GHC ticket #211, so I guess this should be > replaced with a full link https://github.com/snowleopard/hadrian/issues/211. > There may be other potential pitfalls, but hopefully nothing difficult to > handle. > > I've created an issue to discuss and prepare for the merge: > https://github.com/snowleopard/hadrian/issues/440. > > Cheers, > Andrey > > -Original Message- > From: Ben Gamari [mailto:b...@well-typed.com] > Sent: 19 October 2017 21:50 > To: Andrey Mokhov ; Boespflug, Mathieu > > Cc: Jonas Pfenniger Chevalier ; Manuel M T > Chakravarty ; ghc-devs > Subject: RE: Hadrian > > Andrey Mokhov writes: > >> Thanks Ben, >> >> Just to clarify: By history I mean not just commits, but GitHub issues >> and PRs as well -- together they contain a lot of valuable interlinked >> information for GHC/Hadrian developers. >> > Well, the GitHub repo will still exist. Is that enough? > > Cheers, > > - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Hadrian
Hi Ben, > Well, the GitHub repo will still exist. Is that enough? Yes, but I think I'll need to do some clean up in the code so that it's obvious where to look for answers. For example, here is a random comment from a Hadrian source file: -- Objdump is only required on OpenBSD and AIX, as mentioned in #211. The reader might confuse this with GHC ticket #211, so I guess this should be replaced with a full link https://github.com/snowleopard/hadrian/issues/211. There may be other potential pitfalls, but hopefully nothing difficult to handle. I've created an issue to discuss and prepare for the merge: https://github.com/snowleopard/hadrian/issues/440. Cheers, Andrey -Original Message- From: Ben Gamari [mailto:b...@well-typed.com] Sent: 19 October 2017 21:50 To: Andrey Mokhov ; Boespflug, Mathieu Cc: Jonas Pfenniger Chevalier ; Manuel M T Chakravarty ; ghc-devs Subject: RE: Hadrian Andrey Mokhov writes: > Thanks Ben, > > Just to clarify: By history I mean not just commits, but GitHub issues > and PRs as well -- together they contain a lot of valuable interlinked > information for GHC/Hadrian developers. > Well, the GitHub repo will still exist. Is that enough? Cheers, - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Hadrian
Andrey Mokhov writes: > Thanks Ben, > > Just to clarify: By history I mean not just commits, but GitHub issues > and PRs as well -- together they contain a lot of valuable interlinked > information for GHC/Hadrian developers. > Well, the GitHub repo will still exist. Is that enough? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Hadrian
Thanks Ben, Just to clarify: By history I mean not just commits, but GitHub issues and PRs as well -- together they contain a lot of valuable interlinked information for GHC/Hadrian developers. > That is pretty much precisely the use-case which > git subtree was designed to address. This will allow us to have Hadrian, > with history, in the GHC tree and you can continue to develop it on > GitHub until things have stabilized. Sounds great. I haven't used git subtrees before, so I'll need to do some reading, but if everyone is happy with merging Hadrian as is, I can prepare a patch over the weekend! Cheers, Andrey -Original Message- From: Ben Gamari [mailto:b...@well-typed.com] Sent: 19 October 2017 20:50 To: Andrey Mokhov ; Boespflug, Mathieu Cc: Manuel M T Chakravarty ; Moritz Angermann ; Jonas Pfenniger Chevalier ; ghc-devs Subject: RE: Hadrian Andrey Mokhov writes: > Hi Mathieu, > > Yes, in principle we can merge right now, as long as it's clear that Hadrian > still requires more work before taking over. > > My only concern is that merging will make it more difficult for us to > quickly iterate on Hadrian: the GitHub workflow is more convenient (at > least for me) than the Phabricator one. Perhaps, we can keep Hadrian > on GitHub as a submodule? This also has the advantage that we can keep > all existing references to GitHub issues/PRs without migrating > everything to GHC Trac. It would be very unfortunate to lose all > history during the merge. > Okay, so if we want to preserve history then I would suggest that we go the subtree route. That is pretty much precisely the use-case which git subtree was designed to address. This will allow us to have Hadrian, with history, in the GHC tree and you can continue to develop it on GitHub until things have stabilized. The only question is how to ensure that the subtree remains up-to-date. Cheers, - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Hadrian
Andrey Mokhov writes: > Hi Mathieu, > > Yes, in principle we can merge right now, as long as it's clear that Hadrian > still requires more work before taking over. > > My only concern is that merging will make it more difficult for us to > quickly iterate on Hadrian: the GitHub workflow is more convenient (at > least for me) than the Phabricator one. Perhaps, we can keep Hadrian > on GitHub as a submodule? This also has the advantage that we can keep > all existing references to GitHub issues/PRs without migrating > everything to GHC Trac. It would be very unfortunate to lose all > history during the merge. > Okay, so if we want to preserve history then I would suggest that we go the subtree route. That is pretty much precisely the use-case which git subtree was designed to address. This will allow us to have Hadrian, with history, in the GHC tree and you can continue to develop it on GitHub until things have stabilized. The only question is how to ensure that the subtree remains up-to-date. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Hadrian
Hi Mathieu, Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over. My only concern is that merging will make it more difficult for us to quickly iterate on Hadrian: the GitHub workflow is more convenient (at least for me) than the Phabricator one. Perhaps, we can keep Hadrian on GitHub as a submodule? This also has the advantage that we can keep all existing references to GitHub issues/PRs without migrating everything to GHC Trac. It would be very unfortunate to lose all history during the merge. Cheers, Andrey -Original Message- From: Boespflug, Mathieu [mailto:m...@tweag.io] Sent: 19 October 2017 19:21 To: Andrey Mokhov Cc: Ben Gamari ; Manuel M T Chakravarty ; Moritz Angermann ; Jonas Pfenniger Chevalier ; ghc-devs Subject: Re: Hadrian Hi all, As a user who tried to be an early adopter of Hadrian, I can attest to Andrey's remarks about GHC progress sometimes (frequently?) breaking Hadrian. Ben, Andrey - how about this strawman proposal: we merge Hadrian into GHC *now*, not because ./validate with Hadrian works (it doesn't yet), but because the build of GHC succeeds with Hadrian. The resulting compiler might well be garbage. But that's fine - we can iterate in the official ghc repo, all the while knowing that CI has our back if ever some change makes Hadrian no longer even build a compiler. Once ./validate passes with Hadrian, the guarantee that CI gives will become stronger still: we'll know if any change would make the Hadrian-produced compiler garbage again. Maybe that does sound totally bonkers to you? :) Maybe it's radical, but sounds to me like the best way to get the benefit *now* of ensuring Make and Hadrian move forward in lock step thanks to CI. The above all assumes that we're committed to Hadrian being the future of GHC's build system. But I take it that's a given by now. Best, Mathieu On 19 October 2017 at 19:05, Andrey Mokhov wrote: > Hi Ben, Manuel and all, > > Ben has already covered most questions in his answer, but let me add a couple > of comments. > >> So, Mathieu had the clever idea that having the two build system in >> GHC side-by-side and then build in CI both ways might be a good way of >> making sure that keep constant tabs on Hadian and get a clear (and >> continuous picture) of where it is and what is missing. > > It would be great to build every GHC commit both by Make and Hadrian. Not > only this would allow to monitor the readiness of Hadrian, it would also make > it easier for us to catch up with changes in GHC and the Make build system. > At the moment, Hadrian is frequently broken by changes in GHC/Make and we > need to do detective work of figuring out which commit broke what and fix > Hadrian accordingly. These fixes are trivial in many cases (e.g. adding a new > flag to one of the builders) so GHC developers would probably be able to > easily mirror these changes in Hadrian if only their commits were marked as > Hadrian-breaking by the common CI. > >> In other words, why can’t we have Hadrian *today*? > > I'd say the biggest issue is #299 -- i.e. making sure that the GHC built by > Hadrian passes validation. At the moment we still have 100-200 unexpected > failures, most of which probably have to do with outdated command line flags > (GHC's build system continuously evolves and it wasn't possible to keep track > of all flag changes over time, so there are certainly some differences in > Hadrian that lead to validation failures). This is where help is currently > needed. > > Cheers, > Andrey > > -Original Message- > From: Ben Gamari [mailto:b...@well-typed.com] > Sent: 19 October 2017 15:08 > To: Manuel M T Chakravarty > Cc: Mathieu Boespflug ; Moritz Angermann > ; Jonas Pfenniger Chevalier > ; Andrey Mokhov > Subject: Re: Hadrian > > CCing Andrey and Zhen, who are the principle authors of Hadrian. > > Manuel M T Chakravarty writes: > >> Hi Ben, >> >> I our exploration of cross-compilation for GHC and the CI integration, >> we talked with Moritz and got to the topic of Hadrian. It seems that >> there are few interdependent issues here, and I am really interested >> in getting your take on them. >> >> * Hadrian is slated for inclusion for 8.4, but I couldn’t find any >> tickets except #12599. Is this because Hadrian has its own issue >> tracker on GitHub? How can I get an overview over what’s missing in >> getting Hadrian into GHC? >> > Right, Hadrian tickets are currently tracked in its own issue tracker. > >> * For Moritz’ work on ARM and also for CI cross-compiling is >> important, but Moritz pointed out rightly that it seems wasteful put >> much time into improving this in the make-based build system if that >> is going to go soon anyway. However, because Hadrian is not in yet, >> doing the work on Hadrian now also doesn’t really make sense. >> > Indeed. Hadrian is one of the things I am currently working on for > precisely this reason. >
Re: Hadrian
"Boespflug, Mathieu" writes: > Hi all, > > As a user who tried to be an early adopter of Hadrian, I can attest to > Andrey's remarks about GHC progress sometimes (frequently?) breaking > Hadrian. > > Ben, Andrey - how about this strawman proposal: > > we merge Hadrian into GHC *now*, not because ./validate with Hadrian > works (it doesn't yet), but because the build of GHC succeeds with > Hadrian. The resulting compiler might well be garbage. But that's fine > - we can iterate in the official ghc repo, all the while knowing that > CI has our back if ever some change makes Hadrian no longer even build > a compiler. Once ./validate passes with Hadrian, the guarantee that CI > gives will become stronger still: we'll know if any change would make > the Hadrian-produced compiler garbage again. > > Maybe that does sound totally bonkers to you? :) Maybe it's radical, > but sounds to me like the best way to get the benefit *now* of > ensuring Make and Hadrian move forward in lock step thanks to CI. > > The above all assumes that we're committed to Hadrian being the future > of GHC's build system. But I take it that's a given by now. > That's not so different from my existing plan, which is to import Hadrian after 8.2.2. That being said, if it's okay with Andrey to import now then it is also okay with me. There are, of course some details to be worked out: do we import hadrian as a git subtree, retaining history, or simply squash a snapshot? Where should tickets now be filed from now on? Should we move the scripts in the top-level of the hadrian repo to the top-level of the GHC repo? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Hadrian
Hi all, As a user who tried to be an early adopter of Hadrian, I can attest to Andrey's remarks about GHC progress sometimes (frequently?) breaking Hadrian. Ben, Andrey - how about this strawman proposal: we merge Hadrian into GHC *now*, not because ./validate with Hadrian works (it doesn't yet), but because the build of GHC succeeds with Hadrian. The resulting compiler might well be garbage. But that's fine - we can iterate in the official ghc repo, all the while knowing that CI has our back if ever some change makes Hadrian no longer even build a compiler. Once ./validate passes with Hadrian, the guarantee that CI gives will become stronger still: we'll know if any change would make the Hadrian-produced compiler garbage again. Maybe that does sound totally bonkers to you? :) Maybe it's radical, but sounds to me like the best way to get the benefit *now* of ensuring Make and Hadrian move forward in lock step thanks to CI. The above all assumes that we're committed to Hadrian being the future of GHC's build system. But I take it that's a given by now. Best, Mathieu On 19 October 2017 at 19:05, Andrey Mokhov wrote: > Hi Ben, Manuel and all, > > Ben has already covered most questions in his answer, but let me add a couple > of comments. > >> So, Mathieu had the clever idea that having the two build system in >> GHC side-by-side and then build in CI both ways might be a good way of >> making sure that keep constant tabs on Hadian and get a clear (and >> continuous picture) of where it is and what is missing. > > It would be great to build every GHC commit both by Make and Hadrian. Not > only this would allow to monitor the readiness of Hadrian, it would also make > it easier for us to catch up with changes in GHC and the Make build system. > At the moment, Hadrian is frequently broken by changes in GHC/Make and we > need to do detective work of figuring out which commit broke what and fix > Hadrian accordingly. These fixes are trivial in many cases (e.g. adding a new > flag to one of the builders) so GHC developers would probably be able to > easily mirror these changes in Hadrian if only their commits were marked as > Hadrian-breaking by the common CI. > >> In other words, why can’t we have Hadrian *today*? > > I'd say the biggest issue is #299 -- i.e. making sure that the GHC built by > Hadrian passes validation. At the moment we still have 100-200 unexpected > failures, most of which probably have to do with outdated command line flags > (GHC's build system continuously evolves and it wasn't possible to keep track > of all flag changes over time, so there are certainly some differences in > Hadrian that lead to validation failures). This is where help is currently > needed. > > Cheers, > Andrey > > -Original Message- > From: Ben Gamari [mailto:b...@well-typed.com] > Sent: 19 October 2017 15:08 > To: Manuel M T Chakravarty > Cc: Mathieu Boespflug ; Moritz Angermann > ; Jonas Pfenniger Chevalier > ; Andrey Mokhov > Subject: Re: Hadrian > > CCing Andrey and Zhen, who are the principle authors of Hadrian. > > Manuel M T Chakravarty writes: > >> Hi Ben, >> >> I our exploration of cross-compilation for GHC and the CI integration, >> we talked with Moritz and got to the topic of Hadrian. It seems that >> there are few interdependent issues here, and I am really interested >> in getting your take on them. >> >> * Hadrian is slated for inclusion for 8.4, but I couldn’t find any >> tickets except #12599. Is this because Hadrian has its own issue >> tracker on GitHub? How can I get an overview over what’s missing in >> getting Hadrian into GHC? >> > Right, Hadrian tickets are currently tracked in its own issue tracker. > >> * For Moritz’ work on ARM and also for CI cross-compiling is >> important, but Moritz pointed out rightly that it seems wasteful put >> much time into improving this in the make-based build system if that >> is going to go soon anyway. However, because Hadrian is not in yet, >> doing the work on Hadrian now also doesn’t really make sense. >> > Indeed. Hadrian is one of the things I am currently working on for > precisely this reason. > >> * Obviously, one issue with Hadrian is stability and feature >> completeness. This has ramifications on our desire to really get 8.4 >> out of the door in February and not delay the release and also get the >> CI done, because good CI is the best way of making sure the Hadrian >> integration goes smoothly. (There is obviously a cyclic dependence >> between this point and the previous.) >> >> So, Mathieu had the clever idea that having the two build system in >> GHC side-by-side and then build in CI both ways might be a good way of >> making sure that keep constant tabs on Hadian and get a clear (and >> continuous picture) of where it is and what is missing. It would also >> allow Moritz to do cross-compilation work right there on Hadrian. >> >> In other words, why can’t we have Hadrian *today*? >> > At this point the plan is
Re: Determine instance method from class method callsite
I have the same problem with a compiler plugin that I am writing.
In GHC Core I need to get from a dict-fun identifier (e.g.
$fMyClassDouble to the type class instance bindr (starting with $c).
lookupInstEnv from the InstEnv module seemed to do it, but it seems to
look up the matching key from a set of instEnv keys and not anything
that contains the instance bindr. Not sure.
Where is the dictionary lookup that gives me the bindr?
What I did so far:
evalExpr :: DynFlags -> ModGuts -> CoreExpr -> Var -> CoreM NodeType
evalExpr dflags guts (Var iD) v = do
hsc_env <- getHscEnv
eps <- liftIO (hscEPS hsc_env)
let instEnvs = InstEnvs (eps_inst_env eps)
(mg_inst_env guts)
(mkModuleSet (dep_orphs (mg_deps guts)))
let ty = tyConAppTyCon_maybe (idType iD)
let cl = fromJust (tyConClass_maybe (fromJust ty))
let tys = snd (splitTyConApp (idType iD))
let (matches,_,_) | isDictId iD = lookupInstEnv False instEnvs cl tys
| otherwise = ([],[],[])
let inst = map (nameStableString . varName . is_dfun . fst) matches
liftIO $ B.appendFile ("debug.txt") (B.pack (show inst))
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Compiling natively GHC for ARMv7l softabi
October 19, .00µ2017 6:.00ÿ8 PM, "Moritz Angermann" wrote: > Shiftag, > > any chance you could try this with 8.2 again then? > Hi, I'm going to try that and I will let you know ;) Thanks guys. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Compiling natively GHC for ARMv7l softabi
Shiftag, any chance you could try this with 8.2 again then? Cheers, Moritz > On Oct 19, 2017, at 9:56 PM, Ben Gamari wrote: > > Moritz Angermann writes: > >> Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even >> make it to the assembly stage... >> > This was a known bug in 8.0. See #11784. IIRC I fixed it for 8.2. > > Cheers, > > - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Compiling natively GHC for ARMv7l softabi
Moritz Angermann writes: > Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even > make it to the assembly stage... > This was a known bug in 8.0. See #11784. IIRC I fixed it for 8.2. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Compiling natively GHC for ARMv7l softabi
October 19, 2017 11:52 AM, "Moritz Angermann" wrote: > Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even > make it to the assembly > stage... > >> On Oct 19, 2017, at 3:32 PM, shif...@nanotek.info wrote: >> >> October 19, 2017 10:34 AM, "Moritz Angermann" >> wrote: >> >> "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist >> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header >> -Irts -Irts/dist/build >> -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts >> -irts/dist/build >> -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c >> rts/StgStartup.cmm -o >> rts/dist/build/StgStartup.o >>> run this with `-v`, to check the invorcations. I'm pretty certain some >>> flags to opt/llc are >>> missing/wrong here. >> >> Ok :) >> >> Please see below : >> >> $ inplace/bin/ghc-stage1 -v -static -H32m -O -Wall -Iincludes -Iincludes/dist >> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header >> -Irts -Irts/dist/build >> -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts >> -irts/dist/build >> -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c >> rts/StgStartup.cmm -o >> rts/dist/build/StgStartup.o >> Glasgow Haskell Compiler, Version 8.0.2, stage 1 booted by GHC version 8.0.2 >> Using binary package database: >> /tmp/ghc-8.0.2/inplace/lib/package.conf.d/package.cache >> loading package database /tmp/ghc-8.0.2/inplace/lib/package.conf.d >> wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 >> wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 >> wired-in package base mapped to base-4.9.1.0 >> wired-in package rts mapped to rts >> wired-in package template-haskell mapped to template-haskell-2.11.1.0 >> wired-in package ghc mapped to ghc-8.0.2 >> wired-in package dph-seq not found. >> wired-in package dph-par not found. >> Hsc static flags: >> Created temporary directory: /tmp/ghc25166_0 >> *** C Compiler: >> /usr/bin/arm-linux-gnueabi-gcc -marm -fno-stack-protector >> -DTABLES_NEXT_TO_CODE -DNOSMP -E -I >> includes -I includes/dist -I includes/dist-derivedconstants/header -I >> includes/dist-ghcconstants/header -I rts -I rts/dist/build -I rts/dist/build >> -I >> rts/dist/build/autogen -I /tmp/ghc-8.0.2/libraries/base/include -I >> /tmp/ghc-8.0.2/libraries/integer-gmp/include -I >> /tmp/ghc-8.0.2/rts/dist/build -I >> /tmp/ghc-8.0.2/includes -I >> /tmp/ghc-8.0.2/includes/dist-derivedconstants/header >> '-D__GLASGOW_HASKELL__=800' -include /tmp/ghc-8.0.2/includes/ghcversion.h >> '-Dlinux_BUILD_OS=1' >> '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' '-Darm_HOST_ARCH=1' >> '-D__GLASGOW_HASKELL_LLVM__=307' >> '-D__GLASGOW_HASKELL_TH__=0' -include/tmp/ghc25166_0/ghc_2.h -x >> assembler-with-cpp >> rts/StgStartup.cmm -o /tmp/ghc25166_0/ghc_1.cmmcpp >> *** ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]: >> !!! ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]: finished in 4.00 milliseconds, >> allocated 2.082 >> megabytes >> *** LLVM CodeGen: >> *** LLVM CodeGen: >> Using LLVM version: (3,7) >> *** Deleting temp files: >> Deleting: /tmp/ghc25166_0/ghc_5.c /tmp/ghc25166_0/ghc_4.ll >> /tmp/ghc25166_0/ghc_3.rsp >> /tmp/ghc25166_0/ghc_2.h /tmp/ghc25166_0/ghc_1.cmmcpp >> Warning: deleting non-existent /tmp/ghc25166_0/ghc_5.c >> *** Deleting temp dirs: >> Deleting: /tmp/ghc25166_0 >> ghc-stage1: panic! (the 'impossible' happened) >> (GHC version 8.0.2 for arm-unknown-linux): >> hscCmmFile: no_mod >> >> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug For your information : # ./configure --target=arm-linux-gnueabi --with-ld=arm-linux-gnueabi [...] -- Configure completed successfully. Building GHC version : 8.0.2 Git commit id : 8c7250379d0d2bad1d07dfd556812ff7aa2c42e8 Build platform: x86_64-unknown-linux Host platform : x86_64-unknown-linux Target platform : arm-unknown-linux Bootstrapping using : /usr/bin/ghc which is version : 8.0.2 Using gcc : /usr/bin/arm-linux-gnueabi-gcc which is version : 7.2.0 Building a cross compiler : YES hs-cpp : /usr/bin/arm-linux-gnueabi-gcc hs-cpp-flags : -E -undef -traditional ld : /usr/bin/arm-linux-gnueabi-ld.gold nm : /usr/bin/arm-linux-gnueabi-nm objdump : /usr/bin/arm-linux-gnueabi-objdump Happy: /usr/bin/happy (1.19.7) Alex : /usr/bin/alex (3.2.3) Perl : /usr/bin/perl sphinx-build : /usr/bin/sphinx-build xelatex : Using LLVM tools llc : /usr/bin/llc opt : /usr/bin/opt HsColour : /usr/bin/HsColour Tools to build Sphinx HTML documentation available: YES Tools to build Sphinx PDF documentation available: NO -- # grep -v '#' build.mk | sed '
[ANN] GHC DevOps Group
We announced the GHC DevOps Group at the Haskell Implementors’ Workshop in Oxford earlier this year in Simon PJ’s ”Progress on GHC” session. (The videos are unfortunately not yet online.) To finally announce it more broadly, I wrote a blog post: http://www.tweag.io/posts/2017-10-19-ghc-devops-group.html Cheers, Manuel ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC HEAD now needs extra tools to build libffi?
Hi, As it turns out this might be linker madness. I do not yet understand why this did work with the "old" libffi though. The command that fails is a rather long gcc invocation asking it to link a bunch of libraries together. $ gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-fuse-ld=gold' [...] -lHSghci-8.3-ghc8.3.20171018 [...] -lffi [...] From the error message, we know taht ghci depends on libffi. E.g. > libHSghci-8.3-ghc8.3.20171018.so: error: undefined reference to 'ffi_prep_cif' Now there are two possible configurations that do (successfully) link on my test machine: 1.) Droppping `-fuse-ld=gold`. 2.) Moving `-lffi` prior to `-lHSghci-8.3-ghc8.3.20171018`. I guess we could also add the libffi symbols the the other -Wl,-u,... symbols. Obviously I would not see this on macOS, as there is no go.ld on macOS. On my ubuntu system, gold is > GNU gold (GNU Binutils for Ubuntu 2.27) 1.12 Again, as I stated in the beginning, I fail to understand why this should related to the new libffi version. As such running `LD=ld ./configure && make -j` does indeed complete successfully on my machine. If someone has any idea what the core issue between the libffi update and these build failures is, I'd be happy to know! Cheers, Moritz > On Oct 18, 2017, at 11:38 PM, Joachim Breitner > wrote: > > Hi, > > it’s an Arch linux (generously sponsored by Richard’s university). I > have not idea how to give more precise information about the distro > release version or such :-) > > Greetings, > Joachim > > Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann: >> Hi, >> >> so this somehow looks like for a not yet absolutely clear reason to me, >> when building ghci, we fail to link in libffi, for some configurations. >> >> Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the >> compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well? >> I assume Ben bootstraps wit 8.2.1. >> >> I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this. >> >> Joachim, is perf.haskell.org running Ubuntu as well? >> >> Cheers, >> Moritz >> >>> On Oct 11, 2017, at 1:43 AM, Thomas Jakway wrote: >>> >>> Thanks for getting back to me. >>> >>> (I think you mean `git clean -x -f -d`): I usually omit -x but I'll give it >>> a go and report back. >>> >>> Before I got the issue on a clean checkout I thought it was something I did >>> to the build files. >>> >>> I also tried building the latest release of libffi (v3.2.1) and using it in >>> configure with --with-ffi-includes and --with-ffi-libraries but got the >>> same error. >>> >>> >>> On 10/09/2017 02:40 AM, Moritz Angermann wrote: Yes, this commit indeed introduced the need for makeinfo, however after some debugging and improved packaging of the external libffi library, this dependency was removed again, and should not be required with the latest head anymore. Then again this should not result in link issues but rather in build time issues. The key to libffi is the libffi-tarballs git submodule, which contains the packaged libffi-tarballs. Make sure all your submodules are also updated. I usually use `git -x -f -d` (read the documentation first) to ensure a clean working tree. Especially as you say you can’t reproduce it on other machines, maybe there is a file in your tree that the cleaning did not catch? Sent from my iPhone > On 9 Oct 2017, at 4:31 AM, Thomas Jakway wrote: > > I'm on Ubuntu 16.10. > > I ran git bisect: > > -- > > e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit > commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 > Author: Moritz Angermann > Date: Sat Sep 30 09:31:12 2017 -0400 > > Allow libffi snapshots > > This is rather annoying. I'd prefer to have a stable release to > use. However libffi-3.2.1 has been released November 12, 2014, and > libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296 > > The core reason for this change is that llvm changed the supported > assembly to unified syntax, which libffi-3.2.1 does not use, and hence > fails to compile for arm with llvm. For refence, see the following > issue: https://github.com/libffi/libffi/issues/191. > > This diff contains a script to generate a tarball for the > `libffi-tarballs` repository from the libffi GitHub repository; as well > as the necessary changes to the build system. > > Updates libffi-tarballs submodule. > > Reviewers: austin, bgamari, hvr > > Subscribers: hvr, erikd, rwbarton, thomie > > Differential Revision: https://phabricator.haskell.org/D3574 > > -- > > I can't reproduce it on my other linux computers though. > > >> On 10/04/2017 02:17 PM, Ben Gamari wrot
Re: Compiling natively GHC for ARMv7l softabi
Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even make it to the assembly stage... > On Oct 19, 2017, at 3:32 PM, shif...@nanotek.info wrote: > > October 19, 2017 10:34 AM, "Moritz Angermann" > wrote: > >>> "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist >>> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header >>> -Irts -Irts/dist/build >>> -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts >>> -irts/dist/build >>> -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c >>> rts/StgStartup.cmm -o >>> rts/dist/build/StgStartup.o >> >> run this with `-v`, to check the invorcations. I'm pretty certain some flags >> to opt/llc are >> missing/wrong here. > > > Ok :) > > Please see below : > > $ inplace/bin/ghc-stage1 -v -static -H32m -O -Wall -Iincludes > -Iincludes/dist -Iincludes/dist-derivedconstants/header > -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS > -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build > -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen > -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o > Glasgow Haskell Compiler, Version 8.0.2, stage 1 booted by GHC version 8.0.2 > Using binary package database: > /tmp/ghc-8.0.2/inplace/lib/package.conf.d/package.cache > loading package database /tmp/ghc-8.0.2/inplace/lib/package.conf.d > wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 > wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 > wired-in package base mapped to base-4.9.1.0 > wired-in package rts mapped to rts > wired-in package template-haskell mapped to template-haskell-2.11.1.0 > wired-in package ghc mapped to ghc-8.0.2 > wired-in package dph-seq not found. > wired-in package dph-par not found. > Hsc static flags: > Created temporary directory: /tmp/ghc25166_0 > *** C Compiler: > /usr/bin/arm-linux-gnueabi-gcc -marm -fno-stack-protector > -DTABLES_NEXT_TO_CODE -DNOSMP -E -I includes -I includes/dist -I > includes/dist-derivedconstants/header -I includes/dist-ghcconstants/header -I > rts -I rts/dist/build -I rts/dist/build -I rts/dist/build/autogen -I > /tmp/ghc-8.0.2/libraries/base/include -I > /tmp/ghc-8.0.2/libraries/integer-gmp/include -I /tmp/ghc-8.0.2/rts/dist/build > -I /tmp/ghc-8.0.2/includes -I > /tmp/ghc-8.0.2/includes/dist-derivedconstants/header > '-D__GLASGOW_HASKELL__=800' -include /tmp/ghc-8.0.2/includes/ghcversion.h > '-Dlinux_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' > '-Darm_HOST_ARCH=1' '-D__GLASGOW_HASKELL_LLVM__=307' > '-D__GLASGOW_HASKELL_TH__=0' -include/tmp/ghc25166_0/ghc_2.h -x > assembler-with-cpp rts/StgStartup.cmm -o /tmp/ghc25166_0/ghc_1.cmmcpp > *** ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]: > !!! ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]: finished in 4.00 milliseconds, > allocated 2.082 megabytes > *** LLVM CodeGen: > *** LLVM CodeGen: > Using LLVM version: (3,7) > *** Deleting temp files: > Deleting: /tmp/ghc25166_0/ghc_5.c /tmp/ghc25166_0/ghc_4.ll > /tmp/ghc25166_0/ghc_3.rsp /tmp/ghc25166_0/ghc_2.h /tmp/ghc25166_0/ghc_1.cmmcpp > Warning: deleting non-existent /tmp/ghc25166_0/ghc_5.c > *** Deleting temp dirs: > Deleting: /tmp/ghc25166_0 > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 8.0.2 for arm-unknown-linux): > hscCmmFile: no_mod > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Compiling natively GHC for ARMv7l softabi
October 19, 2017 10:34 AM, "Moritz Angermann" wrote: >> "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist >> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header >> -Irts -Irts/dist/build >> -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts >> -irts/dist/build >> -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c >> rts/StgStartup.cmm -o >> rts/dist/build/StgStartup.o > > run this with `-v`, to check the invorcations. I'm pretty certain some flags > to opt/llc are > missing/wrong here. Ok :) Please see below : $ inplace/bin/ghc-stage1 -v -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o Glasgow Haskell Compiler, Version 8.0.2, stage 1 booted by GHC version 8.0.2 Using binary package database: /tmp/ghc-8.0.2/inplace/lib/package.conf.d/package.cache loading package database /tmp/ghc-8.0.2/inplace/lib/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Created temporary directory: /tmp/ghc25166_0 *** C Compiler: /usr/bin/arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE -DNOSMP -E -I includes -I includes/dist -I includes/dist-derivedconstants/header -I includes/dist-ghcconstants/header -I rts -I rts/dist/build -I rts/dist/build -I rts/dist/build/autogen -I /tmp/ghc-8.0.2/libraries/base/include -I /tmp/ghc-8.0.2/libraries/integer-gmp/include -I /tmp/ghc-8.0.2/rts/dist/build -I /tmp/ghc-8.0.2/includes -I /tmp/ghc-8.0.2/includes/dist-derivedconstants/header '-D__GLASGOW_HASKELL__=800' -include /tmp/ghc-8.0.2/includes/ghcversion.h '-Dlinux_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' '-Darm_HOST_ARCH=1' '-D__GLASGOW_HASKELL_LLVM__=307' '-D__GLASGOW_HASKELL_TH__=0' -include/tmp/ghc25166_0/ghc_2.h -x assembler-with-cpp rts/StgStartup.cmm -o /tmp/ghc25166_0/ghc_1.cmmcpp *** ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]: !!! ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]: finished in 4.00 milliseconds, allocated 2.082 megabytes *** LLVM CodeGen: *** LLVM CodeGen: Using LLVM version: (3,7) *** Deleting temp files: Deleting: /tmp/ghc25166_0/ghc_5.c /tmp/ghc25166_0/ghc_4.ll /tmp/ghc25166_0/ghc_3.rsp /tmp/ghc25166_0/ghc_2.h /tmp/ghc25166_0/ghc_1.cmmcpp Warning: deleting non-existent /tmp/ghc25166_0/ghc_5.c *** Deleting temp dirs: Deleting: /tmp/ghc25166_0 ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.0.2 for arm-unknown-linux): hscCmmFile: no_mod Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
