Re: Deprecating arithmetic on std::atomic

[Ville Voutilainen]

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?

[Ville Voutilainen]

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?

[Ville Voutilainen]

>> 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

[Ville Voutilainen via Gcc]

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

[Ville Voutilainen via Gcc]

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

[Ville Voutilainen via Gcc]

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

[Ville Voutilainen via Gcc]

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

[Ville Voutilainen via Gcc]

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

[Ville Voutilainen via Gcc]

>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

[Ville Voutilainen via Gcc]

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

[Ville Voutilainen via Gcc]

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

[Ville Voutilainen via Gcc]

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

[Ville Voutilainen via Gcc]

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

[Ville Voutilainen via Gcc]

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

[Ville Voutilainen via Gcc]

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