Re: Deprecating arithmetic on std::atomic
On 19 April 2017 at 20:07, Jonathan Wakely wrote: > I know it's a bit late, but I'd like to propose deprecating the > libstdc++ extension that allows arithmetic on std::atomic. > Currently we make it behave like arithmetic on void*, which is also a > GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html). > We also allow arithmetic on types such as std::atomic which > is probably not useful (PR 69769). > > C++11 and C++14 were silent on the matter, but C++17 makes it > explicitly ill-formed (see https://wg21.link/p0558r1 page 2). I'm > implementing that for C++17 mode but would like it to be ill-formed > for all modes in a future release. > > So I'd like to apply this patch to the gcc-7/changes.html page: > > --- htdocs/gcc-7/changes.html 17 Apr 2017 22:12:35 - 1.77 > +++ htdocs/gcc-7/changes.html 19 Apr 2017 17:05:27 - > @@ -38,6 +38,10 @@ > > > The Cilk+ extensions to the C and C++ languages have been > deprecated. > + > + The extension allowing arithmetic on > std::atomic> + and types like std::atomic > + has been deprecated. > > > > > > Does this seem reasonable, or do people think we need to keep this > feature, to match the core language extensions? > I think it's reasonable. If users report massive concerns, we can certainly un-deprecate it. At the moment all that deprecation is doing for non-C++17 modes is giving users a fair warning of things to be aware of, and we can get feedback on that.
Re: Delegating Constructors?
On 7 November 2011 03:58, Miles Bader wrote: > Hi, I'm wondering whether there's been any progress on the recent > "Delegating Constructors" patch: > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01202.html > The last post on that thread (in gcc-patches) was early last month. > There doesn't seem to have been any objection, just minor review-type > comments, and it sounded like it was in pretty good shape, but the > thread eventually just sort of petered out. > Is this likely to go in for 4.7? As far as I know, all the review comments have been fixed, I posted a patch that fixed the unwanted whitespace changes and such. It's pending copyright paperwork from the author of the original patch. (my copyright paperwork is in order, but since I didn't write all of it, there's some crossing t's and dotting i's). I don't know about release schedules, so I can't say whether it will make it for 4.7 or not.
Re: Delegating Constructors?
>> It's pending copyright paperwork from the author of the original patch. >> (my copyright paperwork is in order, but since I didn't write all of it, >> there's some crossing t's and dotting i's). >Hmm, has he been contacted recently? The original patch was from ages >ago... >Thanks, >-Miles Jason has contacted Pedro, and Jason's been handling the copyright issues for that patch towards FSF as well. I don't subscribe to the gcc mailing list, if you have questions, please cc me. :)
Re: Expose 'array_length()' macro in
On Tue, 22 Sep 2020 at 01:07, Jonathan Wakely via Libstdc++ wrote: > ># define array_length(arr)(std:size(arr)) > > C++ programmers will not accept a macro for this. ..in other words, the C++17 version of it needs to be an inline function that returns std::size of an array, not a macro. All C++ versions need to be functions, and there should not be any #defines in any of the C++ code. Why should this be array_length and not __array_length? This is a vendor extension, so it should use a name that is reserved for such?
Re: [libc-coord] Re: Expose 'array_length()' macro in or
On Tue, 22 Sep 2020 at 19:46, Jonathan Wakely via Libstdc++ wrote: > > On 22/09/20 12:25 -0400, Rich Felker wrote: > >Is there really a reason to want a nonstandard macro like this to do > >something that's already trivial to do in the base language and has a > >standard idiom (sizeof x / sizeof *x)? > > IMHO no. While it's anciently stupid that that trick needs to be learned by every programmer instead of having something straightforward readily available, I can't become a fan of this direction when it introduces lowercase macros that might clash with something existing or something that other people will want to write. And yes, I know, we can't do any better in C, due to array decay.
Re: [RFC] Increase libstdc++ line length to 100(?) columns
On Fri, 27 Nov 2020 at 10:16, Richard Biener via Libstdc++ wrote: > > Why not change this to: > > > > > if (present) > > > ptr = gfc_build_conditional_assign_expr ( > > > block, present, ptr, nullarg); > > > > > > > I think it looks balanced and way more comfortable, and doesn't waste much > > leading space. > > Other places use > >if (present) > ptr = gfc_build_conditional_assign_expr > (block, present, ptr, nullarg); > > I prefer the ( on the next line. The argument list can be two spaces > indented from > the function name or "right justified" (I think the latter looks > visually better). I find it easier to grok the code when the opening paren is on the first line, I know instantly that I'm looking at a function call. That sort of style probably fits better the C++ code in libstdc++ than the code in gcc, because in libstdc++ code we don't have a space before the argument list.
Re: [RFC] Increase libstdc++ line length to 100(?) columns
On Fri, 27 Nov 2020 at 11:54, Liu Hao via Libstdc++ wrote: > As you can see, qualified names in C++ can grow up to ~100 characters quite > frequently. This may > deteriorate when `typename` and `template` are sometimes required. I don't > think there is > practically a set of rules which governs all cases. So, if something looks > better, go for it, and > that's why I think a (suggested) 100-char limit is better than the > conventional 80-char limit, which > forces another line break in front of `select_on_container_copy_construction`. I do have a general question/thought/rumination here, though. Shouldn't the paren-style and the line length of libstdc++ be mainly decided by those who develop and maintain it? It's already not written in the same style as gcc is, so tweaking that different style to better suit the need of a template-heavy C++ library perhaps should be more or less a slam dunk? :) Despite my sizable contributions to libstd++, I don't have a particularly strong opinion here. Except that, my somewhat strong opinion is "let's give Jonathan what he wants, because it helps his work". ;)
Remove RMS from the GCC Steering Committee
Giacomo wrote: >Stallman cannot betray Free Software AND get away with it. >So to me (and to many others) Stallman is a sort of a living warranty. That's fine. He doesn't need to be in the GCC SC to do that. He can continue to provide guidance on the spirit of Free Software without having an SC position, or any official leadership position. The people in the GCC SC are very reasonable people; I have worked with some of them, and they will listen to reasonable arguments. RMS doesn't have veto powers anyway, and doesn't need them. The proposed removal from the SC doesn't prevent RMS from giving the aforementioned guidance in any way, nor does it even make it any more difficult. In fact, that removal shouldn't have any effect on his ability to give such guidance, nor does it actually have any effect on what the consequences of his guidance will be. The warranty you speak of does not boil down to a particular individual being there in the SC. That's by RMS's own design; the copyright and the license give you that warranty, not the SC presence of any single person. And a removal from an SC doesn't equal the removal from the set of people who can meaningfully contribute. That is certainly, I would think, not the intent of anyone who has spoken in favor of the removal. There is certainly a fair amount of heat in this discussion. Whether the proposed removal has the effects it seeks, I don't know. But I don't buy the surreptitious suggestions that the proposed removal somehow spells doom for the continued availability of GCC as Free Software, or for the spirit of Free Software in general. In my anecdotal case, it doesn't. I have fairly good reasons to think that it doesn't spell such doom for quite many other contributors to these projects, some far more frequently active than me. I am, Yours Most Sincerely, Ville Voutilainen an occasional libstdc++ contributor a less-frequently occasional g++ contributor
GCC association with the FSF
>However, the FSF does NOT control nor own the GNU project. That appears to be a very common misperception. >The FSF offers various pro-bono services to the GNU project, among them guarding some GNU assets for the GNU project, but the GNU project is an independent (unincorporated) organization, with its own separate and independent governance structure. >The conversation has supposedly moved on from being centered on the (very indirect) relationship with RMS to being centered around the (even more indirect) relationship with the FSF. >The trigger for the present movements seems to be RMS's reappointment to the board of directors of the FSF. >That makes no sense to me. Really? Well, it makes some amounts of sense to me. See below. >RMS's closest roles regarding GCC have been of initial developer, leader of the project that GCC belongs in, and occasional participant in discussions among the GCC SC, and none of this has changed recently. >What is the relevance of his reappointment to the board of a separate organization he's founded, long participated in, and presided for most of its history, and that has supported both the GNU project at large and the GNU toolchain specifically, in ways that haven't changed at all, not when he resigned from the board, not when he was reappointed?!? >Can anyone come up with any rational motivation for this move right now? This is fairly straightforward. FSF is not as separate an organization as you wish to depict it. It owns the copyright to GCC, and people associated with it have decided to act as the PR department of GCC developers. Multiple maintainers would rather not have that PR department, as they consider it a PR disaster. They'd rather improve the PR department, but if that can't be accomplished, another solution is to disassociate their work from FSF and the PR department. I don't love Jonathan Wakely's idea of forking libstdc++. I would much rather not have that fork happen. But I will follow that fork. I know him well enough that trying to talk him out of doing the fork is unlikely to succeed, we're far beyond the stage where such talking-out is on the table. This, of course, allows us to actually _see_ whether the predictions of doom and gloom will materialize if FSF and RMS are no longer associated with the work of various GCC developers. It also allows us to see how viable the origin of the fork is, when there sure are people suggesting that it can be lead by non-developers, but fair amounts of developers will just go elsewhere. If you wish to hear my wild guesses on those, they are a) that the doom and gloom will not materialize b) the origin of the fork will not remain viable. Bring on the forks. We have ruminated on this long enough, and that seems like a waste of bandwidth. The messages the various developers are conveying are not getting through, or are sinking into an abyss of neverending discussions about something completely different from what the developers are saying.
A suggestion for going forward from the RMS/FSF debate
Huge apologies for mis-sending this to gcc-patches, my email client makes suggestions when I attempt to send to a gcc list. :D The actual suggestion is at the end; skip straight to it if you wish. >Im glad there are people like you on the project Eric, because you express exactly what a lot of people see - even if a minority of people chose to ignore it, >To a lot of "non americans", the events on here appear as nothing more than a power grab by a small minority of developers, abusing their position and american corporate ideologies to enact change, ignoring any one who dares question or disagree unless they fit into a clique they have built (and want to maintain by ostracizing people they deem unworthy), brandishing them jerks, trolls, toxic and other childish names. Im glad there are a few devs that can see this, but it feels like they are stepping on egg shells (despite the rhetoric about how well the people in said clique can communicate on technical matters). That's a) incorrect b) beside some rather important points. The "small minority of developers" you speak of sure seems to consist of developers who are not in the minority considering how much they _actually contribute_ to the project. Some of them don't need to perform a "power grab"; they already have all the power fathomable, by virtue of being maintainers and active developers. This whole discussion, again, at least to me, boils down to two things, actually three: 1) is the technical leadership of RMS/GNU/FSF useful for the project? Is it beneficial, or harmful? 2) is the PR/public-face position of RMS/FSF useful for the project? Is it beneficial, or harmful? 3) Who should make decisions related to that? The developers and maintainers, or people who are neither of those, but are certainly vocal in these discussions? On the first part, other people have touched on it already, but the fear of a dreaded non-free software vendor co-opting GCC as a library to a non-free project has resulted in GCC being unsuitable to be used as a library in free software projects. This approach alone made sure that the meteoric rise of LLVM happened; there are recorded statements from LLVM developers trying to talk about this to RMS, and the answer, as they phrased it, "wasn't useful", because RMS decided that GCC shouldn't be a library to make it harder to use it in conjunction with non-free programs. Congratulations, it remains hard to use in conjunction with free programs, and everybody who wants to do something like that looks at LLVM first. RMS made a lofty attempt to promote copyleft software for such purposes, and failed miserably, leading us into a situation where such problems are not solved with copyleft software, but with LLVM instead. On the second part, we can discuss whether the reasons for various people not wanting RMS/FSF to be the PR department of GCC developers are sound, or whether we agree with them, until the cows come home. But that doesn't matter. Bad PR is bad PR, and it seems strikingly simple to consider trying a PR department that doesn't have the baggage of the previous one. And if you ask me, *that* should be a choice of the developers and maintainers, and them alone. It's their work; they should have a say in who and what the public face of the work is to the outside world. Whether their choice is made because they live a pampered and cosseted life is very much secondary. I don't have to agree with every viewpoint of the people who have suggested that RMS shouldn't lead this project, or that this project shouldn't necessarily be tied to FSF any more. I don't even need to "accept" it. I don't consider it something that needs my approval or acceptance, I'm not a maintainer or a major contributor. However, I consider it something that needs even LESS acceptance or approval of ESR or Mr. Dimech or various other people. I happen to have Write-After-Approval permission for this project. They don't. Because they're not members of this project, they don't contribute code to it. Finally, with regards to there existing a power grab or a sinister corporation plot to take GCC away from being "accountable to its community": 1) that's just pure horseshit. The people wanting to disassociate the project from RMS and/or FSF worked on GCC before their current employment, and will work on GCC after their current employment. There is no power grab, and there is no sinister corporation plot, and that wouldn't work anyway due to the license and due to how the project _actually works_. 2) the project isn't accountable that way today, anyway. That concern is pure fantasy. So, I have a moderate suggestion, and I will fairly entertain it being a bold suggestion for some people: A) Detach GCC from FSF (and RMS), have it be hosted on non-gnu sites, make it a project separate from FSF, other than B) Don't drop the copyright assignment requirement, at least not yet. C) Run in that mode for a while, and see what happens. This allows re-attac
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > The "small minority of developers" you speak of sure > > seems to consist of developers who are not in the minority > > considering how much they _actually contribute_ to the project. > > Due to their being paid for the work. Have no doubt that if others > were being paid, the contributions could likely drown the current > contributors. Thus, the claim of a power grab is valid. How convenient to make that claim and just bypass what's said in the next bit: > > > Some of them don't need to perform a "power grab"; they > > already have all the power fathomable, by virtue of being maintainers > > and active developers. I very much doubt your lofty hypothesis that if "others" were being paid, the contributions would "likely drown" the current contributors. Especially when we're talking about people who have submitted pretty close to ZERO patches to GCC. You can give a claim that a person $foo would contribute if being paid to do it. I'll buy that claim if you're talking about people like Nathan Sidwell and Iain Sandoe from the time before they became active contributors again, now that they've been hired to do that. I will not buy that claim about people who haven't been GCC contributors before. > > This whole discussion, again, at least to me, boils down to two > > things, actually three: > > It can also boil down about whether people want their work to form part > of the Gnu Project or not!!! Oh, sure it can. So perhaps we should do something along the lines of what Thomas outlined: - ask the maintainers what they want to do - then do that
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, 16 Apr 2021 at 16:22, Christopher Dimech wrote: > Many do not contribute because they do not have time, resources or support. Yes? And? Even if GCC detaches itself from FSF, those who can contribute will continue to contribute. And those who talk about contributing but don't contribute will likely continue talking and not contributing. > Additionally, maintainers have always been aware that being a Gnu Maintainer > meant that coordinating activities in the GNU Project were on behalf of RMS. Fine. And if those maintainers no longer wish to be coordinating activities on behalf of RMS, they should make that decision and run with it. Or make a decision not to.
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, 16 Apr 2021 at 19:01, Jason Merrill wrote: > > On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc > wrote: > > > Sent: Saturday, April 17, 2021 at 1:03 AM > > > From: "Ville Voutilainen" > > > To: "Christopher Dimech" > > > Cc: "GCC Development" > > > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > > > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > > > The "small minority of developers" you speak of sure > > > > > seems to consist of developers who are not in the minority > > > > > considering how much they _actually contribute_ to the project. > > > > > > > > Due to their being paid for the work. Have no doubt that if others > > > > were being paid, the contributions could likely drown the current > > > > contributors. Thus, the claim of a power grab is valid. > > > > > > How convenient to make that claim and just bypass what's said in the next > > > bit: > > > > > > > > > > > > Some of them don't need to perform a "power grab"; they > > > > > already have all the power fathomable, by virtue of being maintainers > > > > > and active developers. > > > > > > I very much doubt your lofty hypothesis that if "others" were being paid, > > > the > > > contributions would "likely drown" the current contributors. Especially > > > when we're talking about people who have submitted pretty close to ZERO > > > patches to GCC. You can give a claim that a person $foo would contribute > > > if being paid to do it. I'll buy that claim if you're talking about > > > people like > > > Nathan Sidwell and Iain Sandoe from the time before they became active > > > contributors again, now that they've been hired to do that. I will not > > > buy that claim about people who haven't been GCC contributors before. > > > > There are many users of gcc who are more qualified to know what is needed > > in gcc, than developers. That does not mean than I want to diminish their > > authority for gcc. But that authority was still conferred to them by the > > the Gnu Project - which demands responsibility to carry out the assigned > > tasks to the best of their ability, not to excoriate their obligation > > towards > > the project itself. > > > > The ultimate authority is the final responsibility of the Gnu Project, > > not only that of gcc. > > Free Software means there is no ultimate authority. In Free Software, > leadership of the development process is by the "consent of the > governed". If there is sufficient objection to the existing > leadership, developers can change it, either by negotiation for > changes with the current leadership or by forking. > > The EGCS fork happened because a critical mass of developers gave up > on the GNU GCC2 leadership model. The reconciliation happened because > GNU agreed to accept the EGCS development model as GNU GCC. > > I hope to resolve the current crisis by leadership adjustments > something along the lines of Ville's proposal, rather than forking. > > Jason That's pretty much all I ask. Jason, Jeff, Thomas, others, please discuss this matter among the maintainers, and if need be, among the SC, and make a decision, or at least provide an indication of how you see these matters. I think that indication gives us megabytes more data than philosophical discussions will, entertaining as they might be.
Re: A suggestion for going forward from the RMS/FSF debate
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++.
Re: A suggestion for going forward from the RMS/FSF debate
On Sun, 18 Apr 2021 at 13:49, Richard Kenner wrote: > > > Depends on the use cases. Not in military surveillance. And certainly not > > at Lawrence Livermore National Laboratory. At Boeing could be the same, but > > I'm not sure. Before 2011, rather than building things from scratch, > > washington bureaucrats simply picked from among existing technology. But > > things had really been going berserk around 2008. From 2017 onwards, > > I'm somewhat in the dark. They could have started allowing some ownership > > rights, but ownership rights under government contracts are very different > > than ownership rights under commercial contracts. > > I can't understand your point with this version either. Sorry. I don't understand these ramblings either. LLNL sure seems to have flirted with LLVM: https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology https://www.osti.gov/servlets/purl/1608523 https://github.com/rose-compiler/rose/wiki/Install-ROSE-with-Clang-as-frontend