Re: Remove RMS from the GCC Steering Committee
On 2021-03-26 15:53, Hi-Angel via Gcc wrote: Hello! I don't know all the details, and it surprises me nobody is asking for them. Let me be the first. A cursory reading of the top of Nathan's email states the reason for not including the URLs, but ~half of the cited points come from Stallman's own archives, which can be found at - https://stallman.org/archive.html And for the rest, Nathan clearly indicates where (for those skilled in the ways of Let Me Google That For You) to find the same information. <... snip ...> (disclaimer: I'm just a random reader of the ML) Noted.
Re: Remove RMS from the GCC Steering Committee
On 2021-03-29 17:39, Christopher Dimech via Gcc wrote: You might say that the fullness of Thomas Jefferson's legacy should be acknowledged, but he did a bit more with his life than own slaves, just as the Reverend Martin Luther King Jr. did more with his time on earth than cheat on his wife and Mohandas Gandhi did more than write racist tracts about black Africans. We remember those men, and celebrate them, for other things. This is irrelevant to the discussion as to whether RMS should be member of GCC SC and whether or not the SC should make a public statement regarding the matter, one way or the other. The individuals you cite are all long dead, their entire history and legacy can be and is evaluated as much in the context of the time in which they lived as it is in the time in which we live now, with all the changes in social norms and standards that that entails. Stallman will no doubt be judged in a similar manner by history; founding the Free Software movement - good, the impact of his abusive and misogynistic behavior which (at best) belongs to another time - probably not so good. The question is, in this time, right now, is that specific last bit there. Is that the legacy that the GCC project and it's community of contributors (and by contributors, I mean those that actively currently do so) by continued association, wants for itself? I fully support the idea that the Steering Committee ought to make a definitive statement in that regard, one way or the other. Active contributors can then make whatever decisions they deem necessary based on that information.
Re: RMS removed from the GCC Steering Committee
On 2021-03-31 17:04, Giacomo Tesio wrote: Hi Jeff, thanks for fixing your affiliation, but let me note that it doesn't change a dime for the geopolitical-diversity issue that affects GCC since before RMS joined the Steering Committee. Not to argue counter to the observation that there is clear bias in terms of large US and EU corporations, but I wonder how that lines up with the affiliations of the major contributors over the recent past to GCC. Quickly eyeballing the output of - 'git shortlog -s -n --all releases/gcc-9.1.0...master' Seems to show a similar bias in participation. I don't think that's some intentional subversive plot hatched over a decade by bigcorp.com and bigcorp.de to undermine GNU. It reflects the economics of whose willing and able to commit to that work as a full time undertaking. The idea of making the SC more diverse over time, as well as what needs to be done to improve the diversity of the community of active contributors are important. I'm just not sure how it 'moves the needle' on the bias toward a bigcorp.com and bigcorp.de affiliated contributors who are paid to work on GCC full time and the SC necessarily has to represent that constituency of contributors as well. there to keep the faithful from wander astray. On Wed, 31 Mar 2021 17:35:36 -0600 Jeff Law wrote: To me, and to billions of people, this shows a huge cultural bias. It's more historical than anything. Power is always justified through history and it always affects history. We are looking at how to increase diversity on the committee, but that's a separate and distinct issue from removal of RMS. 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. While the GCC Steering Committee won't still be representative of all nationalities that contributed and will contribute to GCC, you instantly reduce the huge imbalance in the representation of the USA interests. I'm sure you can see how this is way more urgent than removing RMS, since, according to the other members of the SC, he was pretty inactive and ineffective anyway. Once you have removed the exceeding member from the page (and the SC, obviously) you will be able to identify new member from others countries. But please, HURRY UP! RMS was just a potential treat to GCC image, but these power imbalances on such a fundamental piece of sofware pose (and posed) a way more severe issue and on a global scale! 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. Giacomo
Re: GCC association with the FSF
On 2021-04-08 10:22, Giacomo Tesio wrote: No, David, On April 8, 2021 3:00:57 PM UTC, David Brown wrote: (And yes, I mean FOSS here, not just free software.) you are not talking about Free Software, but Open Source. FOSS, as a term, has been very successful to spread confusion. his attitudes and behaviour are not acceptable by modern standards and are discouraging to developers and users in the FOSS community. In fact, I'm actively looking for alternatives to GCC (and LLVM) because I cannot trust a GCC anymore and I cannot review each and every change. I won't contribute my port and in general will suggest people to look for alternatives. I've had some luck with the compiler offerings from Intel and Microsoft and I understand IBM has a compiler, and of course there's Nvidia's offerings (formerly PGI). But that's not a problem for you, because you do not actually care about real developers and users, just about the US corporations you effectively mentioned and now control several GNU projects: someone in the public relations department at IBM, Google, Facebook, ARM, or other big supporters of the project will get the impression ... As you explained, GCC itself is completelly controlled by few US corporations with strong and long term ties with the US DoD. For sure, it's a big software. And a big threat to everybody outside the US. Thanks for coming out. Giacomo
Re: GCC association with the FSF
On 2021-04-09 11:02, Christopher Dimech via Gcc wrote: [... snip ...] We (the free software world) does not need a person with the qualities of RMS any more - that is the point. There should not be such a position as "Chief GNUsance". Secondly, I cannot clearly see what status you have for making statements that imply a representation for the free software world!!! I know, right? He's not even got the cred conferred to a maintainer of an empty GNU project on Savannah.
Re: GCC association with the FSF
On 2021-04-09 14:02, Christopher Dimech wrote: But you seem too ignorant to introspect the likelihood that I could in effect have many valuable things to say. On the contrary, I eagerly await each and every one of your missives on this topic, hoping for exactly that very thing to occur.
Re: GCC association with the FSF
On 2021-04-10 05:35, Jonathan Wakely via Gcc wrote: On Sat, 10 Apr 2021, 12:57 Pankaj Jangid, wrote: Jonathan Wakely via Gcc writes: You are clueless about what the SC actually does, or the control they have over GCC. I think, it would be great help if someone can document what the SC does. https://gcc.gnu.org/steering.html They make decisions, they don't get to insert NSA backdoors on behalf of their employers without the rest of the project being aware. The idea that the SC members have a special ability to sneak such a change in, any more than any contributor, is just stupid. But I don't think he's seriously worried about that, he's just a Concern Troll raising nonsense concerns to derail any useful discussion from happening. The sooner he moves on to a new compiler he trusts, the better for everybody involved in GCC. Him too really, it's important to have trust in your toolchain...
Re: GCC association with the FSF
On 2021-04-09 14:34, Christopher Dimech wrote: On the contrary, I eagerly await each and every one of your missives on this topic, hoping for exactly that very thing to occur. I do not see how you and your friends at redhat could really get any value from it, because being a seeker of truth means refusing to make assumptions about things that you do not know. The moment you assume that you know because of what you believe, your intelligence will sleep. It is my wish and my blessing that every human being has their intelligence awake. On 2021-04-10 07:49, Christopher Dimech via Gcc wrote: There is a big difference between suppression or censorship, and wanting people in leadership positions to be representative of the values of the group they lead. RMS can have all the opinions he wants, and act has he will (until he ends up arrested for it), but if he is to remain a representative for others (FSF, GNU and/or GCC), then he has a duty to act appropriately according to the values those organisations think are important. If you look at the history of computing you will find that it was mostly crooks and people of very mixed kind of qualities. Not al all saints. Many of them quite unscrupolous and not very clever. And still they managed to do great things. So it tells a kid: They could do that, why can't you? That was certainly what turned me on. Freedom 0 also says "The freedom to run a program as you wish, for any purpose". Should we get our ideas from politicians and bureaucrats; or from Aleksandr Solzhenitsyn, Fyodor Dostoyevsky, Friedrich Nietzsche, Ernest Hemingway, Aldous Huxley, Marie-Henri Beyle, and Emily Jane Brontë? From the latter of course! So, that's a solid 'no' on the likelihood of you contributing anything of value to the discussion of GCC governance then?
Re: GCC association with the FSF
On 2021-04-10 08:54, Christopher Dimech wrote: <...snip...> If you create a very pleasant wonderful atmosphere, everybody behaves wonderfully. If you create an unpleasant atmosphere, a whole lot of people act nasty. That's how it is. This is crux of it really. For many RMS has very much created that unpleasant atmosphere full of people acting nasty, and a few decades on, some people, notably those that do significant amounts of work on a project he may have been part of two decades ago, no longer want any kind of association between their work product and the toxic environment of 'people acting nasty' that he (for a multitude of reasons) engenders. We are done here.
Re: GCC association with the FSF
On 2021-04-10 09:01, Giacomo Tesio wrote: It's fantastic how inclusive you are, isn't it? :-D Indeed you ARE inclusive to those who share your interests, like Nathan. Just not to everybody else. I share with Nathan an interest in making GCC the best C++ compiler and standard library, and like Nathan, I work to help make that the case. It is certainly true I don't have a lot of concern for the concerns of those, whose only apparent contribution to the discussion is 'oooh evil bad bigcorp's subverting mah compiler. I will go away now'. Yet I only asked to fix the Steering Committee AFTER the only credible no-profit protecting free software (FSF) was removed. But I'm a "concern troll", right? I think everybody can see who is who. ;-) Indeed.
Re: GCC association with the FSF
On 2021-04-11 12:30, Alexandre Oliva via Gcc wrote: On Apr 11, 2021, David Malcolm via Gcc wrote: I don't want to be in an environment where, it turns out, the leader of the non-profit that owns copyright on the bulk of the last 8 years of my work, and controls the license on the bulk of my work for the last 20 years, has to be patiently coached in why pedophilia is bad. AFAIK, you actually have no real say on who the company to whom you sold your services assigns *their* copyrights to. That statement is certainly not true with me and my employer. It is very much *my* decision.
Re: GCC association with the FSF
On 2021-04-11 15:23, Alexandre Oliva wrote: On Apr 11, 2021, Thomas Rodgers wrote: On 2021-04-11 12:30, Alexandre Oliva via Gcc wrote: AFAIK, you actually have no real say on who the company to whom you sold your services assigns *their* copyrights to. That statement is certainly not true with me and my employer. It is very much *my* decision. Interesting... I made my statement above because I couldn't find David's assignment on file. This told me he's covered by Red Hat's assignment, which supported my statement. Now, I can't find an assignment on file for you either. What gives? 1) I *should* have an assignment on file with the FSF (I certainly have an email trail in my archives on the matter that indicated such, however..). The paperwork was initiated before I started at Red Hat, my sense of the process was it's a disorganized shit show at the FSF for processing these things (or was at the time so who knows, maybe it's better now?, but I suspect not...for fairly obvious reasons) and I didn't actively pursue confirmation that everything was fully set, because I had RH's blanket assignment to operate under and I didn't have any expectation I'd need to deal with a separate assignment any time soon at that point for work on libstdc++. 2) So, I have done my libstdc++ work to date under RH's assignment to the FSF. Before that happened, however, I did work as a Red Hat employee to bring what was a the time, Intel's standalone C++ parallel algorithms implementation into a state where it could be contributed to libstdc++ as Intel had offered. Intel *also* offered the implementation to libc++. The work I did to bring the implementation in line with the requirements for being part of the standard library is largely the same between libstdc++ and libc++, and it was decided that we'd contribute the work to the LLVM project and relicense under those terms. Then I'd contribute *that* relicensed work to libstdc++. So, to this point, no work had been done in the libstdc++ codebase, just Intel's upstream repo. This required Intel's lawyers to get a copyright assignment from me. This in turn required me to talk to Red Hat's lawyers. Where upon I learned, as long as Red Hat employees' work is done under an approved open source/free software license, Red Hat does not assert ownership over the work. As a result, Red Hat confirmed they had no involvement in relicensing the work that they had paid for. This is not a common situation with corporate work, I grant you. But it is very much the case with Red Hat's employee contributions that Red Hat does not itself assert ownership of the work they do. This means, in particular, that it is the decision of the Red Hat folks who work on GCC to continue doing so under the current terms, or, as Jonathan has indicated, to not do it under those terms.
Re: GCC association with the FSF
On 2021-04-11 16:29, Thomas Rodgers wrote: On 2021-04-11 15:23, Alexandre Oliva wrote: On Apr 11, 2021, Thomas Rodgers wrote: On 2021-04-11 12:30, Alexandre Oliva via Gcc wrote: AFAIK, you actually have no real say on who the company to whom you sold your services assigns *their* copyrights to. That statement is certainly not true with me and my employer. It is very much *my* decision. Interesting... I made my statement above because I couldn't find David's assignment on file. This told me he's covered by Red Hat's assignment, which supported my statement. Now, I can't find an assignment on file for you either. What gives? 1) I *should* have an assignment on file with the FSF (I certainly have an email trail in my archives on the matter that indicated such, however..). The paperwork was initiated before I started at Red Hat, my sense of the process was it's a disorganized shit show at the FSF for processing these things (or was at the time so who knows, maybe it's better now?, but I suspect not...for fairly obvious reasons) and I didn't actively pursue confirmation that everything was fully set, because I had RH's blanket assignment to operate under and I didn't have any expectation I'd need to deal with a separate assignment any time soon at that point for work on libstdc++. 2) So, I have done my libstdc++ work to date under RH's assignment to the FSF. Before that happened, however, I did work as a Red Hat employee to bring what was a the time, Intel's standalone C++ parallel algorithms implementation into a state where it could be contributed to libstdc++ as Intel had offered. Intel *also* offered the implementation to libc++. The work I did to bring the implementation in line with the requirements for being part of the standard library is largely the same between libstdc++ and libc++, and it was decided that we'd contribute the work to the LLVM project and relicense under those terms. Then I'd contribute *that* relicensed work to libstdc++. So, to this point, no work had been done in the libstdc++ codebase, just Intel's upstream repo. This required Intel's lawyers to get a copyright assignment from me. This in turn required me to talk to Red Hat's lawyers. Where upon I learned, as long as Red Hat employees' work is done under an approved open source/free software license, Red Hat does not assert ownership over the work. As a result, Red Hat confirmed they had no involvement in relicensing the work that they had paid for. This is not a common situation with corporate work, I grant you. But it is very much the case with Red Hat's employee contributions that Red Hat does not itself assert ownership of the work they do. This means, in particular, that it is the decision of the Red Hat folks who work on GCC to continue doing so under the current terms, or, as Jonathan has indicated, to not do it under those terms. I'd add that, while uncommon, it does make a lot of sense for a company like Red Hat, whose default stance is to open source everything that can be open sourced. If Red Hat has the same rights to the work that Red Hat is making available to everyone else by funding that work to be done in the first place, there isn't much need to assert additional copyright ownership over the work. Obligatory disclaimer - This was based on my experience with Red Hat legal, and what I was told by them during this particular process. It is not to be construed as any public statement of policy.
Re: A suggestion for going forward from the RMS/FSF debate
On 2021-04-17 10:40, Ville Voutilainen via Gcc wrote: On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote: I do not see people really intending to fork. It explains why detractors have gone berserk. I appreciate your colorful exaggerations, but I should point out that the libstdc++ maintainer has stated his intention to fork, in unambigous terms. A helper elf of his has stated that he will follow the fork, if it occurs. I'm politely entertaining the possibility that you missed that, but Mr. Wakely is not joking when he indicates that he wishes to do a non-FSF fork of lbistdc++. On the helper elf front, I can concretely state that I will not (for the foreseeable future) be assigning copyright to FSF on *new* concurrency and parallelism related features in libstdc++ or the support libraries for this work to the FSF.
Re: A suggestion for going forward from the RMS/FSF debate
On 2021-04-17 12:08, Christopher Dimech wrote: Thomas, So we are decided? I am not pushing anybody down the cliff - rms, you or anybody. I simply wish that after a few world wars, people start seeing the light and things will be somewhat blissed out working on free software. In a lot of ways this is pretty simple for me. Having observed a few weeks of the FSF's ham-fisted response to the ham-fisted way in which they handled a this entire matter, makes it very easy for *me* to arrive at the stance that the *current state* of the FSF is such that I don't personally believe it has the ability to be a good steward of the work that is assigned to it going forward, and so *I* am not going to do that thing in particular as long as that remains the case. I'll see my work in GCC11 through (there's one remaining patch review to address this week); I don't like leaving things in a half assed state if I can avoid it. The work to finish out C++20 library support features which passed through the Concurrency and Parallelism study group (SG-1) in WG21 on their way to being standardized will be, for now, done in a public repo with GPL license sans-FSF assignment. Other work which I have initiated to replace the dependency on Thread Building Blocks within the Parallel STL algorithms (PSTL); something required for this part of libstdc++ to no longer be marked 'experimental' will not be done with a GPL license and will not, as a result, be assigned to the FSF. It is my hope, and expectation, that that work will become part of GCC12 and GCC13 respectively, and I will know in the fullness of time if that expectation is to be met.
Re: A suggestion for going forward from the RMS/FSF debate
On 2021-04-17 20:10, Christopher Dimech via Gcc wrote: You have specified that the community does not require my approval or that of Eric Raymond. That is true of course. But many have gone through so much new age training that they ended up with a very sophisticated way of bullshitting themselves. Regards Christopher I'll see my work in GCC11 through (there's one remaining patch review to address this week); I don't like leaving things in a half assed state if I can avoid it. The work to finish out C++20 library support features which passed through the Concurrency and Parallelism study group (SG-1) in WG21 on their way to being standardized will be, for now, done in a public repo with GPL license sans-FSF assignment. Other work which I have initiated to replace the dependency on Thread Building Blocks within the Parallel STL algorithms (PSTL); something required for this part of libstdc++ to no longer be marked 'experimental' will not be done with a GPL license and will not, as a result, be assigned to the FSF. Using a GPL and assigning copyright are two different things though. Uhm, well, Duh? I guess...not sure what your point is, but mine is - I'm only going to do one of those things for the time being for libstdc++ work, and do precisely neither of those things on the runtime component I expect to eventually replace TBB with in the PSTL. It is my hope, and expectation, that that work will become part of GCC12 and GCC13 respectively, and I will know in the fullness of time if that expectation is to be met.
Re: A suggestion for going forward from the RMS/FSF debate
On 2021-04-18 00:38, Christopher Dimech via Gcc wrote: Listen very carefully - In the first quarter of 2011, Keith Chuvala began discussing the need to drop all proprietary systems used to command the ISS. He specifically mentioned products from Microsoft and Red Hat. This was communicated to General Paul Martin, who then reported everything to the US House Subcommittee on Investigations and Oversight. And yet, here we are 10 years later, the ISS is still running RHEL...
Re: removing toxic emailers
On 2021-04-18 23:29, Jonathan Wakely via Gcc wrote: On Mon, 19 Apr 2021, 02:41 Frosku, wrote: On Sun Apr 18, 2021 at 9:22 PM BST, Alexandre Oliva via Gcc wrote: That's why it's best to dissent politely, lest they incorrectly conclude their opinions are consensual, or majoritary, just because they've driven dissenters into silence. The problem is, Alex, that the trolls mostly haven't been on the dissenting side. All of the childish namecalling -- "jerks", "trolls", "crazies" -- and the insinuations that our voices aren't worth listening to because we don't get paid $250,000 a year by Google to contribute to GCC all day are coming from the pro-forking side. Google doesn't pay anybody to work on GCC all day. You know nothing about GCC or the "problems" you're complaining about. Your input to this conversation is not constructive. Once upon a time, free software developers understood that users' opinions were as valid as contributor's opinions. That depends on the user. Once upon a time, free software's developers *were* it's primary users, i.e. they built the technology for themselves and made it freely available in the hope that it would be useful to others. It's also the case that the vast majority of GCC *current* users are not here making proclamations about what GCC's project governance should be. Rather it's a vocal and vanishingly small minority, who have contributed nothing of value, code or insights, and continue to vocally do so. Many of GCC's users are, however, watching in horror at the absolutely amateurish way in which this is playing out and wondering if their long term commitment should be to using this piece of software to build their products/businesses.
Re: Public discussions on GNU Project governance.
Is it ok to say Carlos is f'n awesome? You know, to keep it positive :) Carlos O'Donell writes: > GNU Maintainers, developers, volunteers, etc., > > This relates to all of our projects and how they operate. Please take > a minute and look over this email. > > This is an invitation to a public discussion about GNU Project governance > by GNU maintainers, developers, volunteers, etc. > > Discussions will take place on a moderated mailing list gnu-misc-discuss: > https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss > > Mark Wielaard has kicked this off with a post about his ideas: > https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-10/msg2.html > > Please feel free to post your own ideas and opinions about governance > and how it relates to the GNU Project. > > Please keep the conversations kind [1] and strictly about governance and > not about specific people and their respective abilities. If you need an > example: "Carlos O'Donell is an aweful leader and speller" is off-topic, > but "I would like an autocratic model where we have one leader for life > who passes this on to the next leader" is on-topic. > > If you have any questions please don't hesitate to ask me.
Re: 1-800-GIT-HELP
Paul Smith writes: > On Mon, 2020-01-13 at 11:33 +, Jonathan Wakely wrote: >> I imagine a lot of people are going to feel lost in the first few >> weeks of using Git. > > I don't do IRC (and I'm not a GCC dev :)) but I'm happy to help via email. > > One thing I'll say though: if you're an Emacs user then IMO you should run, > not walk, to your nearest MELPA site and install the Magit package. > > https://magit.vc/ > > https://magit.vc/manual/magit/Installing-from-Melpa.html#Installing-from-Melpa > > It will make your day-to-day Git use much more pleasant. It provides a > single "status" buffer that shows you the current state of your workspace > and allows you to do everything from the very simple "commit all modified > files", to the more complex "pick and choose individual diff hunks to > commit". It provides Emacs-based interfaces to everything from push/pull > to merging to interactive rebasing. > > The Emacs VC integration with Git is pretty nice, but Magit takes things to > a whole different level. True, but be forewarned, Magit can be a bit slow on the GCC git repo.
Re: 1-800-GIT-HELP
I am also happy to help Jonathan Wakely writes: > I imagine a lot of people are going to feel lost in the first few > weeks of using Git. > > If you are stuck or confused about using Git for GCC development and > too embarrassed to ask in public, feel free to contact me on IRC. I'm > jwakely on OFTC, redi on Freenode. > > It would be nice if other experienced Git users make themselves > available the same way. Please reply to this thread if you're willing > to help. > > This offer is only for GCC devs, using Git for GCC work, not just free > Git support for anybody!
Re: 1-800-GIT-HELP
Thomas Rodgers writes: > I am also happy to help > rodgertq on freenode and oftc > Jonathan Wakely writes: > >> I imagine a lot of people are going to feel lost in the first few >> weeks of using Git. >> >> If you are stuck or confused about using Git for GCC development and >> too embarrassed to ask in public, feel free to contact me on IRC. I'm >> jwakely on OFTC, redi on Freenode. >> >> It would be nice if other experienced Git users make themselves >> available the same way. Please reply to this thread if you're willing >> to help. >> >> This offer is only for GCC devs, using Git for GCC work, not just free >> Git support for anybody!
Re: Are the extended algorithms in the header file going to be supported by gcc ?
There is work ongoing to complete C++17 support in libstdc++, this includes providing support for the C++17 parallel algorithms. Marco Ippolito writes: > Hi, > > the good book "C++17 STL Cookbook" in chapter 9 "Parallelism and > Concurrency" describes some of the 69 algorithms that were extended to > accept execution policies in order to run parallel on multiple cores. And, > according to the provided examples, they all greatly simplify some aspects > of parallelization with the standard algorithms. > > I'm using Ubuntu 16.04 with upgraded gcc version 7.2.0 (Ubuntu > 7.2.0-1ubuntu1~16.04) and the header file is not present. > > In the official gcc documentation: https://gcc.gnu.org/onlinedocs/libstdc++/ > manual/status.html the support to is flagged as "no" in > the Table 1.5. C++ 2017 Implementation Status, > and it seems that it is even not foreseen to be included in the upgraded > gcc 8 version: https://gcc.gnu.org/projects/cxx-status.html > > So, the crucial question about these 69 extended algorithms in the header > file is: > are these extended algorithms going to be supported by the next releases of > gcc, as they are already supported by Visual Studio, and soon by clang ? > > Looking forward to your kind feedback about this extremely important aspect > of gcc. > Marco
Re: Are the extended algorithms in the header file going to be supported by gcc ?
Major GCC releases ship once per year, roughly in May. You can however, today, use the Intel free standing implementation until libstdc++ formally ships with support. See - https://github.com/intel/parallelstl - Tom Marco Ippolito writes: > Hi Thomas, > since simplied and efficient parallelism is actually super-needed in a > world where fast, simple ed efficient software is paramount, when do you > reasonably foresee GCC9 shipping containing the C++17 parallel algorithms? > > Marco > > Il giorno lun 21 mag 2018 alle ore 14:32 Thomas Rodgers > ha scritto: > >> >> Marco Ippolito writes: >> >> > Which gcc release will include the support for the C++17 parallel >> > algorithms? >> >> The expectation is they will ship as part of GCC9. >> >> - Tom >> >>
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines.
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report.
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 17:23, Thomas Rodgers wrote: On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report. Specifically - /tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/semaphore_base.h:259: error: #error "No suitable semaphore implementation available"
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 18:08, David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers wrote: On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report. You now have pinpointed the problem. It's not that AIX doesn't have semaphore, but that the code previously had a fallback that hid a bug in the macros: #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE // Use futex if available and didn't force use of POSIX using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>; #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE using __fast_semaphore = __platform_semaphore; #else using __fast_semaphore = __atomic_semaphore; #endif The problem is that libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h contains #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1 And bits/semaphore_base.h is not testing that corrupted macro. Either semaphore_base.h needs to test for the corrupted macro, or libtsdc++ configure needs to define HAVE_POSIX_SEMAPHORE without itself prepending _GLIBCXX_ so that the c++config.h rewriting works correctly and defines the correct macro for semaphore_base.h. Thanks, David By the way, you can see the bug in the macro name on any Linux system and reproduce the failure on any Linux system if you force it to fallback to POSIX semaphores instead of Linux Futex or atomic wait. Thanks, David Ok, I'll see if I can get a patch out before calling it a night. Thanks! Tom.
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 18:08, David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers wrote: On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report. You now have pinpointed the problem. It's not that AIX doesn't have semaphore, but that the code previously had a fallback that hid a bug in the macros: #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE // Use futex if available and didn't force use of POSIX using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>; #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE using __fast_semaphore = __platform_semaphore; #else using __fast_semaphore = __atomic_semaphore; #endif The problem is that libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h contains #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1 And bits/semaphore_base.h is not testing that corrupted macro. Either semaphore_base.h needs to test for the corrupted macro, or libtsdc++ configure needs to define HAVE_POSIX_SEMAPHORE without itself prepending _GLIBCXX_ so that the c++config.h rewriting works correctly and defines the correct macro for semaphore_base.h. Thanks, David By the way, you can see the bug in the macro name on any Linux system and reproduce the failure on any Linux system if you force it to fallback to POSIX semaphores instead of Linux Futex or atomic wait. Thanks, David I think the attached patch (also in BZ) addresses the issue in bits/semaphore_base.h, but I'm going to defer to Jonathan on why the macro name is being transformed incorrectly in the first place.From b1892fe84fb702ff3085eee8a062bc8606e5566a Mon Sep 17 00:00:00 2001 From: Thomas Rodgers Date: Tue, 20 Apr 2021 21:56:21 -0700 Subject: [PATCH] [libstdc++] Work around for PR100164 As dje@gmail.com pointed out, the _GLIBCXX_HAVE_POSIX_SEMAPHORE macro is being munged into _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE. This caused the detection logic in bits/semaphore_base.h to not define __platform_semaphore. Fixing this uncovered the issue that __platform_semaphore::_M_try_wait() was missing. This patch works around the former issue and addresses the latter issue. libstdc++-v3/ChangeLog: * include/bits/semaphore_base.h: Define __platform_semaphore::_M_try_wait(), temporarily adjust detection macro to reflect the actual name being generated during configuration. * testsuite/30_threads/semaphore/try_acquire_posix.cc: Force use of Posix semaphores if available and always run the test. --- libstdc++-v3/include/bits/semaphore_base.h| 27 --- .../30_threads/semaphore/try_acquire_posix.cc | 15 --- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/libstdc++-v3/include/bits/semaphore_base.h b/libstdc++-v3/include/bits/semaphore_base.h index 7e3235d182e..5c687bfae6f 100644 --- a/libstdc++-v3/in
Re: Update to GCC copyright assignment policy
On 2021-06-01 07:28, Mark Wielaard wrote: Hi David, On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: The GCC Steering Committee has decided to relax the requirement to assign copyright for all changes to the Free Software Foundation. GCC will continue to be developed, distributed, and licensed under the GNU General Public License v3.0. GCC will now accept contributions with or without an FSF copyright assignment. This change is consistent with the practices of many other major Free Software projects, such as the Linux kernel. Contributors who have an FSF Copyright Assignment don't need to change anything. Contributors who wish to utilize the Developer Certificate of Origin[1] should add a Signed-off-by message to their commit messages. Developers with commit access may add their name to the DCO list in the MAINTAINERS file to certify the DCO for all future commits in lieu of individual Signed-off-by messages for each commit. This seems a pretty bad policy to be honest. Why was there no public discussion on this? I certainly understand not wanting to assign copyright to the FSF anymore given the recent board decisions. But changing GCC from having a shared copyright pool to having lots of individual (or company?) copyright holders seems like a regression for a strong copyleft project. With individual copyright holders companies no longer have clear way to know whether they are in compliance unless they talk to each and every individual copyright holder (see also the linux kernel, where there are some individuals who randomly sue companies just to get some money to drop the lawsuit). And for users it will be harder to get compliant sources if they can no longer simply ask the shared copyright holder, but instead will have to get enough individual copyright holders to get a distributor into compliance. If we no longer want the FSF to be the legal guardian and copyright holder for GCC could we please find another legal entity that performs that role and helps us as a project with copyleft compliance? Personally, this would have been my preference. I would be happy to setup a shared copyright pool under the Conservancy Copyleft Compliance project for example: https://sfconservancy.org/copyleft-compliance/ Thanks, Mark
