Re: My 2nd attempt to devel for gcc
On Sun, 28 Mar 2021, 02:20 pawel k., wrote: > Hmm, > Thanks. Not sure I can see answer from him. Ill recheck it. > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html
Re: My 2nd attempt to devel for gcc
Hello, Yea ok got it. Ill reply. I dont get email notifications from him. Ill prepare reply asap as of what we can or cannot do and what will be costs and benefits. Then he/you can decide. Best regards, Pawel niedz., 28.03.2021, 11:34 użytkownik Jonathan Wakely napisał: > > > On Sun, 28 Mar 2021, 02:20 pawel k., wrote: > >> Hmm, >> Thanks. Not sure I can see answer from him. Ill recheck it. >> > > > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html > > > >
Re: My 2nd attempt to devel for gcc
Hello, Ok fair enough. I thought cleaner separation of FE and generics interface would be useful feature. It would make adding new FE easier too hopefully. We could provide either multiple FEs per binary or not. Additionally, In single FE per binary option of my fegens cleanup scenario we could avoid calling langhooks via pointer and funcs could be statically called. As on data member read from langhooks needing mem access now, we could avoid this too and const data members would be inlined similarly to macro consts generally. But if there is no demand for fe<->generics cleanup its ok. As on your question on avoiding storing bytecode into lto and rereading it, it indeed looks like bit over the top task for me at the moment. I woukd need to researching it more deeply. What i rather meant was compiling in multiple targets and choosing via cmdline opts which one to use. As on Your questions wrt multiple targets, indeed target specific constint macro unrolling would need generally a call and additionally probably indirect one unfirtunately. If the hit on perfirmance is too big here its probably a no go. Unless we just cleanup generics target interface, then target data member reads can be as cheap as constint macro unrolling. As on command line processing, we would probably unfortunately have to make it multipass and opts unresolved in first pass would get checked against registered target opts available in 2nd pass only after targetsel option is found. Id check for availability of all required fkags in last phase where here selected target is already known. Additionally this multitarget scenario might have intermediate "generics target interface cleanup phase" which would help cleaning up this lower interface at first, posibly simplifying target autogen and unifying between constdata reads and calls to a target etc. In this phase data member reads from target will be as cheap as const int macro unrolling too. Here we can also think whether to stop at this phase or to extend it into multitarget feature. Hope all this makes my rationale bit less chaotic. If theres demand on researching and hopefully implementing any of these, please let me know. Best regards, Pawel Kunio niedz., 28.03.2021, 11:34 użytkownik Jonathan Wakely napisał: > > > On Sun, 28 Mar 2021, 02:20 pawel k., wrote: > >> Hmm, >> Thanks. Not sure I can see answer from him. Ill recheck it. >> > > > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html > > > >
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
Hi, I have tried the following examples with the fanalyzer option in g++.
1 (a)
void myFunction()
{
char *p =new char;
}
int main()
{
func();
return 0;
}
1(b)
void myFunction()
{
try {
char *p = new char;
throw p;
}
catch(...) {
}
}
int main()
{
myFunction();
return 0;
}
In 1(a), there is no exception handling. When I ran `cc1plus`, a memory
leak was reported as shown in bug #94355.
In 1(b), there is a use of exception handling. When I ran cc1plus`, no
memory leaks were detected. I believe there should be one. Can you please
confirm from your side as well? As you said all the calls to try, catch and
throw got converted to _cxa prefixed functions. I am trying to find the
places where the corresponding checks can be placed for the analysis of
exception handling in gimple IR.
Please, let me know your thoughts on this.
On Fri, Mar 26, 2021 at 12:48 AM David Malcolm wrote:
> On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote:
> > Hi all,
> > I am an undergraduate student in AMU, Aligarh. I am interested in the
> > project* `Extend the static analysis pass`. *I have followed this(
> > https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and been
> > able to
> > successfully build and successfully ran and pass the test suite for C
> > and
> > C++.
> >
> > I found this sub-project `C++ support (new/delete checking,
> > exceptions,
> > etc)` interesting and may be the conservative code for this can be
> > made
> > along the lines of malloc/free implementation in C. I found here(
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some part of
> > it
> > has already been implemented . I would like to expand it further and
> > learn
> > about it, maybe start with writing some test cases, please let me
> > know.
> >
> > Further, I am inclined on this(
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111). Let me know if
> > it is
> > still available.
> >
> > Looking forward to hearing from you guys.
> > Thanks,
> > Saloni Garg
>
> Hi!
>
> I'm the author/maintainer of the static analysis pass, and would be the
> mentor for any GSoC project(s) involving it.
>
> I've already implemented most of the new/delete checking in GCC 11; the
> big missing component there is exception-handling.
>
> Implementing exception-handling in the analyzer could make a good GSoC
> project: it's non-trivial, but hopefully doable in one summer. I see
> you've already seen bug 97111, and there are some links in that bug to
> resources. Given that the analyzer runs on the gimple-ssa
> representation, by the time it sees the code, much of the exception-
> handling has already been translated into calls to various __cxa_-
> prefixed functions in the C++ runtime, so part of the work would
> involve "teaching" the analyzer about those functions. One way to make
> a start on this would be to create a collection of trivial C++ examples
> that use exceptions, and then look at analyzer dumps to see what IR is
> being "seen" by the analyzer for the various constructs. (I actually
> started this a long time ago and have a very crude barely-working
> prototype, but it was just the start, and I've forgotten almost all of
> it...)
>
> Hope this is helpful
> Dave
>
>
>
Re: Remove RMS from the GCC Steering Committee
Alexandre, Making our community more welcoming is indeed a process. And some steps will just be symbolic. But I don't believe removing RMS from (perceived) leadership positions in the GNU project and from the FSF is just symbolic. And even for a symbolic step it is a powerful one. It shows we don't tolerate harassment in our project. And I do hope it doesn't end with that step. We also have to decide whether we still want to be associated with the FSF. Hopefully the FSF takes their responsibility and replaces the whole board to show we can start with a clean slate. One issue is that as long as GCC is associated with RMS and the FSF others who could help us won't because the FSF is that toxic now: https://www.outreachy.org/blog/2021-03-23/fsf-participation-barred/ And they are far from the only Free Software project who has said something similar. We are not talking about some single recent incident, but about decades of problematic behavior. At the last face-to-face GNU Tools Cauldron, everybody I talked to about it had some story about being harassed by RMS, had witnessed such harassment or heard from or knew someone who had been. For years people have tried to help him see how his actions and words might hurt others, even if they are completely logically correct to himself. And obviously that is sometimes hard, nobody is perfect, but hopefully we get a little better every time. But this never happened. And it really needs to stop. RMS actively undermines those who try to make our community a little bit more welcoming. Violating anti-harassment policies of conferences. Even those from the FSF by claiming to be above those policies because of his leadership position or using his position to tell staff they cannot enforce such policies against others. Because he is against enforcing any anti-harassment policy some GNU mailinglist is currently being used to organize a doxing campaign (publishing photos, address and calls to report to the local police station to get her house raided and arrested) for simply saying the same things we are discussing here now. I witnessed something similar recently when we had setup the mailinglist to discuss improving governance of the GNU project. When a female GNU (GCC) volunteer spoke up she got attacked and harassed. We told the harassers that was totally unacceptable and blocked them from sending more emails to the list. RMS arranged for those people to get unblocked to continue their hate campaign on the public GNU list so they could "defend him and the GNU project". That was followed by a torrent of hate to the list making any discussion impossible and making women feel like they were specifically targeted. He still hasn't learned that his words and actions are dog whistles for misogynists, transphobics and racists. This really has to stop. You link to a parody of a request of tens of Free Software foundation projects and thousands of Free Software hackers who are calling for the removal of the entire Board of the Free Software Foundation and for Richard M. Stallman to be removed from all leadership positions, including the GNU Project. For similar reasons that people here are now calling for RMS to be removed from the GCC steering committee. The real letter is here: https://rms-open-letter.github.io/ Sometimes satire is a way to deal with difficult problems, but I don't think that is appropriate here and I hope people take these issues seriously, because I think they are. Mark
Re: Remove RMS from the GCC Steering Committee
On Sun, 28 Mar 2021, 13:50 Mark Wielaard, wrote: > RMS actively undermines those who try to make our community a little > bit more welcoming. Violating anti-harassment policies of > conferences. Even those from the FSF by claiming to be above those > policies because of his leadership position or using his position to > tell staff they cannot enforce such policies against others. Because > he is against enforcing any anti-harassment policy some GNU > mailinglist is currently being used to organize a doxing campaign > (publishing photos, address and calls to report to the local police > station to get her house raided and arrested) for simply saying the > same things we are discussing here now. > > I witnessed something similar recently when we had setup the > mailinglist to discuss improving governance of the GNU project. When a > female GNU (GCC) volunteer spoke up she got attacked and harassed. We > told the harassers that was totally unacceptable and blocked them from > sending more emails to the list. RMS arranged for those people to get > unblocked to continue their hate campaign on the public GNU list so > they could "defend him and the GNU project". That was followed by a > torrent of hate to the list making any discussion impossible and > making women feel like they were specifically targeted. He still > hasn't learned that his words and actions are dog whistles for > misogynists, transphobics and racists. This really has to stop. > We even have a GNU maintainer* with no link to GCC sending abusive emails in this thread, because he feels such harassment is acceptable. * He is listed as maintainer on gnu.org despite the project having no public release and an empty repo. It looks like vapourware that only exists in his head, but he's still a proud "GNU maintainer". If that's who GNU welcomes, count me out.
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote:
> Hi, I have tried the following examples with the fanalyzer option in
> g++.
>
> 1 (a)
> void myFunction()
> {
> char *p =new char;
> }
> int main()
> {
> func();
> return 0;
> }
BTW, are you familiar with Compiler Explorer (godbolt.org)? It's very
handy for testing small snippets of code on different compilers and
different compiler versions. Though I don't know how long the URLs are
good for (in terms of how long code is cached for)
Fixing up the name of the called function to "func":
https://godbolt.org/z/TnM6n4xGc
I get the leak report, as per RFE 94355. This warning looks correct,
in that p does indeed leak.
I should mention that the analyzer has some special-casing for "main",
in that the user might not care about one-time leaks that occur within
"main", or something only called directly by it; this doesn't seem to
be the case here. If I remove the implementation to main, the analyzer
still correctly complains about the leak:
https://godbolt.org/z/zhK4vW6G8
: In function 'void func()':
:4:1: warning: leak of 'p' [CWE-401] [-Wanalyzer-malloc-leak]
4 | }
| ^
'void func()': events 1-2
|
|3 | char *p =new char;
| | ^~~~
| | |
| | (1) allocated here
|4 | }
| | ~
| | |
| | (2) 'p' leaks here; was allocated at (1)
|
> 1(b)
> void myFunction()
> {
> try {
> char *p = new char;
> throw p;
> }
> catch(...) {
> }
> }
> int main()
> {
> myFunction();
> return 0;
> }
> In 1(a), there is no exception handling. When I ran `cc1plus`, a
> memory
> leak was reported as shown in bug #94355.
> In 1(b), there is a use of exception handling. When I ran cc1plus`,
> no
> memory leaks were detected. I believe there should be one. Can you
> please
> confirm from your side as well?
I too am seeing no diagnostics on 1(b).
> As you said all the calls to try, catch and
> throw got converted to _cxa prefixed functions.
-fdump-ipa-analyzer=stderr shows the _cxa-prefixed functions:
https://godbolt.org/z/YMa9dE6aM
> I am trying to find the
> places where the corresponding checks can be placed for the analysis
> of
> exception handling in gimple IR.
Have a look at exploded_node::on_stmt in engine.cc; in particular, see
the GIMPLE_CALL case in the switch statement. Most of the the
analyzer's "knowledge" of the behaviors of specific functions is here,
or called from here.
The simpler cases are handled in the call to
m_region_model->on_call_pre
for functions which merely update state, which are implemented in
region-model-impl-calls.cc
Cases involving state machines (e.g. allocation) are handled in the:
sm.on_stmt
call torwards the bottom of the function.
But exception-handling is a special case, in that it affects control
flow. The closest thing to compare it to currently within the analyzer
is setjmp/longjmp, so it's worth stepping through how that is handled.
In particular, the real implementation of longjmp involves directly
updating the program counter, registers and stack, potentially popping
multiple stack frames. This is similar to what throwing an exception
does.
So I'd recommend looking at the analyzer's implementation of
setjmp/longjmp, the custom classes that I added to handle them, and
stepping through how exploded_node::on_stmt handles setjmp and longjmp
calls, and what the resulting exploded_graph looks like (-fdump-
analyzer-exploded-graph and -fdump-analyzer-supergraph), in that
special-cased edges have to be created that weren't in the original
CFGs or callgraph (for the interprocedural case).
I think an implementation of exception-handling would look somewhat
similar.
> Please, let me know your thoughts on this.
Looks like you're making a great start.
Hope this is helpful
Dave
> On Fri, Mar 26, 2021 at 12:48 AM David Malcolm
> wrote:
>
> > On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote:
> > > Hi all,
> > > I am an undergraduate student in AMU, Aligarh. I am interested in
> > > the
> > > project* `Extend the static analysis pass`. *I have followed
> > > this(
> > > https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and
> > > been
> > > able to
> > > successfully build and successfully ran and pass the test suite
> > > for C
> > > and
> > > C++.
> > >
> > > I found this sub-project `C++ support (new/delete checking,
> > > exceptions,
> > > etc)` interesting and may be the conservative code for this can
> > > be
> > > made
> > > along the lines of malloc/free implementation in C. I found here(
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some
> > > part of
> > > it
> > > has already been implemented . I would like to expand it further
> > > and
> > > learn
> > > about it, maybe start with writing some test cases, please let me
> > > know.
> > >
> > > Further, I am inclined on th
Re: Remove RMS from the GCC Steering Committee
Dear GCC Community,
Hi. My name is JeanHeyd Meneide, my online moniker is "ThePhD"
(not an actual Doctor. Yet!). I spend a lot of my time hacking on C
and C++. Some of the things I've done include:
- Contributing (mostly) a Implementation [1]
- Doing a GSoC for GCC and writing up about fixes for vector and
other data structures that can be helpful [2] (a lot of these
optimizations were rolled into libstdc++'s normal vector by
François Dumont, thank you!!)
- Implementing part of my own proposal's [[nodiscard("should have a
reason")]] [3]
- Macros for identifying literal and wide literal encoding, to aid in
code portability and pre-emptively solving a user concern while
preparing for a new C++ proposal that allows identifying the execution
and wide execution character sets deployed by the compiler [4]
I'm also helping to solve the intmax_t problems in C and C++ so
we can have wider integer types beyond "long long" blessed by
numeric_limits.[5]
I am also, recently, the ISO/IEC JTC1 SC22 WG14 - Programming
Languages, C: Project Editor. I do not speak for ISO/IEC, the C
Committee, or my National Body here; this e-mail is sent in a person
capacity, but my affiliations should be known (not that they are
hidden with a cursory search, either).
Asides from many other things, last and most importantly I am a
GCC advocate, a libstdc++ contributor, and an individual who spent an
exorbitant and extraordinary amount of my free time contributing to
these projects and the wider ecosystems in the hope that C, C++, Rust,
and related Systems Programming languages would continue to flourish
under the leadership done by the people here. By the time I was going
to finish my education, the goal was to ramp up these contributions
10-fold. There is much room for improvements in fundamental C and C++
architecture and library, leading me on a long, long journey, to where
I am today.
I am exactly one of the "future contributors" referenced in the
e-mails by Wakely, Rodgers, Wielaard, Poyarekar, and others here, even
if they were not explicitly thinking of me. Or, I would be:
On Sun, Mar 28, 2021 Mark Wielaard wrote:
>
> ...
>
> I witnessed something similar recently when we had setup the
> mailinglist to discuss improving governance of the GNU project. When a
> female GNU (GCC) volunteer spoke up she got attacked and harassed. We
> told the harassers that was totally unacceptable and blocked them from
> sending more emails to the list. RMS arranged for those people to get
> unblocked to continue their hate campaign on the public GNU list so
> they could "defend him and the GNU project". That was followed by a
> torrent of hate to the list making any discussion impossible and
> making women feel like they were specifically targeted. He still
> hasn't learned that his words and actions are dog whistles for
> misogynists, transphobics and racists. This really has to stop.
>
> ...
This is unacceptable. The only reason I was told - as early as
yesterday, by Free Software advocates, to my socially distanced face -
that Stallman was still here is because he was powerless and had no
effect on the project. That it was run by the caring,
community-oriented stewardship of the "real volunteers" doing the
"actual work".
That is not what this e-mail reveals.
Further digging into Stallman's own words and behavior also
reveals that he continues to flex this influence throughout the
project (and in other places), showing up (generally unsolicited) into
places to do this kind of gross and extreme harassment and engaging in
canceling our own hardworking contributors that actually write code
and do work. This is not a person who is just here for "historical
reasons" and who has "no power"; this is an active, perpetual threat
to hardworking and contributing members of the Free Software movement.
I refuse to spend my free time supporting a single bigot and an
entire globe's worth of toxic enthusiasts who actively support his
behavior while letting people like him create horrible ecosystems for
other developers. At the start of this conversation, I was much like
Nathan; I wanted an explanation. Having reviewed the facts of the
situation, I can now unequivocally say that an explanation is not even
close to enough.
I will never, ever contribute another line of code, another
proposal implementation[6], another optimization, or another
new/better library implementation to GCC and all of its affiliated
projects, including the compilers, glibc, libstdc++, the potential
upcoming Rust implementation, and more until this problem is not
"address", but *fixed*. If you never fix it, I will never return.
Wish you and your community all the best in sorting this out,
JeanHeyd Meneide
[#]: References -
https://gist.github.com/ThePhD/bcfad83f01e6a641c3fda5cfc013a72d
Re: Remove RMS from the GCC Steering Committee
Hello, Siddhesh, Thanks for clarifying your understanding of Nathan's goal. I may indeed have misread and mistaken Nathan's goal and means. I thought the goal was to improve the GCC community by addressing the gender imbalance, and that the means (misguided, IMHO) was to distance ourselves from RMS. Your assertiveness came across to me as a correction of my mistake, but I didn't see any reason to prefer your understanding over mine, until Nathan posted today's followup. Now it looks like you were right, but I still find that a little hard to believe. Are you really sure about your understanding? Do you know for a fact that Nathan agrees with your understanding? Do you know with certainty of anyone else who shares that understanding with you and him? -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
Re: Remove RMS from the GCC Steering Committee
Setting aside whether or not RMS should be associated with the GCC project for a bit, I'm particularly concerned about the tone of some of the messages on this thread. People can and will have differences, and that is fine. But the discussion needs to stay civil. To those who have crossed the line (no, I'm not going to call them out by name) -- please tone things done. We have a long history here of not banning individuals from posting and I don't want to see this discussion escalate to the point where we're forced to take what I would consider drastic measures. To those on the receiving end, I'm terribly sorry that some people can't disagree in a civil manner and I hope their behavior does not discourage you from continuing to contribute to GCC. Jeff
Re: Remove RMS from the GCC Steering Committee
On Mar 28, 2021, Alexandre Oliva wrote: > Nathan posted today's followup. Erhm... Nathan, please accept my apologies. I misread someone else's message under the false impression it had come from you. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
Re: Remove RMS from the GCC Steering Committee
On 3/27/2021 2:49 PM, Martin Liška wrote: On 3/26/21 9:02 PM, Nathan Sidwell wrote: Dear members of the GCC Steering Committee (SC), I ask you to remove Richard Stallman (RMS) I do fully support Nathan's request. Speaking strictly for myself, not as a representative of the steering committee or Tachyum, I also fully support Nathan's request. jeff
Re: Remove RMS from the GCC Steering Committee
The methods used to put a leash on Torvalds and Assange and the methods used to put one on Stallman are too similar to ignore. It hasn’t stopped there either, it is now being wielded as a way to yoke all developers of mainstream software (whether mainstream and non-free, or mainstream and under a free license) into indentured servants of projects that have been taken over by corporate donors who then force even original authors to do things the way the monopoly wanted, or get out. - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Monday, March 29, 2021 at 12:47 AM > From: "Mark Wielaard" > To: "GCC Development" > Cc: "Nathan Sidwell" > Subject: Re: Remove RMS from the GCC Steering Committee > > Alexandre, > > Making our community more welcoming is indeed a process. And some > steps will just be symbolic. But I don't believe removing RMS from > (perceived) leadership positions in the GNU project and from the FSF > is just symbolic. And even for a symbolic step it is a powerful > one. It shows we don't tolerate harassment in our project. And I do > hope it doesn't end with that step. We also have to decide whether we > still want to be associated with the FSF. Hopefully the FSF takes > their responsibility and replaces the whole board to show we can start > with a clean slate. > > One issue is that as long as GCC is associated with RMS and the FSF > others who could help us won't because the FSF is that toxic now: > https://www.outreachy.org/blog/2021-03-23/fsf-participation-barred/ > And they are far from the only Free Software project who has said > something similar. > > We are not talking about some single recent incident, but about > decades of problematic behavior. At the last face-to-face GNU Tools > Cauldron, everybody I talked to about it had some story about being > harassed by RMS, had witnessed such harassment or heard from or knew > someone who had been. > > For years people have tried to help him see how his actions and words > might hurt others, even if they are completely logically correct to > himself. And obviously that is sometimes hard, nobody is perfect, but > hopefully we get a little better every time. But this never happened. > And it really needs to stop. > > RMS actively undermines those who try to make our community a little > bit more welcoming. Violating anti-harassment policies of > conferences. Even those from the FSF by claiming to be above those > policies because of his leadership position or using his position to > tell staff they cannot enforce such policies against others. Because > he is against enforcing any anti-harassment policy some GNU > mailinglist is currently being used to organize a doxing campaign > (publishing photos, address and calls to report to the local police > station to get her house raided and arrested) for simply saying the > same things we are discussing here now. > > I witnessed something similar recently when we had setup the > mailinglist to discuss improving governance of the GNU project. When a > female GNU (GCC) volunteer spoke up she got attacked and harassed. We > told the harassers that was totally unacceptable and blocked them from > sending more emails to the list. RMS arranged for those people to get > unblocked to continue their hate campaign on the public GNU list so > they could "defend him and the GNU project". That was followed by a > torrent of hate to the list making any discussion impossible and > making women feel like they were specifically targeted. He still > hasn't learned that his words and actions are dog whistles for > misogynists, transphobics and racists. This really has to stop. > > You link to a parody of a request of tens of Free Software foundation > projects and thousands of Free Software hackers who are calling for > the removal of the entire Board of the Free Software Foundation and > for Richard M. Stallman to be removed from all leadership positions, > including the GNU Project. For similar reasons that people here are > now calling for RMS to be removed from the GCC steering committee. > > The real letter is here: https://rms-open-letter.github.io/ > > Sometimes satire is a way to deal with difficult problems, but I don't > think that is appropriate here and I hope people take these issues > seriously, because I think they are. > > Mark >
Re: Remove RMS from the GCC Steering Committee
Hi, On Sun, Mar 28, 2021 at 10:33:15AM -0400, JeanHeyd Meneide wrote: > This is unacceptable. The only reason I was told - as early as > yesterday, by Free Software advocates, to my socially distanced face - > that Stallman was still here is because he was powerless and had no > effect on the project. That it was run by the caring, > community-oriented stewardship of the "real volunteers" doing the > "actual work". I do not think those people were lying or trying to deceive you. This is what we hope the actual situation is. But... > Further digging into Stallman's own words and behavior also > reveals that he continues to flex this influence throughout the > project (and in other places), showing up (generally unsolicited) into > places to do this kind of gross and extreme harassment and engaging in > canceling our own hardworking contributors that actually write code > and do work. This is not a person who is just here for "historical > reasons" and who has "no power"; this is an active, perpetual threat > to hardworking and contributing members of the Free Software movement. He does indeed show up randomly claiming authority even if the GNU community has told him no. And it is important to say upfront he has no authority and that his attempts to cancel the work of hardworking GNU contributors is unwelcome. IMHO for the GCC community this means to be explicit he doesn't have any authority and he shouldn't be on the GCC steering committee. > I will never, ever contribute another line of code, another > proposal implementation[6], another optimization, or another > new/better library implementation to GCC and all of its affiliated > projects, including the compilers, glibc, libstdc++, the potential > upcoming Rust implementation, and more until this problem is not > "address", but *fixed*. If you never fix it, I will never return. > > Wish you and your community all the best in sorting this out, Thanks. I do hope we can finally fix this and welcome you back. Cheers, Mark
Re: Remove RMS from the GCC Steering Committee
On Mar 28, 2021, Mark Wielaard wrote: > It shows we don't tolerate harassment in our project. It shows we will favor and engage in harassment against a certain demographic group, while pretending or believing it will somehow make for a welcoming atmosphere. > everybody I talked to about it had some story about being > harassed by RMS, had witnessed such harassment or heard from or knew > someone who had been. ... which, even if true, still requires quite a lot of twisting and forcing and breaking to make it fit the sexism narrative presented as the motivating factor. And this is the problem with most of the witchhunting in place. There are plenty of allegations circulating all over the Internet, and most of them fit either or both of two patterns: actual evidence twisted and forced to fit a false narrative, or repeated hearsay, most likely fabricated or exaggerated, without a traceable ultimate source. Which is not to say that there aren't exceptions, the first-hand narratives. Those invariably fit in either of two patterns: they look like smoking gun evidence of very wrongdoing, but they are disputed by other who were just as much there and are just as trustworthy, or they paint the known picture of person who has well-known flaws and is indeed frequently difficult to deal with, but those facts don't help construct the false boogeyman narrative. Of course conclusions may be different once one starts picking evidence that is favorable to make one's case, and disregarding that which opposes evidence. Most people would agree that this is not the way to go to find truth, be it for science or for justice. > he is against enforcing any anti-harassment policy some GNU > mailinglist is currently being used to organize a doxing campaign Doxing and harassment are not welcome, and that post has already been solved, with his support and before you brought it up, FWIW. Harassment has been tolerated before, which made this decision a little more difficult, because the target of an earlier and ongoing harassment campaign was someone in a position of power in the GNU project itself. My understanding is that there was a decision to not silence that discussion, although some moderators had engaged in suppression of dissenting positions to the (still) ongoing harassment. As anyone who studied history can predict, authoritarian positions tend to suppress or attempt to suppress dissent, while freedom-respecting ones endure it. If that was a trial run of the sort of leadership that was trying to replace Richard's, I'd much rather keep the devil we know. That alleged witch may have some warts indeed, but they're not quite as ugly as the prosecutors/judges/executioners's. > You link to a parody of a request of tens of Free Software foundation > projects and thousands of Free Software hackers If truth finding were a matter of headcount, we might still be forced to believe we're on a flat planet orbited by a star. But if we're to use that measuring stick, petitions calling for the FSF to keep Richard at the FSF board have been signed by more people, translated to more languages, despite there being more of them, and hosted on platforms that are less hostile to software freedom, and not being signed multiple times by the same few people on behalf of multiple organizations. > Sometimes satire is a way to deal with difficult problems, but I don't > think that is appropriate here How about this one instead? https://avilarenata.medium.com/stallman-d824724b0083 RMS’ principled stances cause an uncomfortable cognitive dissonance for them. They would rather kill a sacrificial Gnu than admit their own shortcomings. It is significant that the letter demanding his resignation must be signed using Microsoft’s Github platform, and that many organizations taking position are openly accepting money from Google and other predatory companies. Or this one? https://www.wetheweb.org/post/cancel-we-the-web The paradox of Stallman is that while his pointedness and stubbornness leads many to dismiss him as a jerk, his stubbornness and confrontations are actually rooted in his life-long obsession with morality. Though you may disagree, there is ample reason to believe he has come to hold his views from a concerted, rigorous, good-faith effort to be a voice for good in the world. “Stallman… is a hard man to like. He is driven, often impatient. His anger can flare at friend as easily as foe. He is uncompromising and persistent; patient in both.” Lawrence Lessig, Harvard Law Professor, democracy activist “Even if I strongly disagree with a position or an idea, an expression of an idea, advocacy of an idea, and even if the vast majority of the public disagrees with the idea and finds it offensive, that is not a justification for suppressing the idea. And it’s not a justification for taking away the equal rights of the person who espouses that idea including the right to continue hold
Re: Remove RMS from the GCC Steering Committee
- Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Monday, March 29, 2021 at 6:13 AM > From: "Mark Wielaard" > To: "JeanHeyd Meneide" > Cc: "GCC Development" , "Nathan Sidwell" > Subject: Re: Remove RMS from the GCC Steering Committee > > Hi, > > On Sun, Mar 28, 2021 at 10:33:15AM -0400, JeanHeyd Meneide wrote: > > This is unacceptable. The only reason I was told - as early as > > yesterday, by Free Software advocates, to my socially distanced face - > > that Stallman was still here is because he was powerless and had no > > effect on the project. That it was run by the caring, > > community-oriented stewardship of the "real volunteers" doing the > > "actual work". > > I do not think those people were lying or trying to deceive you. This > is what we hope the actual situation is. But... > > > Further digging into Stallman's own words and behavior also > > reveals that he continues to flex this influence throughout the > > project (and in other places), showing up (generally unsolicited) into > > places to do this kind of gross and extreme harassment and engaging in > > canceling our own hardworking contributors that actually write code > > and do work. This is not a person who is just here for "historical > > reasons" and who has "no power"; this is an active, perpetual threat > > to hardworking and contributing members of the Free Software movement. > > He does indeed show up randomly claiming authority even if the GNU > community has told him no. And it is important to say upfront he has > no authority and that his attempts to cancel the work of hardworking > GNU contributors is unwelcome. IMHO for the GCC community this means > to be explicit he doesn't have any authority and he shouldn't be on > the GCC steering committee. > > > I will never, ever contribute another line of code, another > > proposal implementation[6], another optimization, or another > > new/better library implementation to GCC and all of its affiliated > > projects, including the compilers, glibc, libstdc++, the potential > > upcoming Rust implementation, and more until this problem is not > > "address", but *fixed*. If you never fix it, I will never return. > > > > Wish you and your community all the best in sorting this out, > > Thanks. I do hope we can finally fix this and welcome you back. The attacks against Richard Stallman do not stem from any of his actual statements. Instead, his statements have been given a subversive context that fits into your narrative that wishes to smear him, followed a demand that your interpretation of his words be considered canon — even though evidence to the contrary summarily disproves your position. Stallman’s work and advocacy speaks for itself; and this holds true for anyone in the field of technology, where a person’s work is judged by a system of meritocracy. Linus Torvalds was also famously criticized by those who took offense to his no-nonsense attitude and firm speech. Did the quality of the Linux kernel suffer? Was being unoffensive a requirement as maintainer? The answer is NO. Stallman has never been accused of doing physical harm to anyone, and therefore any assumptions about the harmful nature or context of his words should not be conflated with his professional capacity to hold a leadership role within the FSF, the very organization that he founded. > Cheers, > > Mark >
Re: Remove RMS from the GCC Steering Committee
On 3/28/21 8:20 PM, Alexandre Oliva wrote: Thanks for clarifying your understanding of Nathan's goal. I may indeed have misread and mistaken Nathan's goal and means. I thought the goal was to improve the GCC community by addressing the gender imbalance, and that the means (misguided, IMHO) was to distance ourselves from RMS. There's only one point of departure; you chose to interpret RMS' removal from the steering committee to be the solution while I (and others) have pointed out that it is a notable step in that direction. Your assertiveness came across to me as a correction of my mistake, but I didn't see any reason to prefer your understanding over mine, until Nathan posted today's followup. My reading of every gcc contributor that has participated in this discussion seems to reinforce my understanding over yours. Not one of them has conveyed IMO that RMS' removal from the board will magically solve gender or diversity issues with the community. Now it looks like you were right, but I still find that a little hard to believe. Are you really sure about your understanding? Do you know for a fact that Nathan agrees with your understanding? Do you know with certainty of anyone else who shares that understanding with you and him? In my opinion there is nothing to indicate from any of the contributors' statements that they see RMS' removal from the steering committee as a final solution to D&I issues in the GNU community. I'm happy to be corrected by others if they think I've misinterpreted their comments and if they indeed think that RMS' removal from the steering committee will solve all diversity issues. Siddhesh
Re: Remove RMS from the GCC Steering Committee
You showed your colours with your first few posts, don't try to pretend you are anything but a zealot and a nasty troll. Come back when you've contributed more to the GNU project than attacking those you see as its enemies. The people you are attacking have done more for Free Software than you ever will. On Sun, 28 Mar 2021, 19:43 Christopher Dimech via Gcc, wrote: > > > - > Christopher Dimech > General Administrator - Naiad Informatics - GNU Project (Geocomputation) > - Geophysical Simulation > - Geological Subsurface Mapping > - Disaster Preparedness and Mitigation > - Natural Resource Exploration and Production > - Free Software Advocacy > > > > Sent: Monday, March 29, 2021 at 6:13 AM > > From: "Mark Wielaard" > > To: "JeanHeyd Meneide" > > Cc: "GCC Development" , "Nathan Sidwell" < > nat...@acm.org> > > Subject: Re: Remove RMS from the GCC Steering Committee > > > > Hi, > > > > On Sun, Mar 28, 2021 at 10:33:15AM -0400, JeanHeyd Meneide wrote: > > > This is unacceptable. The only reason I was told - as early as > > > yesterday, by Free Software advocates, to my socially distanced face - > > > that Stallman was still here is because he was powerless and had no > > > effect on the project. That it was run by the caring, > > > community-oriented stewardship of the "real volunteers" doing the > > > "actual work". > > > > I do not think those people were lying or trying to deceive you. This > > is what we hope the actual situation is. But... > > > > > Further digging into Stallman's own words and behavior also > > > reveals that he continues to flex this influence throughout the > > > project (and in other places), showing up (generally unsolicited) into > > > places to do this kind of gross and extreme harassment and engaging in > > > canceling our own hardworking contributors that actually write code > > > and do work. This is not a person who is just here for "historical > > > reasons" and who has "no power"; this is an active, perpetual threat > > > to hardworking and contributing members of the Free Software movement. > > > > He does indeed show up randomly claiming authority even if the GNU > > community has told him no. And it is important to say upfront he has > > no authority and that his attempts to cancel the work of hardworking > > GNU contributors is unwelcome. IMHO for the GCC community this means > > to be explicit he doesn't have any authority and he shouldn't be on > > the GCC steering committee. > > > > > I will never, ever contribute another line of code, another > > > proposal implementation[6], another optimization, or another > > > new/better library implementation to GCC and all of its affiliated > > > projects, including the compilers, glibc, libstdc++, the potential > > > upcoming Rust implementation, and more until this problem is not > > > "address", but *fixed*. If you never fix it, I will never return. > > > > > > Wish you and your community all the best in sorting this out, > > > > Thanks. I do hope we can finally fix this and welcome you back. > > The attacks against Richard Stallman do not stem from any of his actual > statements. Instead, his statements have been given a subversive context > that fits into your narrative that wishes to smear him, followed a demand > that your interpretation of his words be considered canon — even though > evidence to the contrary summarily disproves your position. > > Stallman’s work and advocacy speaks for itself; and this holds true for > anyone > in the field of technology, where a person’s work is judged by a system of > meritocracy. > > Linus Torvalds was also famously criticized by those who took offense to > his > no-nonsense attitude and firm speech. Did the quality of the Linux kernel > suffer? Was being unoffensive a requirement as maintainer? The answer is > NO. > > Stallman has never been accused of doing physical harm to anyone, and > therefore > any assumptions about the harmful nature or context of his words should > not be > conflated with his professional capacity to hold a leadership role within > the FSF, > the very organization that he founded. > > > > > Cheers, > > > > Mark > > >
gcc-11-20210328 is now available
Snapshot gcc-11-20210328 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20210328/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 499fa254ae8c9752d8c2cf3130b13ffddfd83546 You'll find: gcc-11-20210328.tar.xz Complete GCC SHA256=ec27f7e5f259ad693996fe54742621b89e5abf82e4f97b5eb35c3bff2b163537 SHA1=518f798a97dbfc03d4a32146c85a0cf211f1c525 Diffs from 11-20210321 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Remove RMS from the GCC Steering Committee
We are not talking about some single recent incident, but about decades of problematic behavior. At the last face-to-face GNU Tools Cauldron, everybody I talked to about it had some story about being harassed by RMS, had witnessed such harassment or heard from or knew someone who had been. I think I will leave this discussion up to those who have more familiarity with the guy than I do. There's no doubt that some of the stuff Stallman has written creeps me the hell out, and I think it was more the tone of the OP I objected to. Giving twitter as reference points doesn't really help matters, but it appears as though the problems are more offline than on.
Re: Remove RMS from the GCC Steering Committee
This is quite similar to James Madison and John Jay, two of the founding father of the United States Bill of Rights, which enshrined guarantees of personal freedoms and rights within the American Constitution. Many companies rely on their founder to be the chief salesperson. This is difficult as the company grows, but the founder is uniquely suited to convince others about free software in this case. Certainly not Nathan Sidwell, Deb Nicholson, or Neil McGovern. Or the others. If people think that the Jeffrey Epstein problems are going to be resolved by going after Stallman, they are highly misguided. Money and power often buy what they shouldn't. > Sent: Monday, March 29, 2021 at 11:21 AM > From: "Soul Studios" > To: "Mark Wielaard" , "GCC Development" > Cc: "Nathan Sidwell" > Subject: Re: Remove RMS from the GCC Steering Committee > > > We are not talking about some single recent incident, but about > > decades of problematic behavior. At the last face-to-face GNU Tools > > Cauldron, everybody I talked to about it had some story about being > > harassed by RMS, had witnessed such harassment or heard from or knew > > someone who had been. > > I think I will leave this discussion up to those who have more > familiarity with the guy than I do. Have worked with Stallman and never experienced any stories that are being perpetuated in discussions. > There's no doubt that some of the > stuff Stallman has written creeps me the hell out, and I think it was > more the tone of the OP I objected to. Yes, there are things that people can disagree with him about personal views. Which crimes has he committed exactly? And under which jurisdiction? I have to work with a lot of people that I could not particularly like on a personal level. I cannot see how people expect that others stay out of politics because they have some acrimony against them! > Giving twitter as reference points doesn't really help matters, but it > appears as though the problems are more offline than on. >
