Re: [RFC] avoid type conversion through versioning loop
On 2021-03-25 16:35, Richard Biener wrote: On Wed, 24 Mar 2021, guojiufu wrote: On 2021-03-24 20:33, Richard Biener wrote: > On Wed, 24 Mar 2021, guojiufu wrote: > >> On 2021-03-24 15:55, Richard Biener wrote: >> > On Wed, Mar 24, 2021 at 3:55 AM guojiufu wrote: >> >> >> >> On 2021-03-23 16:25, Richard Biener via Gcc wrote: >> >> > On Tue, Mar 23, 2021 at 4:33 AM guojiufu >> >> > wrote: >> >> >> >> >> >> On 2021-03-22 16:31, Jakub Jelinek via Gcc wrote: >> >> >> > On Mon, Mar 22, 2021 at 09:22:26AM +0100, Richard Biener via Gcc >> >> >> > wrote: >> >> >> >> Better than doing loop versioning is to enhance SCEV (and thus >> >> >> >> also >> >> >> >> dependence analysis) to track extra conditions they need to handle >> >> >> >> cases similar as to how niter analysis computes it's 'assumptions' >> >> >> >> condition. That allows the versioning to be done when there's an >> >> >> >> actual beneficial transform (like vectorization) rather than just >> >> >> >> upfront for the eventual chance that there'll be any. Ideally >> >> >> >> such >> >> >> >> transform would then choose IVs in their transformed copy that >> >> >> >> are analyzable w/o repeating such versioning exercise for the next >> >> >> >> transform. >> >> >> > >> >> >> > And it might be beneficial to perform some type promotion/demotion >> >> >> > pass, either early during vectorization or separately before >> >> >> > vectorization >> >> >> > on a loop copy guarded with the ifns e.g. ifconv uses too. >> >> >> > Find out what type sizes the loop use, first try to demote >> >> >> > computations >> >> >> > to narrower types in the vectorized loop candidate (e.g. if >> >> >> > something >> >> >> > is computed in a wider type only to have the result demoted to >> >> >> > narrower >> >> >> > type), then pick up the widest type size still in use in the loop >> >> >> > (ok, >> >> >> > this assumes we don't mix multiple vector sizes in the loop, but >> >> >> > currently >> >> >> > our vectorizer doesn't do that) and try to promote computations >> >> >> > that >> >> >> > could >> >> >> > be promoted to that type size. We do partially something like that >> >> >> > during >> >> >> > vect patterns for bool types, but not other types I think. >> >> >> > >> >> >> > Jakub >> >> >> >> >> >> Thanks for the suggestions! >> >> >> >> >> >> Enhancing SCEV could help other optimizations and improve performance >> >> >> in >> >> >> some cases. >> >> >> While one of the direct ideas of using the '64bit type' is to >> >> >> eliminate >> >> >> conversions, >> >> >> even for some cases which are not easy to be optimized through >> >> >> ifconv/vectorization, >> >> >> for examples: >> >> >> >> >> >>unsigned int i = 0; >> >> >>while (a[i]>1e-3) >> >> >> i++; >> >> >> >> >> >>unsigned int i = 0; >> >> >>while (p1[i] == p2[i] && p1[i] != '\0') >> >> >> i++; >> >> >> >> >> >> Or only do versioning on type for this kind of loop? Any suggestions? >> >> > >> >> > But the "optimization" resulting from such versioning is hard to >> >> > determine upfront which means we'll pay quite a big code size cost >> >> > for unknown questionable gain. What's the particular optimization >> >> >> >> Right. Code size increasing is a big pain on large loops. If the gain >> >> is not significant, this optimization may not positive. >> >> >> >> > in the above cases? Note that for example for >> >> > >> >> > unsigned int i = 0; >> >> > while (a[i]>1e-3) >> >> >i++; >> >> > >> >> > you know that when 'i' wraps then the loop will not terminate. >> >> > There's >> >> >> >> Thanks :) The code would be "while (a[i]>1e-3 && i < n)", the upbound is >> >> checkable. Otherwise, the optimization to avoid zext is not adoptable. >> >> >> >> > the address computation that is i * sizeof (T) which is done in a >> >> > larger >> >> > type to avoid overflow so we have &a + zext (i) * 8 - is that the >> >> > operation >> >> > that is 'slow' for you? >> >> >> >> This is the point: "zext(i)" is the instruction that I want to >> >> eliminate, >> >> which is the direct goal of the optimization. >> >> >> >> The gain of eliminating the 'zext' is visible or not, and the code size >> >> increasing is small enough or not, this is a question and needs to >> >> trade-off. >> >> It may be only acceptable if the loop is very small, then eliminating >> >> 'zext' >> >> would help to save runtime, and code size increase maybe not big. >> > >> > OK, so I indeed think that the desire to micro-optimize a 'zext' doesn't >> > make versioning a good trade-off. The micro-architecture should better >> > not make that totally slow (I'd expect an extra latency comparable to >> > the multiply or add on the &a + zext(i) * 8 instruction chain). >> >> Agree, I understand your point. The concern is some micro-architectures >> are >> not >> very well on this yet. I tested the above example code: >> unsigned i = 0; >> while (a[i] > 1e-3 && i < n) >> i++; >> there are ~30% performance
Question about reading LTO function summaries
Hello,
I already have some experience developing SIMPLE_IPA_PASSes, but I am
looking to understand IPA_PASSes better. I have made a hello world ipa
pass that stores "hello world $FUNCTION_NAME" in the function
summaries; however, I am having trouble reading this information back.
Can someone help me understand how to use these interfaces correctly?
At the moment, it **seems** to be writing information correctly.
(I.e., it doesn't segfault when attempting to write data.) However, in
my read summary function (ipa_hello_world_read_summary (void)) the
function `lto_get_summary_section_data (file_data,
LTO_section_ipa_hello_world, &len);` always returns NULL and
`file_data_vec` is of size 1. This means that at run time, there is
only one call to `lto_get_summary_section_data` and it returns NULL.
I am copy-pasting the relevant code below.
/* Map from cgraph_node* to "hello world $FUNCTION_NAME". */
static hash_map *hello_summaries;
static void
ipa_hello_world_write_summary (void)
{
gcc_assert(hello_summaries);
struct output_block *ob = create_output_block (LTO_section_ipa_hello_world);
gcc_assert(ob);
if (dump_file) fprintf(dump_file, "hello world from write summary\n");
lto_symtab_encoder_t encoder = ob->decl_state->symtab_node_encoder;
if (dump_file) fprintf(dump_file, "writing %d\n",
hello_summaries->elements());
streamer_write_uhwi (ob, hello_summaries->elements());
for (auto i = hello_summaries->begin(), e = hello_summaries->end();
i != e; ++i)
{
if (dump_file) fprintf(dump_file, "writing %s\n", (*i).second);
streamer_write_uhwi(ob, lto_symtab_encoder_encode(encoder, (*i).first));
streamer_write_string (ob, ob->main_stream, (*i).second, true);
}
produce_asm (ob, NULL);
destroy_output_block (ob);
delete hello_summaries;
}
static void
ipa_hello_world_read_summary (void)
{
struct lto_file_decl_data **file_data_vec = lto_get_file_decl_data ();
struct lto_file_decl_data *file_data;
unsigned int j = 0;
if (dump_file) fprintf(dump_file, "hello from read summary\n");
while ((file_data = file_data_vec[j++]))
{
if (dump_file) fprintf(dump_file, "iteration = %d\n", j);
size_t len;
const char *data =
lto_get_summary_section_data (file_data,
LTO_section_ipa_hello_world, &len);
if (!data) continue;
const struct lto_function_header *header = (const struct
lto_function_header*) data;
gcc_assert(header);
gcc_assert(header->cfg_size);
const int cfg_offset = sizeof (struct lto_function_header);
const int main_offset = cfg_offset + header->cfg_size;
const int string_offset = main_offset + header->main_size;
class data_in *data_in;
lto_input_block ib ((const char *) data + main_offset, header->main_size,
file_data->mode_table);
data_in
= lto_data_in_create (file_data, (const char *) data + string_offset,
header->string_size, vNULL);
unsigned int n = streamer_read_uhwi (&ib);
//hello_summaries = new hash_map;
for (unsigned i = 0; i < n; i++)
{
unsigned int index = streamer_read_uhwi(&ib);
lto_symtab_encoder_t encoder = file_data->symtab_node_encoder;
struct cgraph_node *cnode = dyn_cast
(lto_symtab_encoder_deref(encoder, index));
gcc_assert(cnode);
const char* string = streamer_read_string (data_in, &ib);
if (dump_file) fprintf(dump_file, string);
}
}
}
Re: Can help with task of language frontend cleanup
Hello, Im sorry for posting to wrong group. Wasnt sure. Let me try to explain more clearly. Please forgive my nonnative english. My idea is something like ideally single gcc.exe would be built deployed distributed runtests against per version per some/all frontends. We could think as of whether make frontends as shared objects or compiled statically. Id think id prefer statics for avoiding so mess. You could test all langs tests on single binary amongst other benefits. Also we wouldnt be spawning processes like crazy. Also build process would possibly get simpler less targets and so on. If we stuck with single frontend per binary wed still gain on cleaner interface to langhooks cleaner more consistent basic hooks use calling langhooks statically not through pointer (not sure hiw costly that is) possibly gaining better code locality around frontend inlining many basic hooks and enclosing them into frontend class. As an extra we could get better separation of frontend and middle part. Also adding new frontend would be cleaner process imho. In approach with multiple frontends per binary we could build one gcc and serve many langs possibly optimally building single exe for all langs. I mostly think here of easier testing across frontends. I updated tree processing and i want to check whether i didnt break any frontend on single gcc binary build. In thus approach build process would be simpler and running regressions could be done on single binary. If that still doesnt make any sense or is useless fair enough. I tried. If though multitarget approach would make any sense i could try to think about this approach but id need some help with modifying build process etc. Plus some research on building for all targets at once and so on. On this one im also thinking of avoiding text form of assembly (keeping it as option for debugging but using binary form or calls as default) and running gas internally not as an external process. If any of this makes any sense i can toy with it. Love the project and work you guys are doing. Would like to catch up with clang a bit and sync those two projects. Best regards, Pawel Kunio czw., 25.03.2021, 13:06 użytkownik Jonathan Wakely napisał: > On Thu, 25 Mar 2021 at 09:43, pawel k. via Gcc-help > wrote: > > > > Hello, > > Not sure which list is right. I have ideas for code improvement for gcc. > > Please don't cross-post to gcc@ and gcc-help@, there are almost no > topics relevant to both. You're discussing GCC development, so gcc@ is > the right place. > > > > > Idea1 langhooks cleanup > > > > It basically involves clean up of lang hooks. Closing it in special > class. > > Might help to clean up massive defines etc spurious langhooks > declarations > > amongst others and removing some hooks from hooks.h/c and langhooks.h/c. > > Also in this solution wed gain some cputime by not calling langhooks via > > func pointers. > > > > Idea 1a multiple langhooks in single binary. Choosable in runtime. > > > > Ideally will allow compiling in multiple frontends in single binary and > > choosing in runtime which lang front to use. > > What would be the benefit? > > I can understand the advantage of a single binary that is a > cross-compiler for different targets (but it would be a huge task to > get GCC there). You wouldn't need multiple complete copies of GCC > installed to do cross-compilation if there was a --target option like > Clang's. But what's the benefit to users of a single binary for > different languages? The 'gcc' driver already exists and gives that > functionality, what would change with your proposal? > > > It doesnt seem very difficult just quite laborious. If anyone is > interested > > in such improvement please authorize me to branch off. > > I'm not sure what you mean by this, but you can just create a clone of > the Git repo and host it anywhere you want. >
Dimitar Dimitrov as TI PRU maintainer
I am pleased to announce that the GCC Steering Committee has appointed Dimitar Dimitrov as maintainer of the TI PRU port in GCC. Dimitar, please update your listing in the MAINTAINERS file. Sorry it's taken so long to make this happen. It just kept slipping off my radar. Thanks, Jeff
Re: Dimitar Dimitrov as TI PRU maintainer
On петък, 26 март 2021 г. 18:29:23 EET Jeff Law wrote: > I am pleased to announce that the GCC Steering Committee has appointed > Dimitar Dimitrov as maintainer of the TI PRU port in GCC. > > > Dimitar, please update your listing in the MAINTAINERS file. Sorry it's > taken so long to make this happen. It just kept slipping off my radar. > > > Thanks, > > Jeff Thank you for the honour. I have pushed the following as c314741a539244a947b94ac045611746c0f072e0 ChangeLog: * MAINTAINERS: Add myself as pru port maintainer. --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1722f0aa8fc..0fbbc0519d0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -96,6 +96,7 @@ nvptx portTom de Vries or1k port Stafford Horne pdp11 port Paul Koning powerpcspe portAndrew Jenner +pru port Dimitar Dimitrov riscv port Kito Cheng riscv port Palmer Dabbelt riscv port Andrew Waterman @@ -372,7 +373,6 @@ Bud Davis Chris Demetriou Sameera Deshpande Wilco Dijkstra -Dimitar Dimitrov Benoit Dupont de Dinechin Jason Eckhardt Bernd Edlinger
Re: Current limitations of define_subst
Colin McEwan via Gcc writes: > Hi all, > > I was wondering if anyone understands the rationale behind the current > limitations on (define_subst), ie. working only on (define_insn) and > (define_expand). > > A lot of md cleanup, as well as extra patterns for combiner use, could be > enabled by supporting (define_split) / (define_insn_and_split) / > (define_peephole2) so I've had a very brief look at adding support for > these constructs, and from what I see there are only a few barriers > standing in the way. > > 1. attributes are used to store iterator state. This is fine for insns and > expands,, but splits and peephole2- do not have attributes. Some alternate > storage could be used, or attributes could added for splits and peephole2s. > > 2. splits and peephole2s will have two RTL patterns which the transform > might be intended to apply to. Adding an attribute to (define_subst) to > flag whether it applies to 'old', 'new' or both RTL patterns in the > definition seems a reasonable change to support this. > > Does anyone have any insight into anything else that would stop this from > working? Thanks for looking at this. Extending define_subst to support other constructs sounds useful. Normally the define_subst is triggered by the use of special string attributes, but define_splits don't have the names or (like you say) attributes in which these special attribute would typically be used. Is the idea to apply the define_subst to all define_splits whose patterns match? Or would there be some other trigger for using the define_subst? Apart from that, I don't think there's any fundamental reason why define_subst hasn't been made to work with other constructs. Thanks, Richard
Remove RMS from the GCC Steering Committee
[double sigh, attaching a pdf causes it to be blocked, and I guess the number of URLs is also triggering a spam trap for the follow up. I have removed many of the URLS from this, you'll have to use your google-fu for sources. I emailed several members of the SC, and don't want to bomb them with yet a third copy. ] Dear members of the GCC Steering Committee (SC), I ask you to remove Richard Stallman (RMS) from the SC, or, should you chose not to do so, make a clear statement as to why he remains. I am writing this publicly, as it is important we address the issue. In 2019, when RMS resigned from the FSF, I asked the SC about his status on the SC (the web site continued to list his affiliation as FSF). I never saw as response. I failed to follow up. (FWIW, I never received a response to a technical licensing issue I asked in 2020. Something seems amiss.) As this is public, even though I know you, the SC, know who I am, and I am lucky enough to count several of you as friends, I present some bona fides: • I am a long-time developer of GCC, having become involved during the EGCS days of the late 1990’s. • While there has been a time when I wasn’t as active as before or since, I have made many thousands of commits to GCC. Particularly in the C++ Front End. • You, the SC, have recognized my skills and named me as a co-maintainer of the C++ Front End. • In addition to the front end, I have implemented middle-end and backend changes and improvements. For instance the core of the OpenAcc execution model, building on the excellent OpenMP support developed by Redhat. • Outside of upstream, I have ported GCC to several architectures. Sadly several never saw the light of day, but they did pay the bills. • Historically, I reimplemented the gcov coverage system, and was a co-maintainer of that subsystem for some time. • I implemented several pieces of the Itanium C++ ABI – the nearest thing we have to a cross-platform ABI standard. • I was named a maintainer of the morpho (since removed) backend, and the nvidia backend originally authored by Bernd Schmidt (Tom de Vries has taken over that maintainance). • I’m nowhere near as prolific as other contributors, but I have been fortunate enough to work on a program that is exciting and useful to so many people. I would rather not have to write this email. Like many developers, I just want to write code. Right now we’re working towards the GCC 11 release. I thought about deferring this email. But there’s never a good time, and bad behaviour needs to be addressed in the moment. I have left this for too long already. I used to think of GCC development as egalitarian, and therefore fair, and, by assumption, welcoming. That is not true. I’m a white dude with a British accent. /Of course/ I have white male privilege. I used to joke that I fell into every job I’ve had (including my doctorate) – that, right there, is white male privilege. I have so much, that I can move to a xenophobic racist country and get a complete pass from the ‘immigrants are bad’ mentality. Many of you on the SC have such privilege – if you don’t think such privilege affects you, /then you have it/. Just letting the code speak for itself, /is not enough/. Egalitarianism would be fine in an equal world. We do not live in that world. Perhaps you discount the benefits of white male privilege. You’re wrong. Of course I cannot speak from experience, but being female in a misogynistic environment is /exhausting/. Being non-white in a racist society is /exhausting/. You may think the current pre-release crunch is tiring – but it has an end and will stop. The adverse affects of white male privilege never stop. Perhaps you do not see the need to attract a diverse population of developers. Why do you not want to evangelize to everyone the fun it is in writing compilers? /You’re writing a program that writes programs!/ /You’re writing a program that can rewrite itself to run on a different CPU!/ /How meta do you want to go!?/ You cannot have missed the sparsity of women and people of color in compiler engineering (kaporcenter black tech workforce). Maybe you fallaciously put that down to imbalances in education (leakytechpipeline) How can we, the GCC community, be expected to address that? Representation matters, we’re the problem. In the before-time, I had heard that RMS was ‘difficult’, or ‘socially awkward’. I had ignored the true toxicity he engenders. I’m sure you have too. It didn’t directly affect me. I didn’t need to interact with him. I’m not a woman. It diminishes all of us to ignore it. Let me list a few of the cases I have found. Warning, this are extremely offensive repugnant opinions. Mostly referenced via geekfeminism.wikia.org. It didn’t take me long to find them – I should have done so sooner and for that I am sorry. 1. 'skeptical that voluntarily pedophilia harms children.’
Re: Remove RMS from the GCC Steering Committee
What is this? The usual rant of freaked out madness!!! - 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: Saturday, March 27, 2021 at 8:02 AM > From: "Nathan Sidwell" > To: "GCC Development" > Subject: Remove RMS from the GCC Steering Committee > > [double sigh, attaching a pdf causes it to be blocked, and I guess the number > of > URLs is also triggering a spam trap for the follow up. I have removed many > of > the URLS from this, you'll have to use your google-fu for sources. I emailed > several members of the SC, and don't want to bomb them with yet a third copy. > ] > > Dear members of the GCC Steering Committee (SC), I ask you to remove Richard > Stallman (RMS) from the SC, or, should you chose not to do so, make a clear > statement as to why he remains. > > I am writing this publicly, as it is important we address the issue. In 2019, > when RMS resigned from the FSF, I asked the SC about his status on the SC > (the > web site continued to list his affiliation as FSF). I never saw as response. > I > failed to follow up. (FWIW, I never received a response to a technical > licensing > issue I asked in 2020. Something seems amiss.) > > As this is public, even though I know you, the SC, know who I am, and I am > lucky > enough to count several of you as friends, I present some bona fides: > • I am a long-time developer of GCC, having become involved during the > EGCS > days of the late 1990’s. > • While there has been a time when I wasn’t as active as before or > since, I > have made many thousands of commits to GCC. Particularly in the C++ Front End. > • You, the SC, have recognized my skills and named me as a co-maintainer > of > the C++ Front End. > • In addition to the front end, I have implemented middle-end and > backend > changes and improvements. For instance the core of the OpenAcc execution > model, > building on the excellent OpenMP support developed by Redhat. > • Outside of upstream, I have ported GCC to several architectures. > Sadly > several never saw the light of day, but they did pay the bills. > • Historically, I reimplemented the gcov coverage system, and was a > co-maintainer of that subsystem for some time. > • I implemented several pieces of the Itanium C++ ABI – the nearest > thing > we have to a cross-platform ABI standard. > • I was named a maintainer of the morpho (since removed) backend, and > the > nvidia backend originally authored by Bernd Schmidt (Tom de Vries has taken > over > that maintainance). > • I’m nowhere near as prolific as other contributors, but I have been > fortunate enough to work on a program that is exciting and useful to so many > people. > > I would rather not have to write this email. Like many developers, I just > want > to write code. Right now we’re working towards the GCC 11 release. I thought > about deferring this email. But there’s never a good time, and bad behaviour > needs to be addressed in the moment. I have left this for too long already. > > I used to think of GCC development as egalitarian, and therefore fair, and, > by > assumption, welcoming. That is not true. I’m a white dude with a British > accent. > /Of course/ I have white male privilege. I used to joke that I fell into > every > job I’ve had (including my doctorate) – that, right there, is white male > privilege. I have so much, that I can move to a xenophobic racist country > and > get a complete pass from the ‘immigrants are bad’ mentality. Many of you on > the > SC have such privilege – if you don’t think such privilege affects you, /then > you have it/. > > Just letting the code speak for itself, /is not enough/. Egalitarianism would > be > fine in an equal world. We do not live in that world. > > Perhaps you discount the benefits of white male privilege. You’re wrong. Of > course I cannot speak from experience, but being female in a misogynistic > environment is /exhausting/. Being non-white in a racist society is > /exhausting/. You may think the current pre-release crunch is tiring – but > it > has an end and will stop. The adverse affects of white male privilege never > stop. > > Perhaps you do not see the need to attract a diverse population of > developers. > Why do you not want to evangelize to everyone the fun it is in writing > compilers? /You’re writing a program that writes programs!/ /You’re writing > a > program that can rewrite itself to run on a different CPU!/ /How meta do you > want to go!?/ > > You cannot have missed the sparsity of women and people of color in compiler > engineering (kaporcenter black tech workforce). Maybe you fallaciously put > that > down to imbalances in educa
Re: Remove RMS from the GCC Steering Committee
On Fri, 26 Mar 2021, 20:03 Nathan Sidwell, wrote: > > Dear members of the GCC Steering Committee (SC), I ask you to remove > Richard > Stallman (RMS) from the SC, or, should you chose not to do so, make a > clear > statement as to why he remains. > I second Nathan's request, and agree with everything he said. It's important for GCC today, and for potential future contributors.
Re: Remove RMS from the GCC Steering Committee
On Fri, Mar 26, 2021 at 04:02:30PM -0400, Nathan Sidwell wrote: > [double sigh, attaching a pdf causes it to be blocked, and I guess the > number of URLs is also triggering a spam trap for the follow up. I have > removed many of the URLS from this, you'll have to use your google-fu for > sources. I emailed several members of the SC, and don't want to bomb them > with yet a third copy. ] > > Dear members of the GCC Steering Committee (SC), I ask you to remove > Richard Stallman (RMS) from the SC, or, should you chose not to do so, make > a clear statement as to why he remains. [...] > I am writing this publicly, as it is important we address the issue. In > 2019, when RMS resigned from the FSF, I asked the SC about his status on the > SC (the web site continued to list his affiliation as FSF). I never saw as > response. I failed to follow up. (FWIW, I never received a response to a > technical licensing issue I asked in 2020. Something seems amiss.) > In the alternative, I want you to make a definitive statement about why you > choose not to make such a change. Do not hide behind silence. Silence is > agreeing with the status quo. Further, if you choose not to make a change, > do not hide behind a technicality. (My understanding is that RMS has veto > power.) The rules of the SC are not immutable laws of the universe, nor does > humanity have immutable laws cast in stone. The EGCS project showed that we > can make changes with GCC’s social organization. If we fail to do so, it > will continue to be harder and harder to attract new talent to GCC > development. I support this and believe we ought to act now. Marek
Re: Remove RMS from the GCC Steering Committee
On Fri, Mar 26, 2021 at 08:51:21PM +, Jonathan Wakely via Gcc wrote: > On Fri, 26 Mar 2021, 20:03 Nathan Sidwell, wrote: > > > > Dear members of the GCC Steering Committee (SC), I ask you to > > remove Richard Stallman (RMS) from the SC, or, should you chose > > not to do so, make a clear statement as to why he remains. > > I second Nathan's request, and agree with everything he said. > > It's important for GCC today, and for potential future contributors. Thanks for starting this discussion. I agree given the recent controversy and the long history of problematic behavior it would be good for the Steering Committee to consider whether it still wants to be associated with the FSF. And whether to remove or replace RMS on the steering committee. Thanks, Mark
Re: Remove RMS from the GCC Steering Committee
On Fri, 2021-03-26 at 20:51 +, Jonathan Wakely via Gcc wrote: > On Fri, 26 Mar 2021, 20:03 Nathan Sidwell, wrote: > > > > > Dear members of the GCC Steering Committee (SC), I ask you to > > remove > > Richard > > Stallman (RMS) from the SC, or, should you chose not to do so, make > > a > > clear > > statement as to why he remains. > > > > I second Nathan's request, and agree with everything he said. To any observers seeing this email unfamiliar with the project, I wanted to note that Jonathan is currently one of the most prolific contributors to GCC, showing up as #2 on this list for commit count to GCC over the last year, with 590 commits: https://www.openhub.net/p/gcc/contributors?query=&time_span=&sort=twelve_month_commits [1] I too second Nathan's request, and agree with what he said. (Nathan shows up as #7 on that list, and Marek who has also replied whilst I've been writing this shows up as #9; I'm #11 on that list). > It's important for GCC today, and for potential future contributors. Agreed. I own an autographed copy of RMS's book from when I used to look up to him, but, frankly, I think the cause of Free Software would have been helped greatly by him taking retirement from the FSF/GNU at least a decade ago. I should note that I'm writing this in a personal capacity, not on behalf of Red Hat, though FWIW Red Hat has said the following on the matter of RMS's return to the FSF board: https://www.redhat.com/en/blog/red-hat-statement-about-richard-stallmans-return-free-software-foundation-board Now to get back to fixing bugs... Dave [1] actually the 12 month period ending 2 months ago, since that was the last time the project was rescanned by openhub
gcc-9-20210326 is now available
Snapshot gcc-9-20210326 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210326/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision fd23b0bb77d483c07bc14f86cc349f82b1b38320 You'll find: gcc-9-20210326.tar.xzComplete GCC SHA256=1de2da6b1df4874851669a9523e3f3a1bcce730bbd7fd1686a5683a4c49cc415 SHA1=70c00d23f9d64d9a38a4c56e6b668f5507380203 Diffs from 9-20210319 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Remove RMS from the GCC Steering Committee
Hello! I don't know all the details, and it surprises me nobody is asking for them. Let me be the first. On Fri, 26 Mar 2021 at 23:03, Nathan Sidwell wrote: > I’m a white dude with a British accent. > /Of course/ I have white male privilege. So, this text makes me feel sorry for the author, but at the same time makes it clear he is writing under some emotional burnout that he unambiguously shown he is experiencing. I think before making any kind of decision it would be fair to ask the author to provide references to the points he has written below. Because someone's career is at stake, so that kind of decision shouldn't be done that easily, just because someone wrote that on the internet, right? And yes, I realize that "someone" is or was a prolific developer, but so was RMS whom we are discussing here. We all do code-review to look for developer's mistakes, and I think it's useful to do the same here. So, Nathan Sidwell, could you please provide references for the problems you mentioned below? > In the before-time, I had heard that RMS was ‘difficult’, or ‘socially > awkward’. > I had ignored the true toxicity he engenders. I’m sure you have too. It > didn’t > directly affect me. I didn’t need to interact with him. I’m not a woman. It > diminishes all of us to ignore it. > Let me list a few of the cases I have found. Warning, this are extremely > offensive repugnant opinions. Mostly referenced via geekfeminism.wikia.org. > It > didn’t take me long to find them – I should have done so sooner and for that I > am sorry. > 1. 'skeptical that voluntarily pedophilia harms children.’ stallman's > own > archives 2006-mar-jun I note that children are *incapable* of consenting. > That’s what the age of consent means. > 2. 'end censorship of “child pornography”’. Stallman's archives > 2012-jul-oct.html Notice use of “quotes” to down play what is actually being > requested. > 3. 'gentle expressions of attraction’ Stallman's archives > 2012-jul-oct.html > Condoning a variant of the wolf-whistle. Unless one’s talking to one’s lover, > ‘gentle invitations for sex’ by a stranger is *grooming* (be it child or > of-age). > 4. Defends someone charged with ‘"sexual assault" on a "child" after a > session with a sex worker of age 16.’ stallman's archives 2018-jul-oct Notice > the quoting here, implying the *child* is not a child. ‘The article refers to > the sex worker as a "child", but that is not so. Elsewhere it has been > published > that she is 16 years old. That is late adolescence, not childhood.’ No, they > are > a child, that’s what the ages of majority and consent mean. > 5. The ‘St Ignatius’ ‘EMACS virgins’ non-joke. ‘The commenter writes > about > seeing the routine when she was only 15, and how RMS singled her out several > times during that performance: > He actually pointed to me in the back and proclaimed, into the mic, "A > GIRL!" causing the audience to turn and look. Mortifying. Then he proceeded to > gesture toward me every time he referred to "EMACS Virgins." (I cannot believe > that he is still doing the same talk 10+ years later.)’ > No wonder women want nothing to do with him. > 6. A business card that is completely repelling image on oreilly > 7. He knows those cards are inappropriate. He broke the code of conduct > he > helped author. wiredferret's twitter feed. > 8. I understand he’s tried to circumvent such codes of conduct by asking > women to meet him outside of the conference venue. _sagesharp_'s twitter feed. > 9. He doesn’t acknowledge the few women he has worked with ‘I don’t have > any experience working with women in programming projects; I don’t think that > any volunteered to work on Emacs or GCC.’ Completely ignoring Sandra > Loosemore, > who is a coauthor, with him, of the Glibc manual. Sandra was involved with > LISP > standardization, so I would be surprised if he was unaware of her involvement > there. As you well know, she has worked significantly on GCC, GCC has several > other women contributors, but too few for complacency. > 10. ‘My first interaction with RMS was at a hacker con at 19. He asked my > name, I gave it, whether I went to MIT (I had an MIT shirt on), and after > confirmation I did, asked me on a date. I said no. That was our entire > conversation.’ corbett's twitter feed. This is but one of many reports of > utterly inappropriate social interactions. > That list is no where near exhaustive, nor is it prioritized. As a personal > anecdote, an acquaintance of mine who was at MIT, related that she was warned > about RMS’s behaviour, and to never be alone with him. It wasn’t an isolated > warning.
Re: Remove RMS from the GCC Steering Committee
On 2021-03-26 15:53, Hi-Angel via Gcc wrote: Hello! I don't know all the details, and it surprises me nobody is asking for them. Let me be the first. A cursory reading of the top of Nathan's email states the reason for not including the URLs, but ~half of the cited points come from Stallman's own archives, which can be found at - https://stallman.org/archive.html And for the rest, Nathan clearly indicates where (for those skilled in the ways of Let Me Google That For You) to find the same information. <... snip ...> (disclaimer: I'm just a random reader of the ML) Noted.
