Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On 4/1/21 2:35 PM, 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. with the backport of PR95842, the plugin header install is now broken. Needs also backporting of 9a83366b62e585cce5577309013a832f895ccdbf "Fix up plugin header install". Matthias
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On Fri, Apr 02, 2021 at 09:37:26AM +0200, Matthias Klose wrote: > On 4/1/21 2:35 PM, 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. > > with the backport of PR95842, the plugin header install is now broken. > > Needs also backporting of 9a83366b62e585cce5577309013a832f895ccdbf > "Fix up plugin header install". Cherry-picked now. Jakub
Re: Build reproducibility of gcc @ NixOS
Hi Arthur, On Fri, Apr 2, 2021 at 5:56 AM Arthur Gautier wrote: > > 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. That is expected as mentioned in the manual: https://gcc.gnu.org/install/build.html#Building-with-profile-feedback And, I have reproduced it as well as reported here: https://gcc.gnu.org/ml/gcc-help/2019-05/msg00118.html, the last questions that remain being here: https://gcc.gnu.org/legacy-ml/gcc-help/2019-07/msg00053.html > 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? Since an optimized build is likely to be machine-dependent regardless of any intended injection (e.g., different instructions used in GCC binaries depending on /proc/cpuinfo), I don't understand why an optimized build should be reproducible on different machines, unless of course every channel that GCC uses to find out about the machine (e.g., /proc/cpuinfo) is under your total control. So, do you mean to ask a list of all channels that GCC uses to find out about the machine? > Thank you for your help! No worries. > Best, > -- > Arthur -- Best regards, Tadeus
Re: RMS removed from the GCC Steering Committee
Hello Thomas, Jonathan, David, Nathan Jean and... everybody. :-) I'm sorry for this long mail that rivals with the original Nathan's request, but I wanted to back my request properly. On Wed, 31 Mar 2021 18:25:23 -0700 Thomas Rodgers wrote: > Not to argue counter to the observation that there is clear bias in > terms of large US and EU corporations Well, to be precise, it's 9 members from US corporations and 2 from German corporations. I mean: the bias is not even balanced between US and EU! Not even remotely! And obviously it totally excludes thousands of different interests. China, Russia, Brazil, Switzerland, Cuba, Iraq, Palestine... I guess you do not need me to continue. ;-) > Quickly eyeballing the output of - > >'git shortlog -s -n --all releases/gcc-9.1.0...master' > > Seems to show a similar bias in participation. As I said before, history is always used to justify Power and (obviously) Power affects history. Thanks for proving my point by referring to `git shortlog`! :-D > It reflects the economics of whose willing and able to commit to > that work as a full time undertaking. This is another very interesting argument, Thomas. Just like the Jeff's one "it's more historical than anything", it looks quite neutral on the surface, even obvious as an argument, until you look at it "cum grano salis". Why most contributions to GCC come from employees of large corporations from the greatest military power since the fall of the Berlin Wall? I know: a very good question that cannot be answered here. But for sure, it's not just a matter of fair merits[1]! Yet, the fact you look at the economics to explain power (instead of the other way around) proves my other point. You are just showing (in absolute good faith!) how your US-priviledge blinds you from itself and its dogmatic roots that Weber called "the Spirit of Capitalism" [2]. It's not your fault, but it more than a danger to the rest of the world. It's sistematic discrimination based on power (that's is expressed and enforced through wealth and giustified through "economics" and clearly captured by `git log`s). But from outside your "cultural bubble", we all see that a bunch of highly controversial [3][4] US corporations (with long term ties with the USA DoD [5]) are kicking out of the GCC Steering Committee their only connection with both the FSF and the GNU project. A member of FSF and GNU that was representing the only non-profit in the Steering Committee credibly dedicated to preserve Free Software[6]. You just need to read what David wrote: On Wed, 31 Mar 2021 08:59:41 -0400 David Edelsohn via Gcc wrote: > GCC SC whose major purpose is to be a buffer between the GCC > Community and the Free Software Foundation. On Wed, 31 Mar 2021 11:23:09 -0400 David Edelsohn via Gcc wrote: > members of the GCC SC have worked diligently behind the scenes to > ensure that GCC and GNU Toolchain development can proceed as smoothly > and unhindered as possible. We have prevented or resolved many > conflicts and issues without disturbing the broader community and > allow the community to focus on its important tasks and great > progress for the toolchain itself. > [...] > It's like a good manager: regardless of the openness, hopefully the > GCC community feels that the GCC SC "has their back", manages the > politics, and removes real or potential roadblocks so that the > software engineer can focus on being productive. it is quite evident that the interest represented by the members of the Steering Committee while "managing the politics" will align with that of their employers (and with their own values and culture). Please, do not offend our intelligence by pretending otherwise. On Thu, 1 Apr 2021 10:23:03 +0100 Jonathan Wakely wrote: > 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. Quite the opposite: I've totally seen the point from the very beginning[7]: a Facebook employee from the US asked to the US corporate-members of GCC Steering Committee to remove Stallman (and FSF and GNU with him) from the Steering Committee. And the Steering Committee, did it [8]. Also, note that I focused on your culture just because you accepted the Nathan's request to remove RMS from the GCC Steering Committee because of his "are extremely offensive repugnant opinions"[0]. You did the removal NOW, not years before or years later. And you know how this particular timing will be interpreted. But I do NOT ignore the geopolitical hazard of a GCC Steering Committee whose members are mostly under US legislation while GCC is used to compile fundamental software all over the world! Let's not pretend that we didn't read Thompson reflections on trusting trust or, if you need a more recent example, we haven't read about Solar Wind supply chain attack or about the backdoor introduced in PHP [13]! Nor I do ignore the ECONOMICAL hazard to rely
Re: RMS removed from the GCC Steering Committee
From what I have seen, problem has really start from developers who think they are some hot shot that can make things swing their way. That is the real problem in achieving an inclusive community. It is not about Richard Stallman at all. He did one of the most inclusive thing there is, which brute developers inherited to then screw up. More progress was done with Richard Stallman than at any later time - the really important things anyway. Furthermore, there would not have been any public focused cryptography if it was not for Richard Stallman. I can do what I want with GCC without the current input of some individuals. Things could move slower, but what the heck - I'm fine with that! Regards Christopher > Sent: Friday, April 02, 2021 at 10:05 PM > From: "Giacomo Tesio" > To: "Thomas Rodgers" , "Nathan Sidwell" > , "JeanHeyd Meneide" > Cc: gcc@gcc.gnu.org > Subject: Re: RMS removed from the GCC Steering Committee > > Hello Thomas, Jonathan, David, Nathan Jean and... everybody. :-) > > > I'm sorry for this long mail that rivals with the original Nathan's > request, but I wanted to back my request properly. > > > On Wed, 31 Mar 2021 18:25:23 -0700 Thomas Rodgers wrote: > > > Not to argue counter to the observation that there is clear bias in > > terms of large US and EU corporations > > Well, to be precise, it's 9 members from US corporations and 2 from > German corporations. I mean: the bias is not even balanced between US > and EU! Not even remotely! > > And obviously it totally excludes thousands of different interests. > China, Russia, Brazil, Switzerland, Cuba, Iraq, Palestine... > I guess you do not need me to continue. ;-) > > > > Quickly eyeballing the output of - > > > >'git shortlog -s -n --all releases/gcc-9.1.0...master' > > > > Seems to show a similar bias in participation. > > As I said before, history is always used to justify Power and > (obviously) Power affects history. > > Thanks for proving my point by referring to `git shortlog`! :-D > > > > It reflects the economics of whose willing and able to commit to > > that work as a full time undertaking. > > This is another very interesting argument, Thomas. > > Just like the Jeff's one "it's more historical than anything", it looks > quite neutral on the surface, even obvious as an argument, until you > look at it "cum grano salis". > > Why most contributions to GCC come from employees of large corporations > from the greatest military power since the fall of the Berlin Wall? > I know: a very good question that cannot be answered here. > But for sure, it's not just a matter of fair merits[1]! > > > Yet, the fact you look at the economics to explain power (instead of the > other way around) proves my other point. > You are just showing (in absolute good faith!) how your US-priviledge > blinds you from itself and its dogmatic roots that Weber called "the > Spirit of Capitalism" [2]. > > It's not your fault, but it more than a danger to the rest of the world. > It's sistematic discrimination based on power (that's is expressed and > enforced through wealth and giustified through "economics" and > clearly captured by `git log`s). > > > > > But from outside your "cultural bubble", we all see that a bunch of > highly controversial [3][4] US corporations (with long term ties with > the USA DoD [5]) are kicking out of the GCC Steering Committee their > only connection with both the FSF and the GNU project. > > A member of FSF and GNU that was representing the only non-profit in > the Steering Committee credibly dedicated to preserve Free Software[6]. > > > You just need to read what David wrote: > > On Wed, 31 Mar 2021 08:59:41 -0400 David Edelsohn via Gcc wrote: > > > GCC SC whose major purpose is to be a buffer between the GCC > > Community and the Free Software Foundation. > > On Wed, 31 Mar 2021 11:23:09 -0400 David Edelsohn via Gcc wrote: > > > members of the GCC SC have worked diligently behind the scenes to > > ensure that GCC and GNU Toolchain development can proceed as smoothly > > and unhindered as possible. We have prevented or resolved many > > conflicts and issues without disturbing the broader community and > > allow the community to focus on its important tasks and great > > progress for the toolchain itself. > > [...] > > It's like a good manager: regardless of the openness, hopefully the > > GCC community feels that the GCC SC "has their back", manages the > > politics, and removes real or potential roadblocks so that the > > software engineer can focus on being productive. > > it is quite evident that the interest represented by the members of the > Steering Committee while "managing the politics" will align with that > of their employers (and with their own values and culture). > > Please, do not offend our intelligence by pretending otherwise. > > > > On Thu, 1 Apr 2021 10:23:03 +0100 Jonathan Wakely wrote: > > > But if you think simply being American causes the same (or "more > > severe") image problem, maybe you m
Re: RMS removed from the GCC Steering Committee
On Fri, 2 Apr 2021 at 11:06, Giacomo Tesio wrote: > But from outside your "cultural bubble", we all see that a bunch of > highly controversial [3][4] US corporations (with long term ties with > the USA DoD [5]) are kicking out of the GCC Steering Committee their > only connection with both the FSF and the GNU project. If that's what you think happened, you've not been paying attention to this thread. The SC just did was they were requested to do by (some of) the developers of the project.
Re: Has FSF stopped processing copyright paperwork?
On Fri, Aug 14, 2020 at 8:25 AM Kaylee Blake wrote: > > On 7/8/20 10:41 pm, H.J. Lu wrote: > > On Tue, May 5, 2020 at 6:42 PM Kaylee Blake wrote: > >> > >> On 2/5/20 11:49 pm, H.J. Lu wrote: > >>> On Wed, Mar 18, 2020 at 6:46 PM Kaylee Blake via Binutils > >>> wrote: > > On 19/3/20 12:02 pm, H.J. Lu wrote: > > Kaylee, is your paper work with FSF in order? I will submit the updated > > patch set after your paper is on file with FSF. > > I'm waiting on a response from them at the moment. > > >>> > >>> Hi Kaylee, > >>> > >>> Any update on your paper work with FSF? > >>> > >> > >> Still waiting; apparently their work process has been dramatically > >> slowed by the whole COVID-19 situation. > >> > >> -- > >> Kaylee Blake > >> C is the worst language, except for all the others. > > > > Hi, > > > > I submitted a set of binutils patches: > > > > https://sourceware.org/pipermail/binutils/2020-March/13.html > > > > including contribution from Kaylee Blake . > > Can someone check if Kaylee's paperwork is on file with FSF? > > > > Thanks. > > > > I needed clarification on some of the language in the contract, and with > them being so busy that has been taking a while. They've confirmed it's > still in their work queue. > > -- > Kaylee Blake > C is the worst language, except for all the others. Can someone check if Kaylee's paperwork is on file with FSF? Thanks. -- H.J.
Re: RMS removed from the GCC Steering Committee
Dear Jonathan, everybody can see it... On Fri, 2 Apr 2021 14:05:10 +0100 Jonathan Wakely wrote: > On Fri, 2 Apr 2021 at 11:06, Giacomo Tesio wrote: > > But from outside your "cultural bubble", we all see that a bunch of > > highly controversial [3][4] US corporations (with long term ties > > with the USA DoD [5]) are kicking out of the GCC Steering Committee > > their only connection with both the FSF and the GNU project. > > If that's what you think happened, you've not been paying attention to > this thread. ...I wrote such a long mail, full of references to so many passages of your mails in these threads... without paying attention to them. What a lucky guy, I am! :-D > The SC just did was they were requested to do by (some > of) the developers of the project. Yeah, "some of". In this specific moment, when a global (and well financed) mob is attacking RMS personally, for anything they can frame as mischief, you were fine to comply with what "some of the developers" asked. What about the others? Did you consider that many of them might be to scared to oppose? Yet my request is not about Stallman, but about the Steering Committee. Please fix the huge global hazard that his removal uncovered. Giacomo
Re: RMS removed from the GCC Steering Committee
> Sent: Saturday, April 03, 2021 at 2:06 AM > From: "Giacomo Tesio" > To: "Jonathan Wakely" > Cc: "gcc@gcc.gnu.org" , "Nathan Sidwell" > Subject: Re: RMS removed from the GCC Steering Committee > > Dear Jonathan, > > everybody can see it... > > On Fri, 2 Apr 2021 14:05:10 +0100 Jonathan Wakely wrote: > > > On Fri, 2 Apr 2021 at 11:06, Giacomo Tesio wrote: > > > But from outside your "cultural bubble", we all see that a bunch of > > > highly controversial [3][4] US corporations (with long term ties > > > with the USA DoD [5]) are kicking out of the GCC Steering Committee > > > their only connection with both the FSF and the GNU project. > > > > If that's what you think happened, you've not been paying attention to > > this thread. > > ...I wrote such a long mail, full of references to so many passages of > your mails in these threads... without paying attention to them. > > What a lucky guy, I am! :-D > > > > The SC just did was they were requested to do by (some > > of) the developers of the project. > > Yeah, "some of". > > In this specific moment, when a global (and well financed) mob is > attacking RMS personally, for anything they can frame as mischief, > you were fine to comply with what "some of the developers" asked. > > What about the others? > Did you consider that many of them might be to scared to oppose? Even if you consider those who are not scared, the list clearly outstrips any legitimacy of the anti-stallman group. I clearly remember Ludovic Courtès trying to hamstring all Gnu Maintainers and force them to implement Codes of Conduct without any authority whatsoever. Free Software is about having NO Owners. Despite corporations' proliferation of codes of conduct, codes oftentimes suffer from numerous weaknesses that undermine the whole thing. > > Yet my request is not about Stallman, but about the Steering Committee. > > Please fix the huge global hazard that his removal uncovered. > > > Giacomo >
Re: Build reproducibility of gcc @ NixOS
Hi Tadeus, On Fri, Apr 2, 2021 at 9:07 AM Tadeus Prastowo wrote: > > Hi Arthur, > > On Fri, Apr 2, 2021 at 5:56 AM Arthur Gautier > wrote: > > > > 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. > > That is expected as mentioned in the manual: > > And, I have reproduced it as well as reported here: > https://gcc.gnu.org/ml/gcc-help/2019-05/msg00118.html, the last > questions that remain being here: > https://gcc.gnu.org/legacy-ml/gcc-help/2019-07/msg00053.html > > > 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? > > Since an optimized build is likely to be machine-dependent regardless > of any intended injection (e.g., different instructions used in GCC > binaries depending on /proc/cpuinfo), I don't understand why an > optimized build should be reproducible on different machines, unless > of course every channel that GCC uses to find out about the machine > (e.g., /proc/cpuinfo) is under your total control. So, do you mean to > ask a list of all channels that GCC uses to find out about the > machine? This is where I'm getting confused. According to the manual, stagetrain only record branch statistics. And I would expect, given the same input provided in the same order, two different architectures to take the same branch, and not observe any difference. I understand that with autoprofiled builds, the local architecture behavior is injected in the build, but I don't use that. I'm not using any -march in the build either (as far as I can understand/tell). So I do not expect the build to change its instruction set either. Is that normal that two different architectures would issue two different "execution counts of instruction and branch probabilities"? Or is there something more? Thank you for your reply! -- Arthur
Re: Has FSF stopped processing copyright paperwork?
Hi, On Fri, 2021-04-02 at 06:45 -0700, H.J. Lu via Gcc wrote: > On Fri, Aug 14, 2020 at 8:25 AM Kaylee Blake wrote: > > I needed clarification on some of the language in the contract, and with > > them being so busy that has been taking a while. They've confirmed it's > > still in their work queue. > > > Can someone check if Kaylee's paperwork is on file with FSF? I cannot find anything, sorry. It might be best to contact the Copyright Clerk at fsf-reco...@gnu.org with any details you can provide about when and for which name/email address the assignment was submitted. Note that it might be a holiday this Friday/Monday over there. Also the FSF might be a bit busy at the moment with changing its management team and board: https://www.fsf.org/blogs/executive-director/management-team-members-resigning Cheers, Mark
Re: Build reproducibility of gcc @ NixOS
Hi Arthur, On Fri, Apr 2, 2021 at 5:04 PM Arthur Gautier wrote: > > Hi Tadeus, > > On Fri, Apr 2, 2021 at 9:07 AM Tadeus Prastowo > wrote: [...] > > Since an optimized build is likely to be machine-dependent regardless > > of any intended injection (e.g., different instructions used in GCC > > binaries depending on /proc/cpuinfo), I don't understand why an > > optimized build should be reproducible on different machines, unless > > of course every channel that GCC uses to find out about the machine > > (e.g., /proc/cpuinfo) is under your total control. So, do you mean to > > ask a list of all channels that GCC uses to find out about the > > machine? > > This is where I'm getting confused. According to the manual, > stagetrain only record branch statistics. By "the manual", do you refer to https://gcc.gnu.org/install/build.html#Building-with-profile-feedback ? Quoting the page: When ‘make profiledbootstrap’ is run, it will first build a stage1 compiler. This compiler is used to build a stageprofile compiler instrumented to collect execution counts of instruction and branch probabilities. Training run is done by building stagetrain compiler. Finally a stagefeedback compiler is built using the information collected. End quote. Based on the quote, a reproducible build is to expected for the following compilers: 1. The stage1 compiler. 2. The stageprofile compiler, which is built by the stage1 compiler. 3. The stagetrain compiler, which is built by the stageprofile compiler. Then, a reproducible build is expected for the stagefeedback compiler on the condition that the same information, which was collected by the stageprofile compiler when building the stagegrain compiler, is used. Do you agree with that reasoning? > And I would expect, given > the same input provided in the same order, two different architectures > to take the same branch, and not observe any difference. In other words, you expect that branch statistics depends only on the given source code. Correct? > I understand > that with autoprofiled builds, the local architecture behavior is > injected in the build, but I don't use that. > I'm not using any -march in the build either (as far as I can > understand/tell). So I do not expect the build to change its > instruction set either. > > Is that normal that two different architectures would issue two > different "execution counts of instruction and branch probabilities"? I guess that it would be the case. > Or is there something more? Perhaps you can have the reproducible build that you want by first isolating the information that is collected by the stageprofile compiler when building the stagegrain compiler and then reusing the same information when building every other stagefeedback compiler. > Thank you for your reply! My pleasure. > -- > Arthur -- Best regards, Tadeus
Re: Build reproducibility of gcc @ NixOS
On Fri, Apr 2, 2021 at 4:32 PM Tadeus Prastowo wrote: > > Hi Arthur, > > On Fri, Apr 2, 2021 at 5:04 PM Arthur Gautier > wrote: > > > > Hi Tadeus, > > > > On Fri, Apr 2, 2021 at 9:07 AM Tadeus Prastowo > > wrote: [...] > > By "the manual", do you refer to > https://gcc.gnu.org/install/build.html#Building-with-profile-feedback > ? yes > > Quoting the page: > When ‘make profiledbootstrap’ is run, it will first build a stage1 compiler. > This compiler is used to build a stageprofile compiler instrumented > to collect execution counts of instruction and branch probabilities. > Training run is done by building stagetrain compiler. > Finally a stagefeedback compiler is built using the information collected. > End quote. > > Based on the quote, a reproducible build is to expected for the > following compilers: > 1. The stage1 compiler. > 2. The stageprofile compiler, which is built by the stage1 compiler. > 3. The stagetrain compiler, which is built by the stageprofile compiler. > > Then, a reproducible build is expected for the stagefeedback compiler > on the condition that the same information, which was collected by the > stageprofile compiler when building the stagegrain compiler, is used. > > Do you agree with that reasoning? Yes, and as far as I can tell, up to the stageprofile I get the same result. Only the output of the stagetrain compilation changes, which affects the stagefeedback compilation. > > > And I would expect, given > > the same input provided in the same order, two different architectures > > to take the same branch, and not observe any difference. > > In other words, you expect that branch statistics depends only on the > given source code. Correct? That would be my understanding (although very limited). What I'm trying to understand is: what "local behavior" is injected in my build, and see if I could get rid of that, and only keep branch statistics/execution counts, which I expect to be reproducible. > > > I understand > > that with autoprofiled builds, the local architecture behavior is > > injected in the build, but I don't use that. > > I'm not using any -march in the build either (as far as I can > > understand/tell). So I do not expect the build to change its > > instruction set either. > > > > Is that normal that two different architectures would issue two > > different "execution counts of instruction and branch probabilities"? > > I guess that it would be the case. > > > Or is there something more? > > Perhaps you can have the reproducible build that you want by first > isolating the information that is collected by the stageprofile > compiler when building the stagegrain compiler and then reusing the > same information when building every other stagefeedback compiler. Yeah, but said information is not reproducible itself (that would defeat the purpose of the effort).
Re: RMS removed from the GCC Steering Committee
On Fri, Apr 2, 2021 at 3:06 AM Giacomo Tesio wrote: > > I'm sorry for this long mail that rivals with the original Nathan's > request, but I wanted to back my request properly. This is free software. If you want to make it better, then make it better. The EGCS branch that displaced and became GCC came into existence because the people involved felt that it would make GCC better (I was a participant myself, though not a major one). See https://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_fork for a few more details. GCC is a successful free software project, but it is not perfect. It has many problems. Lack of contributor diversity is one of them. If I knew how to fix that problem, I would work to fix it. I personally do not believe that the membership of the steering committee is a significant cause of that problem. But I could be mistaken. So prove me wrong. Do the work. Ian
gcc-9-20210402 is now available
Snapshot gcc-9-20210402 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210402/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 0c7d11dbd216df4c1ae2f47138321b399e7349f0 You'll find: gcc-9-20210402.tar.xzComplete GCC SHA256=c26d540d3a52b9ae56978b623bfd4dbad068c4c5a99b14d8c802a8e921057610 SHA1=9fef279ab22bb438a55dd3ef255038d3ba39863c Diffs from 9-20210326 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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: GCC 10.3 Release Candidate available from gcc.gnu.org
On 01/04/2021 13:35, 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. On Windows, linking two C++ translation units that both #include results in errors about multiple definition of the weak function __dummy_resume_destroy. This can be avoided by cherry-picking commit 94fd05f1f76faca9dc9033b55d44c960155d38e9 [PR 95917].
Re: Build reproducibility of gcc @ NixOS
Hi Arthur, On Fri, Apr 2, 2021 at 6:45 PM Arthur Gautier wrote: > > On Fri, Apr 2, 2021 at 4:32 PM Tadeus Prastowo > wrote: > > > > Hi Arthur, > > > > On Fri, Apr 2, 2021 at 5:04 PM Arthur Gautier > > wrote: > > > > > > Hi Tadeus, > > > > > > On Fri, Apr 2, 2021 at 9:07 AM Tadeus Prastowo > > > wrote: > [...] > > > > By "the manual", do you refer to > > https://gcc.gnu.org/install/build.html#Building-with-profile-feedback > > ? > yes > > > > Quoting the page: > > When ‘make profiledbootstrap’ is run, it will first build a stage1 > > compiler. > > This compiler is used to build a stageprofile compiler instrumented > > to collect execution counts of instruction and branch probabilities. > > Training run is done by building stagetrain compiler. > > Finally a stagefeedback compiler is built using the information collected. > > End quote. > > > > Based on the quote, a reproducible build is to expected for the > > following compilers: > > 1. The stage1 compiler. > > 2. The stageprofile compiler, which is built by the stage1 compiler. > > 3. The stagetrain compiler, which is built by the stageprofile compiler. > > > > Then, a reproducible build is expected for the stagefeedback compiler > > on the condition that the same information, which was collected by the > > stageprofile compiler when building the stagegrain compiler, is used. > > > > Do you agree with that reasoning? > Yes, and as far as I can tell, up to the stageprofile I get the same result. > Only the output of the stagetrain compilation changes, which affects > the stagefeedback compilation. By saying "up to the stageprofile I get the same result", do you mean that you obtain the same stageprofile compilers on two different architectures? Or, do you mean that you obtain the same stageprofile compilers on the same machine by building GCC one after another in different build directories? And by saying "the output of the stagetrain compilation changes", do you mean that the stageprofile compiler __running on the same machine__ produces different stagetrain compilers? Or, do you mean that the stageprofile compiler running on the same machine obtains different statistics that will later be used to build the stagefeedback compiler? Or, something else? > > > And I would expect, given > > > the same input provided in the same order, two different architectures > > > to take the same branch, and not observe any difference. > > > > In other words, you expect that branch statistics depends only on the > > given source code. Correct? > That would be my understanding (although very limited). Could you tell me what you actually mean by the word "architectures", please? It is because in my understanding different architectures mean different instruction sets. > What I'm trying to understand is: what "local behavior" is injected in > my build, and see if I could get rid of that, and only keep branch > statistics/execution counts, which I expect to be reproducible. That currently I don't know because I haven't fully understood your actual situation. > > > I understand > > > that with autoprofiled builds, the local architecture behavior is > > > injected in the build, but I don't use that. > > > I'm not using any -march in the build either (as far as I can > > > understand/tell). So I do not expect the build to change its > > > instruction set either. > > > > > > Is that normal that two different architectures would issue two > > > different "execution counts of instruction and branch probabilities"? > > > > I guess that it would be the case. > > > > > Or is there something more? > > > > Perhaps you can have the reproducible build that you want by first > > isolating the information that is collected by the stageprofile > > compiler when building the stagegrain compiler and then reusing the > > same information when building every other stagefeedback compiler. > > Yeah, but said information is not reproducible itself (that would > defeat the purpose of the effort). I expect that running the same stageprofile compiler on the same machine twice, once to build stagetrain compiler A and and then once again to build stagetrain compiler B, should obtain A = B. While you imply that it was not the case, I am not sure because you don't say whether in your case you did the same (i.e., running the same stageprofile compiler on the same machine twice to obtain A and B). -- Best regards, Tadeus
Re: RMS removed from the GCC Steering Committee (was: Remove RMS...)
On Thu, 1 Apr 2021, Giacomo Tesio wrote: > Oh well, sure, but luckily the solution is just as fast and easy as > it was to remove RMS: pick just one person for each nationality and > remove the others. Why nationalities? That strikes me as a rather specific view focusing on one of many attributes (and I believe there's more nationalities than you might think, and a bigger variety of backgrounds). > 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. I will argue that is the case as of today and would like to see potential counter examples (if any) so that we can address those -or- file the point above as FUD. Note that contributions are generally reviewed and accepted by our group of maintainers per the MAINTAINERS file (not the steering commitee) and releases driven by our release managers. Gerald
