Build reproducibility of gcc @ NixOS
Dear GCC development team, We've been trying to build reproducibly the minimal NixOS image, and gcc was one of the last issues we had. We found that disabling profiled bootstrap compilation of GCC allowed us to get a reproducible build of gcc. Our efforts can be followed here: https://github.com/NixOS/nixpkgs/pull/112928 But I measured disabling this optimization to cost around 7-12% depending on the build. Because of this performance regression, we're trying to find a middle ground. Ideally we'd like to keep the performance of gcc as untouched as possible (even if that costs us on compilation time of gcc itself). Compiling gcc twice on the same machine gets us the same output, but compiling on a different architecture gets us a different result. Reading the documentation, it would seem that autoprofiledback bootstrap would use machine metrics and injects them in the build (and we don't use autoprofiledback), But I would not expect the stagetrain of profiledbootstrap to do that. I tried disabling concurrency of the stagetrain without luck. It feels like I'm missing something. Would anyone have any idea what could inject the host's behavior here? Thank you for your help! Best, -- Arthur
gcc-8-20210401 is now available
Snapshot gcc-8-20210401 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20210401/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision 530567da49fbbde99f22fb18a2919c6d705292dc You'll find: gcc-8-20210401.tar.xzComplete GCC SHA256=230bf09639d725fa188d3d5c60f239cd03a2dad052c5930878ac27f61b20e85c SHA1=6b80c54f819ca22eead6fc7c27144d04e1436f4b Diffs from 8-20210325 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Remove RMS from the GCC Steering Committee
> If RMS had ever done the same (pretty unlikely, Fortran isnt't his > thing), I would have done the same without thinking twice about it. I agree with that sentiment. The fact that somebody has a certain role doesn't necessarily mean that the question is asked with that hat on: it may be nothing more than curiousity.
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
I bootstrap built and tested for powerpc 64 on power 7 and 8 BE and power 8, 9, and 10 LE and I saw nothing unexpected. On 4/1/21 7:35 AM, Richard Biener wrote: The first release candidate for GCC 10.3 is available from https://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/ ftp://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/ and shortly its mirrors. It has been generated from git commit 892024d4af83b258801ff7484bf28f0cf1a1a999. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 10.3 on Thursday, April 8th.
Re: Remove RMS from the GCC Steering Committee
On 01.04.21 22:33, Joseph Myers wrote: And while in that case RMS probably learned of modules and libcody through the SC mailing list, in general he has this habit of asking GNU package developers random questions related to their packages. I've been asked a few questions about gfortran by random people, which I have always tried to answer correctly and courteously, with a copy to the relevant mailing list. If RMS had ever done the same (pretty unlikely, Fortran isnt't his thing), I would have done the same without thinking twice about it.
Re: Remove RMS from the GCC Steering Committee
On 4/1/21 10:33 PM, Joseph Myers wrote: RMS once asked me about the status of fused multiply-add support in glibc. I don't know why. He wasn't asking for any changes or objecting to anything the glibc maintainers had done. I'd hope that future Chief GNUisances won't try to get involved in details like that as part of their role as Chief GNUisance, because it's clearly outside the scope of such a role, and that if interested in such details as an individual free software developer (but not directly involved in development of the package in question) they will do more research of their own first and then approach the usual public mailing lists or other public discussion areas rather than individual developers. So what? He asked you. I don't know why he asked and I don't see a bad intent in it. This bashing is getting ridiculous now... regards, chris
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On Thu, Apr 01, 2021 at 08:49:19PM +0100, Jonathan Wakely via Gcc wrote: > On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote: > > > > Richard Biener wrote: > > > > > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou > > > wrote: > > >>> I have so far bootstrapped and tested the release candidate on > > >>> x86_64-linux. Please test it and report any issues to bugzilla. > > > > On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails. > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 > > I missed a backport, this is needed for gcc-10 branch: > https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r11-7239 > Only affects the testsuite, but in a util header that is used by lots of > tests. > > I'll wait for RM approval before pushing the backport. Ok. Jakub
Re: Remove RMS from the GCC Steering Committee
On Thu, 1 Apr 2021, Ian Lance Taylor via Gcc wrote: > > 2) Last year, I asked for libcody to be added as a subcomponent, with > > its Apachev2 license intact. AFAICT RMS was involved in that licensing > > discussion, /for which I never received a response/. He was not at the > > FSF then, so he could not render any FSF licensing opinion. Why was he > > involved? If he was not involved, how did he learn of it in order to > > ask me questions about C++ modules? I only emailed the SC and the > > timing is too coincidental to draw a different conclusion. > > Yes, we definitely dropped the ball on that. Sorry. If that ever > happens again I would encourage you to ping. > > I checked the mailing list archives. Jeff and I expressed support for > using libcody. Nobody else said anything. Certainly RMS didn't say > anything, and it would have been astonishing if he had. But, yes, he > was CC'ed. And while in that case RMS probably learned of modules and libcody through the SC mailing list, in general he has this habit of asking GNU package developers random questions related to their packages. RMS once asked me about the status of fused multiply-add support in glibc. I don't know why. He wasn't asking for any changes or objecting to anything the glibc maintainers had done. I'd hope that future Chief GNUisances won't try to get involved in details like that as part of their role as Chief GNUisance, because it's clearly outside the scope of such a role, and that if interested in such details as an individual free software developer (but not directly involved in development of the package in question) they will do more research of their own first and then approach the usual public mailing lists or other public discussion areas rather than individual developers. -- Joseph S. Myers jos...@codesourcery.com
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On Thu, 1 Apr 2021 at 21:08, Richard Biener wrote: > > On April 1, 2021 9:49:19 PM GMT+02:00, Jonathan Wakely via Gcc > wrote: > >On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote: > >> > >> Richard Biener wrote: > >> > >> > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou > >> > wrote: > >> >>> I have so far bootstrapped and tested the release candidate on > >> >>> x86_64-linux. Please test it and report any issues to bugzilla. > >> > >> On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails. > >> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 > > > >I missed a backport, this is needed for gcc-10 branch: > >https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r11-7239 > >Only affects the testsuite, but in a util header that is used by lots > >of tests. > > > >I'll wait for RM approval before pushing the backport. > > This is OK. Pushed, thanks.
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On April 1, 2021 9:49:19 PM GMT+02:00, Jonathan Wakely via Gcc wrote: >On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote: >> >> Richard Biener wrote: >> >> > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou >> > wrote: >> >>> I have so far bootstrapped and tested the release candidate on >> >>> x86_64-linux. Please test it and report any issues to bugzilla. >> >> On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails. >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 > >I missed a backport, this is needed for gcc-10 branch: >https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r11-7239 >Only affects the testsuite, but in a util header that is used by lots >of tests. > >I'll wait for RM approval before pushing the backport. This is OK. Richard.
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote: > > Richard Biener wrote: > > > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou > > wrote: > >>> I have so far bootstrapped and tested the release candidate on > >>> x86_64-linux. Please test it and report any issues to bugzilla. > > On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 I missed a backport, this is needed for gcc-10 branch: https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r11-7239 Only affects the testsuite, but in a util header that is used by lots of tests. I'll wait for RM approval before pushing the backport.
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
Richard Biener wrote: On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou wrote: I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Iain
Re: Remove RMS from the GCC Steering Committee
On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell wrote: > > You, the SC, have chosen to fix this as a clerical error. The most > do-nothing response, other than actually doing nothing. > > I am profoundly disappointed that you have not even acknowledged the > harm RMS has caused. Using passive voiced 'RMS was added' phrasing. > You're not explicitly saying that was incorrect, and neither are you > saying it was correct. Your language attempts to distance you from > your choices. > > 'we no longer feel the listing serves the best interest'. 'Therefore, > we are removing him from the page FULLSTOP'. Well, at least that's not > passive voice, but it is a milque-toast response. You're not removing > him from the SC, merely removing mention of him from the listing. > You're not adding words to the website mentioning this historical > ambiguity/error/misjudgement (you'd say if you were, right?). You're > not adding words acknowledging that RMS's involvement has been > detrimental and repelled contributors. Nor are you apologizing. You're > not owning your mistake. You just hope the problem will silently go > away. The problem will not go away. > > /You/ involved RMS in SC discussions. /You/ treated him as a member > thereof. /You/ gave him controlling rights. > > You have misled the majority of GCC developers, and the wider community > by doing so. If it looks like a duck, walks like a duck, and talks like > a duck, it's a duck. (As compiler developers for duck-typed languages, > you should understand that.) > > You involved RMS prior to 2012, and continued to do so after. Including > after 2019 when he was no longer at the FSF. Two instances I personally > know of: > > 1) Sometime around 2005? maybe later, I lobbied to change gcc's > implementation language to C++. I failed because I'm lazy and learned I > was arguing against an RMS effective veto. (I learned this because Mark > Mitchell informed me that some SC members were also pushing back against > RMS's opposition to C++. I was not privy to the actual SC discussion.) > If he was not an SC member, why was he even in that private > conversation? The public ML would have been more appropriate place for > non-SC opinions to be voiced. Just think, we could have transitioned to > C++ earlier than we did, if it were not for the SC's inclusio of RMS. > > 2) Last year, I asked for libcody to be added as a subcomponent, with > its Apachev2 license intact. AFAICT RMS was involved in that licensing > discussion, /for which I never received a response/. He was not at the > FSF then, so he could not render any FSF licensing opinion. Why was he > involved? If he was not involved, how did he learn of it in order to > ask me questions about C++ modules? I only emailed the SC and the > timing is too coincidental to draw a different conclusion. > > Interactions I've had with the SC, beyond maintainer appointment, seem > to run into RMS. (In the original email I mentioned a third interaction > about RMS's position on the SC, which didn't do so, but also was > decidedly one way.) > > You, the SC, do not state that you will not continue to involve RMS in > discussions, just as you have done for the past 20 years. You merely > feel the listing is unfortunate. > > Your final paragraph is the corporate BS of hollow men. Nice words, no > specific actions. > > Richard Biener pointed out dysfunction in the SC. The case of the > missing question I asked in 2019 also points to that. This response > gives me no confidence that things will materially change. I call for > the dissolution of the SC, replacing it with a more open, functional and > inclusive body (which includes, nothing). > > nathan > > FWIW, I am surprised that you, the SC, chose to respond only to the > mailing list, and not CC me, the original complainant, of your decision. > Perhaps that seems petty, but it is personally insulting. Nathan, you are clearly angry and frustrated. I'm sorry about that. I'm going to give some of my own personal opinions. I'm not at all speaking for the committee, and other committee members may disagree. The steering committee is just a bunch of GCC hackers who originally self-organized to manage the EGCS fork. As it says at https://gcc.gnu.org/steering.html, "committee members were chosen to represent the interests of communities." I was not on the steering committee at the time, but I was somewhat involved with thinking about who should be, and that statement accurately describes what we were trying to do. The intent was to ensure that when decisions were made that covered the GCC project as a whole, all interested groups would have a representative. In practice the steering committee makes few decisions. Naturally, members of the committee work to improve GCC in various ways. That work almost never involves any sort of steering committee discussion. I think you want the steering committee to issue a statement about RMS's behavior. I think
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou wrote: >> I have so far bootstrapped and tested the release candidate on >> x86_64-linux. Please test it and report any issues to bugzilla. > >It does not build for Windows: > https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567582.html Backporting the followup fix is approved. Richard.
Re: Remove RMS from the GCC Steering Committee
On 3/31/21 2:27 PM, David Edelsohn via Gcc wrote: [I previously sent this from another email account, but it seems to be lost. I am sending this on behalf of the GCC Steering Committee.] In 2012 RMS was added to the GCC Steering Committee web page based on his role in the GNU Project, though his role as a member of the Steering Committee has been ambiguous and he was not a member of the Steering Committee when EGCS became GCC[1]. We no longer feel that this listing serves the best interests of the GCC developer and user community. Therefore, we are removing him from the page. GCC supports the principles of Free Software and has remained aligned with the GNU Project since EGCS became GCC, but effectively has continued to operate as an autonomous project. The GCC Steering Committee is committed to providing a friendly, safe and welcoming environment for all, regardless of gender identity and expression, sexual orientation, disabilities, neurodiversity, physical appearance, body size, ethnicity, nationality, race, age, religion, or similar personal characteristics. - The GCC Steering Committee [1] https://static.lwn.net/1999/0429/a/gcc.html You, the SC, have chosen to fix this as a clerical error. The most do-nothing response, other than actually doing nothing. I am profoundly disappointed that you have not even acknowledged the harm RMS has caused. Using passive voiced 'RMS was added' phrasing. You're not explicitly saying that was incorrect, and neither are you saying it was correct. Your language attempts to distance you from your choices. 'we no longer feel the listing serves the best interest'. 'Therefore, we are removing him from the page FULLSTOP'. Well, at least that's not passive voice, but it is a milque-toast response. You're not removing him from the SC, merely removing mention of him from the listing. You're not adding words to the website mentioning this historical ambiguity/error/misjudgement (you'd say if you were, right?). You're not adding words acknowledging that RMS's involvement has been detrimental and repelled contributors. Nor are you apologizing. You're not owning your mistake. You just hope the problem will silently go away. The problem will not go away. /You/ involved RMS in SC discussions. /You/ treated him as a member thereof. /You/ gave him controlling rights. You have misled the majority of GCC developers, and the wider community by doing so. If it looks like a duck, walks like a duck, and talks like a duck, it's a duck. (As compiler developers for duck-typed languages, you should understand that.) You involved RMS prior to 2012, and continued to do so after. Including after 2019 when he was no longer at the FSF. Two instances I personally know of: 1) Sometime around 2005? maybe later, I lobbied to change gcc's implementation language to C++. I failed because I'm lazy and learned I was arguing against an RMS effective veto. (I learned this because Mark Mitchell informed me that some SC members were also pushing back against RMS's opposition to C++. I was not privy to the actual SC discussion.) If he was not an SC member, why was he even in that private conversation? The public ML would have been more appropriate place for non-SC opinions to be voiced. Just think, we could have transitioned to C++ earlier than we did, if it were not for the SC's inclusio of RMS. 2) Last year, I asked for libcody to be added as a subcomponent, with its Apachev2 license intact. AFAICT RMS was involved in that licensing discussion, /for which I never received a response/. He was not at the FSF then, so he could not render any FSF licensing opinion. Why was he involved? If he was not involved, how did he learn of it in order to ask me questions about C++ modules? I only emailed the SC and the timing is too coincidental to draw a different conclusion. Interactions I've had with the SC, beyond maintainer appointment, seem to run into RMS. (In the original email I mentioned a third interaction about RMS's position on the SC, which didn't do so, but also was decidedly one way.) You, the SC, do not state that you will not continue to involve RMS in discussions, just as you have done for the past 20 years. You merely feel the listing is unfortunate. Your final paragraph is the corporate BS of hollow men. Nice words, no specific actions. Richard Biener pointed out dysfunction in the SC. The case of the missing question I asked in 2019 also points to that. This response gives me no confidence that things will materially change. I call for the dissolution of the SC, replacing it with a more open, functional and inclusive body (which includes, nothing). nathan FWIW, I am surprised that you, the SC, chose to respond only to the mailing list, and not CC me, the original complainant, of your decision. Perhaps that seems petty, but it is personally insulting. -- Nathan Sidwell
Re: Protest against removal of RMS from GCC Steering Committee
On Thu, 2021-04-01 at 17:23 +0200, Andrea G. Monaco wrote: > > I strongly disagree with the removal of Dr. Stallman from the > Steering > Committee. RMS was not removed from the GCC Steering Committee; his name was removed from the *web page* of the steering committee. Based on the discussion here it appears to me that he never was a member of the steering committee, and the listing on that web page was in error (and thus the recent thread on this was misnamed). Rather, one of the roles of the steering committee seems to be to interact with RMS and the FSF on behalf of the project so that the rest of us can get on with maintaining our Free Software compiler. Thanks Steering Committee members! (I liked David Edelhsohn's analogy earlier that the SC is about removing roadblocks so that the developers can get on with things). > Not only RMS wrote the GCC initially, but I think he is the best > person > by far who can guarantee the values of free software, with unmatched > integrity and lucidity. > > That's especially important in the SC, given the presence of powerful > and evil corporations like Google and IBM. > > I suspect that many people agree with me, but perhaps they are scared > into silence by this intimidating and hostile mob. The only intimidation I've seen on this list has been from one of RMS's supporters. Hope this is constructive Dave (my opinions, and not those of my employer, which though it may have made mistakes over the years is not currently overtly evil, last time I checked)
Re: Protest against removal of RMS from GCC Steering Committee
On April 1, 2021 5:23:25 PM GMT+02:00, "Andrea G. Monaco" wrote: > >I strongly disagree with the removal of Dr. Stallman from the Steering >Committee. > >Not only RMS wrote the GCC initially, but I think he is the best person >by far who can guarantee the values of free software, with unmatched >integrity and lucidity. > >That's especially important in the SC, given the presence of powerful >and evil corporations like Google and IBM. Note that not companies but individual people are SC members, so I would not characterize things in this way. Richard. >I suspect that many people agree with me, but perhaps they are scared >into silence by this intimidating and hostile mob. > > >Andrea Monaco
Re: Question on changing IPA-PTA to an IPA_PASS
On April 1, 2021 3:52:37 PM GMT+02:00, Erick Ochoa wrote: >> >> I don't think this would remove any problem that is present. >> > >I have a problem understanding what you mean here because later on you >state: > >> Now - the reason you think of is likely that IPA transform will >instantiate >> IPA clones and do inlining and transfering the IPA PTA solution to >the >> such transformed IL is at best complicated. That's true as well, of >course, >> in fact IPA inlining and cloning will improve context sensitivity (by >> duplicating). > >So, I think you are agreeing with me that transferring the IPA PTA >solution to the transformed IL is a big complication. So, going back >to your previous statement "I don't think this would remove any >problem that is present," does this mean that: > >1. this will not solve the "transfering the IPA PTA solution to the >such transformed IL" problem? This. >2. or "transfering the IPA PTA solution to the such transformed IL" is >not a present problem? > >Sorry, just trying to understand what you are fully saying. > >Just to be more explicit, I believe (and might be wrong) that placing >a new section of passes after the ipa-passes would now materialize all >the new IL, and therefore when creating a new section, IPA-PTA would >only see IL that will not be transformed. This gets rid of >"transfering the IPA PTA solution to transformed IL" problem, because >there is no more transformed IL. (But again, my understanding of some >things might be wrong). But that would mean running two ltrans and WPA phases. You can't (don't want to) materialize clones during WPA. >> >> But the main reason we've not even tried to make IPA PTA a true IPA >pass >> is because of the scalability issue. >> > >I didn't know this was the main reason! Thanks! I'm wondering, let's >say that IPA PTA magically gets better performance. What would be the >next steps after that? Is looking into the summaries and updating the >constraints something that would be a good idea. (I think Hubicka >agrees on doing that.) Or do you have some other hints/ideas about >what would be a good implementation? Honza already suggested a unification based solver. That would be an experiment to do. Richard.
Protest against removal of RMS from GCC Steering Committee
I strongly disagree with the removal of Dr. Stallman from the Steering Committee. Not only RMS wrote the GCC initially, but I think he is the best person by far who can guarantee the values of free software, with unmatched integrity and lucidity. That's especially important in the SC, given the presence of powerful and evil corporations like Google and IBM. I suspect that many people agree with me, but perhaps they are scared into silence by this intimidating and hostile mob. Andrea Monaco
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
> I have so far bootstrapped and tested the release candidate on > x86_64-linux. Please test it and report any issues to bugzilla. It does not build for Windows: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567582.html -- Eric Botcazou
Re: Question on changing IPA-PTA to an IPA_PASS
> > I don't think this would remove any problem that is present. > I have a problem understanding what you mean here because later on you state: > Now - the reason you think of is likely that IPA transform will instantiate > IPA clones and do inlining and transfering the IPA PTA solution to the > such transformed IL is at best complicated. That's true as well, of course, > in fact IPA inlining and cloning will improve context sensitivity (by > duplicating). So, I think you are agreeing with me that transferring the IPA PTA solution to the transformed IL is a big complication. So, going back to your previous statement "I don't think this would remove any problem that is present," does this mean that: 1. this will not solve the "transfering the IPA PTA solution to the such transformed IL" problem? 2. or "transfering the IPA PTA solution to the such transformed IL" is not a present problem? Sorry, just trying to understand what you are fully saying. Just to be more explicit, I believe (and might be wrong) that placing a new section of passes after the ipa-passes would now materialize all the new IL, and therefore when creating a new section, IPA-PTA would only see IL that will not be transformed. This gets rid of "transfering the IPA PTA solution to transformed IL" problem, because there is no more transformed IL. (But again, my understanding of some things might be wrong). > > But the main reason we've not even tried to make IPA PTA a true IPA pass > is because of the scalability issue. > I didn't know this was the main reason! Thanks! I'm wondering, let's say that IPA PTA magically gets better performance. What would be the next steps after that? Is looking into the summaries and updating the constraints something that would be a good idea. (I think Hubicka agrees on doing that.) Or do you have some other hints/ideas about what would be a good implementation?
Re: Question on changing IPA-PTA to an IPA_PASS
> The reason this is not done is because the summaries (constraints) > are huge, the solutions are even larger and the PTA solver doesn't > scale to large units (so the LTRANS splitting makes it actually usable > in the first place). I did not spent that much time working on PTA as Richard, but it seems to me that while this is true for current solver that runs on bitmaps, the unification based PTA will scale (solving and stremaing should be fast enough to be enabled by default). If improved by context sensitivity it should also give useful results. So I think the right course of action is to make IPA-PTA to (optionally) use unification based approach first, so it could run at -O2. That Then one can make it to work with summaries and run at WPA time. Once this is working one can work on right balance between precision and performance. There is a paper on the open64 implementation https://yuleisui.github.io/publications/spe14.pdf that looks close to what we could do. > > Now - the reason you think of is likely that IPA transform will instantiate > IPA clones and do inlining and transfering the IPA PTA solution to the > such transformed IL is at best complicated. That's true as well, of course, > in fact IPA inlining and cloning will improve context sensitivity (by > duplicating). At high level I do not think it is so bad :) Your IPA summary wil have constraints which will map to (probably simplified) SSA graph. If you clone function, you just duplicate the summary. Function signature changes (ipa-sra/ipa-cp) will need some cooperation, but we already do similar things to keep jump functions intact... When inlining one needs to merge in the solution but that also seems doable... Honza > > Note that in principle IPA summaries from other IPA passes are available > and thus you could duplicate / rewrite constraints accordingly. > > But the main reason we've not even tried to make IPA PTA a true IPA pass > is because of the scalability issue. > > Richard.
Re: Question on changing IPA-PTA to an IPA_PASS
On Thu, Apr 1, 2021 at 2:50 PM Erick Ochoa via Gcc wrote: > > Hi, > > just a high level question. I know that IPA-PTA is a SIMPLE_IPA_PASS > and that ideally it would be better as an IPA_PASS. I understand that > one of the biggest challenges of changing IPA-PTA to an IPA_PASS is > that on the current LTO framework, the LTRANS stage can happen at the > same time for multiple transformations. This means (I think) that if > IPA-PTA computed the points-to sets during WPA, during LTRANS there > can be new variables, or modified function bodies that therefore no > longer correspond to the computed IPA-PTA. > > However, it seems that there's a simpler way to change IPA-PTA to an > IPA_PASS. This is by just introducing another section of > "all_regular_ipa_passes". Something like (not sure if the name inside > the brackets has to be unique) > > INSERT_PASSES_AFTER (all_regular_ipa_passes) > // normal stuff > TERMINATE_PASS_LIST (all_regular_ipa_passes) >INSERT_PASSES_AFTER (all_regular_ipa_passes) > NEXT_PASS (pass_ipa_pta); >TERMINATE_PASS_LIST (all_regular_ipa_passes) > > I understand that this still singles out IPA-PTA as being "special", I don't think this would remove any problem that is present. > but I am wondering if this is something that has been discussed > previously. The changes in the implementation on IPA-PTA should be > something like: > > 1. LGEN: in summaries store the constraint variables that GCC is > finding by inspecting gimple > 2. WPA: actually solve the constraint variables and store only the > solutions to the constraint variables in another summary > 3. LTRANS: read from the summary and pass the information to gimple > > The advantage I see to this is that the precision of IPA-PTA would be > equal to using -flto-partition=none but without actually using that > flag and possibly some compile time speedup (when compared to > -flto-partition=none because parallel reading and writing of > summaries). Again, just an idea and I just want to understand if this > has been discussed before and why it is or might not be something that > you guys want. The reason this is not done is because the summaries (constraints) are huge, the solutions are even larger and the PTA solver doesn't scale to large units (so the LTRANS splitting makes it actually usable in the first place). Now - the reason you think of is likely that IPA transform will instantiate IPA clones and do inlining and transfering the IPA PTA solution to the such transformed IL is at best complicated. That's true as well, of course, in fact IPA inlining and cloning will improve context sensitivity (by duplicating). Note that in principle IPA summaries from other IPA passes are available and thus you could duplicate / rewrite constraints accordingly. But the main reason we've not even tried to make IPA PTA a true IPA pass is because of the scalability issue. Richard.
Question on changing IPA-PTA to an IPA_PASS
Hi, just a high level question. I know that IPA-PTA is a SIMPLE_IPA_PASS and that ideally it would be better as an IPA_PASS. I understand that one of the biggest challenges of changing IPA-PTA to an IPA_PASS is that on the current LTO framework, the LTRANS stage can happen at the same time for multiple transformations. This means (I think) that if IPA-PTA computed the points-to sets during WPA, during LTRANS there can be new variables, or modified function bodies that therefore no longer correspond to the computed IPA-PTA. However, it seems that there's a simpler way to change IPA-PTA to an IPA_PASS. This is by just introducing another section of "all_regular_ipa_passes". Something like (not sure if the name inside the brackets has to be unique) INSERT_PASSES_AFTER (all_regular_ipa_passes) // normal stuff TERMINATE_PASS_LIST (all_regular_ipa_passes) INSERT_PASSES_AFTER (all_regular_ipa_passes) NEXT_PASS (pass_ipa_pta); TERMINATE_PASS_LIST (all_regular_ipa_passes) I understand that this still singles out IPA-PTA as being "special", but I am wondering if this is something that has been discussed previously. The changes in the implementation on IPA-PTA should be something like: 1. LGEN: in summaries store the constraint variables that GCC is finding by inspecting gimple 2. WPA: actually solve the constraint variables and store only the solutions to the constraint variables in another summary 3. LTRANS: read from the summary and pass the information to gimple The advantage I see to this is that the precision of IPA-PTA would be equal to using -flto-partition=none but without actually using that flag and possibly some compile time speedup (when compared to -flto-partition=none because parallel reading and writing of summaries). Again, just an idea and I just want to understand if this has been discussed before and why it is or might not be something that you guys want.
GCC 10.3 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 10.3 is available from https://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/ ftp://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/ and shortly its mirrors. It has been generated from git commit 892024d4af83b258801ff7484bf28f0cf1a1a999. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 10.3 on Thursday, April 8th.
GCC 10.2.1 Status Report (2021-04-01), branch frozen for release
Status == The GCC 10 branch is frozen for the release of GCC 10.3 with a first release candidate published. All changes require release manager approval. Quality Data Priority # Change from last report --- --- P1- 1 P2 326 - 27 P3 25 - 5 P4 179 + 3 P5 23 --- --- Total P1-P3 350 - 34 Total 552 - 31 Previous Report === https://gcc.gnu.org/pipermail/gcc/2021-March/235046.html
Re: Question about reading LTO function summaries
Hello,
just trying one more time. Any direction or hint is appreciated. Just
as a note, I looked at the ipa-devirt as an inspiration for these
small functions I wrote, but for some reason I can't read what I
assume have written to the summaries. (What I'm trying to do is simply
use LTO using a real IPA_PASS as opposed to SIMPLE_IPA_PASS, and
therefore I just want to write some simple summaries and read them).
I have wondered if the bitpack_d bp = bitpack_create
(ob->main_stream); creates any difference, but when I tried it that
didn't seem to be the case.
Many thanks in advance!
On Tue, 30 Mar 2021 at 10:18, Erick Ochoa wrote:
>
> Hello,
>
> just trying again to increase visibility of this question. Many thanks
> in advance!
>
>
> On Fri, 26 Mar 2021 at 13:49, Erick Ochoa wrote:
> >
> > Hello,
> >
> > I already have some experience developing SIMPLE_IPA_PASSes, but I am
> > looking to understand IPA_PASSes better. I have made a hello world ipa
> > pass that stores "hello world $FUNCTION_NAME" in the function
> > summaries; however, I am having trouble reading this information back.
> > Can someone help me understand how to use these interfaces correctly?
> >
> > At the moment, it **seems** to be writing information correctly.
> > (I.e., it doesn't segfault when attempting to write data.) However, in
> > my read summary function (ipa_hello_world_read_summary (void)) the
> > function `lto_get_summary_section_data (file_data,
> > LTO_section_ipa_hello_world, &len);` always returns NULL and
> > `file_data_vec` is of size 1. This means that at run time, there is
> > only one call to `lto_get_summary_section_data` and it returns NULL.
> >
> > I am copy-pasting the relevant code below.
> >
> > /* Map from cgraph_node* to "hello world $FUNCTION_NAME". */
> > static hash_map *hello_summaries;
> >
> > static void
> > ipa_hello_world_write_summary (void)
> > {
> > gcc_assert(hello_summaries);
> > struct output_block *ob = create_output_block
> > (LTO_section_ipa_hello_world);
> > gcc_assert(ob);
> > if (dump_file) fprintf(dump_file, "hello world from write summary\n");
> > lto_symtab_encoder_t encoder = ob->decl_state->symtab_node_encoder;
> > if (dump_file) fprintf(dump_file, "writing %d\n",
> > hello_summaries->elements());
> > streamer_write_uhwi (ob, hello_summaries->elements());
> >
> > for (auto i = hello_summaries->begin(), e = hello_summaries->end();
> > i != e; ++i)
> > {
> > if (dump_file) fprintf(dump_file, "writing %s\n", (*i).second);
> > streamer_write_uhwi(ob, lto_symtab_encoder_encode(encoder, (*i).first));
> > streamer_write_string (ob, ob->main_stream, (*i).second, true);
> > }
> > produce_asm (ob, NULL);
> > destroy_output_block (ob);
> > delete hello_summaries;
> > }
> >
> > static void
> > ipa_hello_world_read_summary (void)
> > {
> > struct lto_file_decl_data **file_data_vec = lto_get_file_decl_data ();
> > struct lto_file_decl_data *file_data;
> > unsigned int j = 0;
> > if (dump_file) fprintf(dump_file, "hello from read summary\n");
> > while ((file_data = file_data_vec[j++]))
> > {
> > if (dump_file) fprintf(dump_file, "iteration = %d\n", j);
> > size_t len;
> > const char *data =
> > lto_get_summary_section_data (file_data,
> > LTO_section_ipa_hello_world, &len);
> > if (!data) continue;
> >
> > const struct lto_function_header *header = (const struct
> > lto_function_header*) data;
> > gcc_assert(header);
> > gcc_assert(header->cfg_size);
> > const int cfg_offset = sizeof (struct lto_function_header);
> > const int main_offset = cfg_offset + header->cfg_size;
> > const int string_offset = main_offset + header->main_size;
> > class data_in *data_in;
> >
> > lto_input_block ib ((const char *) data + main_offset,
> > header->main_size,
> > file_data->mode_table);
> > data_in
> > = lto_data_in_create (file_data, (const char *) data + string_offset,
> > header->string_size, vNULL);
> > unsigned int n = streamer_read_uhwi (&ib);
> > //hello_summaries = new hash_map;
> > for (unsigned i = 0; i < n; i++)
> > {
> > unsigned int index = streamer_read_uhwi(&ib);
> > lto_symtab_encoder_t encoder = file_data->symtab_node_encoder;
> > struct cgraph_node *cnode = dyn_cast
> > (lto_symtab_encoder_deref(encoder, index));
> > gcc_assert(cnode);
> > const char* string = streamer_read_string (data_in, &ib);
> > if (dump_file) fprintf(dump_file, string);
> > }
> > }
> >
> > }
GCC 10.2.1 Status Report (2021-04-01), branch frozen for release
The GCC 10 branch is now frozen in preparation for the GCC 10.3 release which will see a first release candidate built soon. All changes from now on require release manager approval.
Re: GCC Plugin introduction
On Tue, 30 Mar 2021, SAIFI wrote: On Mon, 29 Mar 2021, Gabriele Serra wrote: I have written a very basic article on GCC Plugins (how to build a plugin from the ground, some info on APIs, and how to instrument code). The material is based on GCC 9. The code is fully documented and working. https://gabrieleserra.ml/blog/2020-08-27-an-introduction-to-gcc-and-gccs-plugins.html Gabriele thanks for sharing the detailed write up. in the spirit of 'gcc-help', can you please share pointers as to how one can profile C++ code using GCC plugins ? Gabriele please see Stephen Friedl's blog posts on GCC plugins https://stephanfr.com/category/gcc/ and git repo https://github.com/stephanfr/GCCPlugin Have you had a chance to see these posts during your literature survey ? Any thoughts ? warm regards Saifi.
Re: RMS removed from the GCC Steering Committee (was: Remove RMS...)
On Thu, 1 Apr 2021 at 10:13, Jonathan Wakely wrote: > > > > On Thu, 1 Apr 2021, 01:05 Giacomo Tesio, wrote: >> >> >> People all over the world, whatever their country, should be sure to be >> treated fairly and equally by the GCC leaders even if they want to >> contribute something that does not match the culture or interests you >> represent. > > > > Everybody is welcome to send patches for GCC. The steering committee doesn't > decide what people work on, and they don't approve patches. I don't think "the West" creates the same perceptual problem for potential new contributors as Nathan explained in his original email. Of course more diversity in the GCC community and the SC is needed. But if you think simply being American causes the same (or "more severe") image problem, maybe you missed the point of Nathan's original email.
Re: RMS removed from the GCC Steering Committee (was: Remove RMS...)
On Thu, 1 Apr 2021, 01:05 Giacomo Tesio, wrote: > > People all over the world, whatever their country, should be sure to be > treated fairly and equally by the GCC leaders even if they want to > contribute something that does not match the culture or interests you > represent. > Everybody is welcome to send patches for GCC. The steering committee doesn't decide what people work on, and they don't approve patches.
Re: RMS removed from the GCC Steering Committee
Giacomo Tesio writes: > Hi David, thanks for sharing! > > On Wed, 31 Mar 2021 14:27:29 -0400 David Edelsohn via Gcc wrote: > >> In 2012 RMS was added to the GCC Steering Committee web page >> based on his role in the GNU Project [...] >> we are removing him from the page. > > I have to admit that I had never carefully observed the list of members > of the GCC steering committee. As I explained before in this thread, > the presence of Stallman gave me enough reassurance that GCC would have > honoured the values of Free Software. > > As I said, enough to chose to port GCC to Jehanne instead of another > C compiler, in the hope to contribute back the port upstream, to GNU. > > > But now that I'm comparing the old web page [1] and the new one [2], > I realized something entirely new to me. > > > 10 out of 13 members of the GCC steering committee work either for > American corporations (8), their subsidiaries (1) or an American > University (1) recently covered by the press in India [3]. > Also, 4 of these work for the same corporation (IBM / Red Hat). > > The other 3 are from German GmbH (2) or from a Nederlands public agency. > [...] Hi Giacomo, thanks for your mail. Unfortunately I think is clear at this points what's the "Open Source" corporates position on this affair. A weak and malleable FSF and Free Software community is to many a very comfortable situation. Excluding RMS leveraging cancel culture proved to be the perfect strategy. Cancel culture is extremely powerful, it induces strong emotions and participation on people in good faith, freedom of speech and rationality go quickly in background (reminds me something of the past). Fighting against that often proves to be a desperate task, this is really just the perfect storm. Those who loses is just us, a divided and weaker movement. Regards Andrea
