Re: Remove RMS from the GCC Steering Committee

[Alexandre Oliva via Gcc]

On Mar 30, 2021, JeanHeyd Meneide  wrote:

>   Taking the correction into account

*nod*

> What you've presented here is your word ("This
> accusation is outright false, beyond any possible doubt."),

True, I didn't claim to be offering evidence, and that didn't seem
necessary since all the supporting evidence you'd brought was hearsay.
I can't link to the message that is presumably removed, and I suppose I
could get permission to share the email in which he issued the request,
but please be honest: would you believe it?

> they were NOT allowed to attack people like this and go this far and
> being banned by moderation, RMS taking explicit actions to UNDO that
> moderation and explicitly, in the internal mailing list, state
> (paraphrased): 'I have put a new moderator in. Have at it.'

This description suggests we're not even talking about the same events.
My description was about a doxxing web site/email posted no more than a
week ago.

Your description appears to resemble events of 2019: the illegitimate
censorious moderation that was imposed on a GNU mailing list, against
GNU and mailing list policies, after someone abused their autonomy to
grant moderation privileges to a group that started suppressing views
they disagreed with, while allowing personal attacks they supported to
go through.  List rules were restored and censorship ceased with the
legitimate installation of a larger group of moderators with more
diverse stances, that applied list rules and blocked inappropriate posts
while allowing through civil criticism on all sides.  Richard was
criticized for insisting on enabling the debate to carry on, but he
insisted on the principled stance of free speech, and then some, to
allow for what some perceived as personal attacks against him.


Now, you appear to believe a very different interpretation of these
facts.  I can't imagine that showing public posts will prove anything,
since the difference is in the interpretation and attribution of
motivations and allegiances, rather than on facts.  As law and history
have taught us, proving innocence or honesty are often impossible tasks;
it is the burden of the accuser to offer enough evidence to sustain an
accusation, and all you've brought is hearsay.  Popular, widespread
hateful hearsay, but still hearsay.


> where someone who was already banned

No such thing happened.  That's yet another distortion.

There was an attempt to attach shocking labels to an honest man.

The labels failed to stick, though some people still believe them.

Part of the problem is the reasoning that, if so many people are
parroting the same false allegations, there must be truth to them.

When any one of them is proven wrong, with the great effort required to
overcome preconceptions, the goal post is moved onto all of the others
that appear to remain, because the preconceptions still mistake them for
granted, and the accused remains guilty for having taken multiple shots.
That's not the way civilizations have long carried out justice.

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

[JeanHeyd Meneide via Gcc]

Dear Alexandre,

As stated here, shortly after I sent my message
(https://gcc.gnu.org/pipermail/gcc/2021-March/235197.html):

> Apologies, a correction here. I should have more carefully read
> it, but this paragraph:
>
> >  My problem is Dr. Richard M. Stallman stands credibly and
> > factually accused of Doxxing and GCC contributor/participant and
> > knowingly manipulating the project for his own personal reasons.
>
> This should be "RMS explicitly sanctioned, encouraged, and
> blessed the Doxxing of an individual". Apologies, he did not do the
> doxxing himself; this was a fat finger on my part. Please take that
> into account; the rest is accurate.

  Taking the correction into account, no, the accusation is not
even close to false. What you've presented here is your word ("This
accusation is outright false, beyond any possible doubt."), with a
shortened version of what happened and no evidence, and that does not
match the quoted responses from Stallman and other people who were
present in both the public mailing list discussion and the internal
mailing list. I was given quoted evidence of, after people being told
they were NOT allowed to attack people like this and go this far and
being banned by moderation, RMS taking explicit actions to UNDO that
moderation and explicitly, in the internal mailing list, state
(paraphrased): 'I have put a new moderator in. Have at it.'

 That the same individuals (who Stallman, again, explicitly and
knowingly) unshackled were then banned for continuing to do things
that were against the Community Guidelines and grossly inappropriate
(including the Doxxing). Stallman was not born yesterday, neither were
any of the moderators or contributors involved: Stallman deliberately
overturned moderator decisions and that decision went poorly after he
explicitly signaled to people that they should Go All Out.

 If you (or anyone else) have evidence to the contrary, logs,
screenshots, etc. that counteract what I know and I have already
received, then I would LOVE to be proven wrong and have ABSOLUTELY no
problem walking back every word I said and giving Richard M. Stallman
an apology and respect as well as apologizing to the mailing list for
believing to be led astray. If you feel the exact words should not be
shared publicly, you can e-mail me or message me privately; I have
honored everyone's right to privacy, and I will continue to do so.

 I must be explicitly clear here that the current body of evidence
gives me my current conviction. There is no planet, no galaxy, no
UNIVERSE, where someone who was already banned for going **way**
beyond acceptable behavior, and then brought back with their
punishment undone with the *explicit go-ahead to go forward* and a
*new moderator for that purpose*, would not take that as a signal to
be even nastier. If you are in a Leadership position and your thought
process here was "well, things will go better the second time" after
doing those actions, then you absolutely do not deserve to be in a
Leadership position, and you absolutely should not have stewardship
over me or my contributions. Especially if this is not your first time
on a mailing list and this is not your first time being a leader.

All my best,
JeanHeyd

Re: Remove RMS from the GCC Steering Committee

[Alexandre Oliva via Gcc]

On Mar 30, 2021, JeanHeyd Meneide via Gcc  wrote:

>  My problem is Dr. Richard M. Stallman stands credibly and
> factually accused of Doxxing and GCC contributor/participant and
> knowingly manipulating the project for his own personal reasons.

This accusation is outright false, beyond any possible doubt.


A misguided person thought that reciprocating the doxxing against RMS
was a good way to defend him.  It's not.

The message went through because there is no censorship regime in effect.

RMS asked the unacceptable post to be deleted from the archives hosted
in GNU servers as soon as he learned about it.

I did not check whether that was done.  If you have any evidence that it
wasn't, please let me know.


That you got confirmation of a false claim from multiple developers you
talked to should now have you doubting other of their allegations.

If you look into them outside the attacking coalition, you *will* find
them to be built on just as flaky foundations.


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

[Andrew Sutton via Gcc]

Are you still responding to me? Your response reads like a thinly veiled
threat. Angry friends on a jihad? Sounds serious.

On Tue, Mar 30, 2021, 7:14 PM Christopher Dimech  wrote:

>
> I have some friends in this movement who have been getting rather angry
> recently.  There is a lot of anger in the world,
> in fact, in politics.  Our political movement is not the only one
> suffering from anger at the moment.  But some of my angry
> friends, have come to the conclusion that they’re on a jihad for free
> software.
>
> That way won’t work. If a campaign of coercive compliance is carried just
> a moment too far, willingness to use free
> software among rational people will decline to a point which is dangerous
> to freedom.
>
> -
> 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:* Wednesday, March 31, 2021 at 9:55 AM
> *From:* "Andrew Sutton" 
> *To:* "Christopher Dimech" 
> *Cc:* "Joseph Myers" , "GCC Development" <
> gcc@gcc.gnu.org>, "Nathan Sidwell" 
> *Subject:* Re: Remove RMS from the GCC Steering Committee
> Sorry for the confusion, but was this response directed to me? It seems
> entirely unrelated to what I wrote.
>
> On Tue, Mar 30, 2021, 5:35 PM Christopher Dimech  wrote:
>
>>
>> Seriously.  When you want something to happen within society, it is
>> complex.  Just
>> because you want to push something - an ideology - you chant about it
>> every day,
>> does not mean things will go your way.
>>
>> Perhaps you can start donating money to Antifa!
>>
>>
>>
>>
>>
>> *Sent:* Wednesday, March 31, 2021 at 9:09 AM
>> *From:* "Andrew Sutton" 
>> *To:* "Christopher Dimech" 
>> *Cc:* "Joseph Myers" , "GCC Development" <
>> gcc@gcc.gnu.org>, "Nathan Sidwell" 
>> *Subject:* Re: Remove RMS from the GCC Steering Committee
>> I guess I'll add my two cents. It seems everyone else is...
>>
>> I'm not a maintainer or frequent contributor, but I did implement
>> concepts for C++, and I'd like to continue contributing, time permitting.
>> My company (as in, I own it) also does some work on GCC, implementing new
>> and experimental features like contracts, which we intend to upstream,
>> pending review. Some modules-related stuff too (I hope).
>>
>> Maybe my response is a little different because I'm writing as a business
>> owner and not a contributor.
>>
>> 
>>
>> I understand that RMS is not actually on the steering committee and not
>> an active contributor, and the SC web page should be updated to reflect
>> that if it hasn't already.
>>
>> I agree with Nathan.
>>
>> The SC needs to be forward-looking --- you can't steer effectively if
>> you're always looking in the rear-view mirror. My understanding is that GCC
>> put RMS behind it a long time ago. And for the better.
>>
>> Part of the SC's job is (or should be) considering recruitment and
>> retention for this community, including corporate participation. This idea
>> that we have to somehow revere a person who has managed to make himself
>> controversial for reasons entirely unrelated to his ideology on free
>> software actively works against both of those goals.
>>
>> Undeniably so. If RMS were actually in the SC, I would have serious
>> reservations about committing my employees time to this community. His
>> documented behavior readily violates my company's code of conduct. At best,
>> I'd risk burn out employees in a toxic environment. At worst, I could end
>> up as a defendant in a sexual harassment case. And this 100% not hyperbole.
>>
>> (Thanks to everyone who makes GCC a good community to participate in.)
>>
>> I think it's perfectly reasonable for GCC to acknowledge RMS' past
>> contributions, both ideological and code-wise, but it's time to move on.
>> Nothing good comes from lionizing a man who purportedly asked teenage girls
>> to eat candy out of his hand.
>>
>>
>>
>> On Tue, Mar 30, 2021, 2:14 PM Christopher Dimech via Gcc 
>> wrote:
>>
>>>
>>> > Sent: Wednesday, March 31, 2021 at 5:45 AM
>>> > From: "Joseph Myers" 
>>> > To: "JeanHeyd Meneide" 
>>> > Cc: "GCC Development" , "Nathan Sidwell" <
>>> nat...@acm.org>
>>> > Subject: Re: Remove RMS from the GCC Steering Committee
>>> >
>>> > On Tue, 30 Mar 2021, JeanHeyd Meneide via Gcc wrote:
>>> >
>>> > >  So, it boils down to this for me: either GCC is a place where
>>> all
>>> > > contributions are welcome, or GCC is a place of hypocrisy, where
>>> > > contributions are welcome except when Stallman (or someone else in a
>>> > > position of power) lobbies a non-technical, non-factual argument
>>> > > against you and jumps from their high tower to slam down on
>>> > > rank-and-file contributors and participants. You cannot have it both
>>> > > ways.
>>> >
>>> > All contributions are welcome.  One of the key functions of the SC is
>>> > actually 

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

Re: Remove RMS from the GCC Steering Committee

[Joseph Myers]

On Tue, 30 Mar 2021, Giacomo Tesio wrote:

> That being said (and for full disclosure), I also consider his return to
> the FSF fair, because the shitstorm that caused his resign two years
> ago was built on top of a severe misrepresentation of his words, as
> described here https://jorgemorais.gitlab.io/justice-for-rms/ and
> admitted also by the people arguing against his return (see the
> various edits at https://rms-open-letter.github.io/appendix ).

I explicitly stated in my comments that my agreement with Nathan's 
conclusion is *not* based on the views RMS has expressed, whether on that 
occasion or on any other.

> But I'd want Stallman in GCC's SC for a totally different reason:
> 
> On Tue, 30 Mar 2021 18:50:52 +0200 Martin Jambor wrote:
> 
> > Nobody suggested that GCC would be relicensed and certainly not to a
> > non-free license.  If you decide to contribute your port upstream, it
> > will be safe with us, regardless of who will or will not be on the
> > steering committee

The GCC SC doesn't have the power to relicense GCC; that lies with the 
FSF.  We can correct clear licensing mistakes where the underlying 
licensing policy is already established (e.g. if someone forgets to put 
the runtime exception in a file in a target library) and there are certain 
cases with delegated relicensing powers (e.g. copying documentation for 
target hooks between GFDL and GPL files).  But in general relicensing 
depends on the FSF and that doesn't depend on who is on the SC.

(The original owner of code who assigned it to the FSF can also license 
copies of the code they contributed (not anyone else's changes to that 
code) under different licenses if they so wish, in accordance with the 
terms of the standard assignment agreements.  The standard assignment 
agreements also prevent the FSF from distributing the code under 
proprietary terms.)

> On Tue, 30 Mar 2021 17:45:24 + Joseph Myers wrote:
> > One of the key functions of the SC is actually saying no to RMS.
> 
> My bad experiences with Google and SFC makes me ask: "about what?"

Any time he comes up with an idea, technical or otherwise, that doesn't 
make sense (he's too far removed from actually following GCC development 
or use to be able to judge that effectively himself).  If an idea makes 
sense, of course we'll let him know that we'll consider patches.  (It's 
only likely to be in very routine cases that someone on the SC just makes 
the requested change themselves, e.g. if he points out somewhere in the 
GCC documentation saying "Linux" that should be "GNU/Linux" in accordance 
with GNU conventions.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Remove RMS from the GCC Steering Committee

[Giacomo Tesio]

Hi everybody, thanks for your feedbacks.

I've to say I'm a bit confused, but maybe we have different sources and
experience so we have different perspective on the matter.

Let's start with something I want to clarify:

On Tue, 30 Mar 2021 13:07:07 -0400 JeanHeyd Meneide wrote:

>  You state it here and many others say it throughout the thread
> that Stallman is the only reason they contribute to GCC, or similar
> Free Software projects. This deeply concerns me

I'm sorry, but apperently I was not clear.

I do NOT follow RMS as a prophet or something. He does NOT "lead" me.
We do not agree on several relevant political issues (even some
important one related to Free Software!) and I find statements like
https://stallman.org/notes/2016-jul-oct.html#31_October_2016_(Down's_syndrome)
plain disgusting.

So I'm NOT, in any way, a RMS fanboy.

That being said (and for full disclosure), I also consider his return to
the FSF fair, because the shitstorm that caused his resign two years
ago was built on top of a severe misrepresentation of his words, as
described here https://jorgemorais.gitlab.io/justice-for-rms/ and
admitted also by the people arguing against his return (see the
various edits at https://rms-open-letter.github.io/appendix ).


But I'd want Stallman in GCC's SC for a totally different reason:

On Tue, 30 Mar 2021 18:50:52 +0200 Martin Jambor wrote:

> Nobody suggested that GCC would be relicensed and certainly not to a
> non-free license.  If you decide to contribute your port upstream, it
> will be safe with us, regardless of who will or will not be on the
> steering committee

When I joined the Harvey project they were all fun and welcoming.
When I asked how and where to write my copyright statement, I was
answered by the seasoned and well known Google's engineer that a few
years later completely removed my name from the project without
removing the contributions.

Harvey is copylefted too (GPLv2) and as you know, this sort of
behaviour would trigger GPL termination, but Harvey is part of
Software Freedom Conservancy and the violation of my copyright
likely occurred during the working hours of the above engineer.

So they were the good guys and the most powerful guys, together.
I had no hope in a US court (and I'm Italian and... let say "not rich").


They taught me a valuable lesson, though.

In the long run, even the good guys betray your trust if they have a
reason to and they think they can get away with that.


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.

Unless, obviously, you have reasons that I ignore to not trust him on
his loyalty to the Free Software vision and movement. Do you have any?

For example when I read

On Tue, 30 Mar 2021 17:45:24 + Joseph Myers wrote:
> One of the key functions of the SC is actually saying no to RMS.

My bad experiences with Google and SFC makes me ask: "about what?"


So if you (all) have good reason to think that RMS could betray
Free Software, well... THAT would be a good argument to put on the
table!


But note that to many of us, GCC is not just a great compiler suite!
More importantly, it's a Free Software compiler suite.

This means that its core value, its main "selling point", is not how
cool it is, but how it is designed, developed and distributed to
maximise software freedom.

IOW, I can imagine scenarios where some features should NOT be
introduced to reach this political goal which is MORE important
than the technical goal of compiler suite

To this aim, I'd prefer to see RMS in the GCC's SC.
Because to me GCC is not just "open source", it's not just matter of
seeing the source: it's Free Software, it should be designed and
developed TO maximize software freedom!

That's a fundamental difference that still stay between Free Software
and Open Source.


On Tue, 30 Mar 2021 18:56:02 +0200 Markus Böck wrote:

> At least I would hope that most countries are in pursuit
> or see value in having an inclusive environment where no one has to
> feel treated unfairly due to either their gender, race or other
> things.

I want to clarify that I hope this too. Really. 
And in fact thousands of people of very different races and genders
worldwide expressed their support for RMS and FSF by signing
https://rms-support-letter.github.io/
Some of them are my close friends, but I will not, obviously, doxe them.

However you can find very variegate people arguing on the web for RMS
from all of genders and races. Just a few valuable examples are 
Leah Rowe https://mobile.twitter.com/n4of7/status/1374844604101591047 and
Mary Kate Fain https://mobile.twitter.com/mkay_fain/status/1374766567544737793


On Tue, 30 Mar 2021 18:56:02 +0200 Markus Böck wrote:

> I am also of the opinion that legally wrong does not equal morally
> wrong. RMS does not have to have committed a crime for the developers
> of GCC, the SC or whoever, to feel like he is not representing their
> values as a mem

Re: Looking at UNSUPPORTED dejagnu tests for a port...

[Jonathan Wakely via Gcc]

On Tue, 30 Mar 2021 at 20:23, Alan Lehotsky  wrote:
>
> I’m doing some final polishing on a gcc 8.3 upgrade and taking a look at the 
> unsupported tests.   Most of them are completely sensible (my port doesn’t 
> support trampolines, for example).  But gcc.c-torture/execute/pr78622.c is 
> marked as unsupported.  That appears to be due to the line
>
>{ dg-require-effective-target c99_runtime }
>
> I’m using newlib, and if I manually compile the test case with or without an 
> explicit —std=c99, it compiles and links without error.
> Do I need to set something in the baseboards file or in a local .exp file to 
> indicate that c99 is okay?

That effective-target is defined by this check:

# Return 1 if the target provides a full C99 runtime.

proc check_effective_target_c99_runtime { } {
return [check_cached_effective_target c99_runtime {
global srcdir

set file [open "$srcdir/gcc.dg/builtins-config.h"]
set contents [read $file]
close $file
append contents {
#ifndef HAVE_C99_RUNTIME
#error !HAVE_C99_RUNTIME
#endif
}
check_no_compiler_messages_nocache c99_runtime assembly $contents
}]
}

So it comes from the gcc/testsuite/gcc.dg/builtins-config.h header, which says:

/* Define HAVE_C99_RUNTIME if the entire C99 runtime is available on
   the target system.  The value of HAVE_C99_RUNTIME should be the
   same as the value of TARGET_C99_FUNCTIONS in the GCC machine
   description.  (Perhaps GCC should predefine a special macro
   indicating whether or not TARGET_C99_FUNCTIONS is set, but it does
   not presently do that.)  */

and then later:

/* Newlib has the "f" variants of the math functions, but not the "l"
   variants.  TARGET_C99_FUNCTIONS is only defined if all C99
   functions are present.  Therefore, on systems using newlib, tests
   of builtins will fail the "l" variants, and we should therefore not
   define HAVE_C99_RUNTIME.  Including  gives us a way of
   seeing if _NEWLIB_VERSION is defined.  Including  would work
   too, but the GLIBC math inlines cause us to generate inferior code,
   which causes the test to fail, so it is not safe.  Including 
   also fails because the include search paths are ordered such that GCC's
   version will be found before the newlib version.  Similarly, uClibc
   lacks the C99 functions.  */

Looking at UNSUPPORTED dejagnu tests for a port...

[Alan Lehotsky]

I’m doing some final polishing on a gcc 8.3 upgrade and taking a look at the 
unsupported tests.   Most of them are completely sensible (my port doesn’t 
support trampolines, for example).  But gcc.c-torture/execute/pr78622.c is 
marked as unsupported.  That appears to be due to the line

   { dg-require-effective-target c99_runtime }

I’m using newlib, and if I manually compile the test case with or without an 
explicit —std=c99, it compiles and links without error.
Do I need to set something in the baseboards file or in a local .exp file to 
indicate that c99 is okay?

Re: Remove RMS from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

I encourage everyone to please try to keep this discussion focused on GCC.

If there is a message that is completely unrelated to GCC, I encourage
not responding, or responding off-list.

Thanks.

Ian

Re: Remove RMS from the GCC Steering Committee

[Gabriel Ravier via Gcc]

On 3/30/21 7:10 PM, Christopher Dimech via Gcc wrote:

Sent: Wednesday, March 31, 2021 at 4:50 AM
From: "Martin Jambor" 
To: "Giacomo Tesio" 
Cc: "GCC Development" 
Subject: Re: Remove RMS from the GCC Steering Committee

Dear Giacomo,

On Tue, Mar 30 2021, Giacomo Tesio wrote:

Hi Nathan and hello everybody,

On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote:


The USA is not the world and the SC is not the US government.  For
those in the USA, the (inapplicable) first amendment provides 5
rights, including showing an unwelcome guest the door. [...]

If we fail to do so, it will continue to be harder and harder to
attract new talent to GCC development.

I do not know if I qualify to speak here because I'm Italian and
I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see
http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the
pandemic I wasn't able to align it with the new developments and
contribute the port upstream. Also, I have no idea if you would be
interested in running GCC on a Plan 9 fork and thus accept my
contribution.


Yet, after a careful read of this thread I realized that I might
be considered the kind of "new talent" Nathan is talking about.

So here is my perspective on this topic, "in the hope it helps but
without any warranty". :-D


I do not share many of Stallman's opinions (we are VERY different), but
when I write free software and contribute to a free software community,
what I want is long term assurances about one and only one topic: that
the software will stay free as in freedom, as a common good for the
whole humanity.

As of today, GPLv3 is the legal tool that best suit this goal.
I don't think it's perfect in this regards, but that's another story.

Nobody suggested that GCC would be relicensed and certainly not to a
non-free license.  If you decide to contribute your port upstream, it
will be safe with us, regardless of who will or will not be on the
steering committee or running the FSF.  Just read the copyright
assignment text that you have singed or would need to sign to contribute
and look for FSF obligations as the license holder there.


As an Italian I'm having a hard time trying to follow your reasoning
about Stallman being a problem to attract new talents.

I do not believe that being European or Italian has anything to do with
it. I am European, I understand and agree with everything Nathan wrote
and apparently I am not the only one.

The ability to see and stand up to consistent wrongdoing is universal
and every human of every nationality posses it.  Unfortunately, all
people are also able to close their eyes and ears and ignore mistreatment
when they are not the victims and when their friend or their favorite
public figure is the perpetrator.  There is absolutely nothing American
or European about either.

Young socialists have been getting organized on colleges campuses
with these extreme ideas not only in the United States.  France, for
instance has been harbouring a socialist model we should all dread.

France was once a role model for what big government can do for its
people. But it has become an embarrassing example since “The Gilets
Jaunes” took to the streets to demonstrate against the insane amount
of taxes they pay. These guys aren’t upper class. They are the people
who had supported the policies that are inevitable when you have the
government providing so many services and involved so deeply in so much
of the economy.

All those people in America who currently fall for the socialism soup
that that Ocasio-Cortez and Sanders are selling need to realize that if
their dream came to pass, they, not the rich – not the bankers and politicians
– will be ones suffering the most from the high taxes, high unemployment, and
slow growth that go hand in hand with the level of public spending they want.
I fail to see how this has anything to do with the message you're 
answering. Is this what the right-wingers in America are resorting to ? 
Randomly making speeches about the "socialist soup" whenever they 
encounter something they can't find a good answer to ?

Sincerely,

Martin

Re: Remove RMS from the GCC Steering Committee

[Christopher Dimech via Gcc]

> Sent: Wednesday, March 31, 2021 at 5:45 AM
> From: "Joseph Myers" 
> To: "JeanHeyd Meneide" 
> Cc: "GCC Development" , "Nathan Sidwell" 
> Subject: Re: Remove RMS from the GCC Steering Committee
>
> On Tue, 30 Mar 2021, JeanHeyd Meneide via Gcc wrote:
> 
> >  So, it boils down to this for me: either GCC is a place where all
> > contributions are welcome, or GCC is a place of hypocrisy, where
> > contributions are welcome except when Stallman (or someone else in a
> > position of power) lobbies a non-technical, non-factual argument
> > against you and jumps from their high tower to slam down on
> > rank-and-file contributors and participants. You cannot have it both
> > ways.
> 
> All contributions are welcome.  One of the key functions of the SC is 
> actually saying no to RMS.
> 
> Central FSF or GNU project infrastructure is not used in developing GCC; 
> gcc.gnu.org is entirely independent of central FSF or GNU infrastructure 
> such as savannah.  So RMS has no control over policies applied to GCC 
> mailing lists, and any influence he might apply to the moderation of lists 
> hosted on lists.gnu.org does not apply here.  (Although GCC releases are 
> uploaded to ftp.gnu.org, which is central GNU infrastructure, they are 
> also available at https://gcc.gnu.org/pub/gcc/releases/ .)  He has an 
> ordinary restricted user account on gcc.gnu.org giving the same access to 
> push commits as most committers; he does not have shell or administrative 
> access.

People are inflating the power or control he actually has.  I have to say
that at no time has Stallman dictated on any of my work.  Unlike the animosity
that has been demonstrated by Ludovic Courtès in October 2019, by sending
a message disguised to look like an official Gnu Directive to Gnu Maintainers.
A fashionable tool for excommunicating those he find problematic due to their
pesky different points of view.   
 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: Remove RMS from the GCC Steering Committee

[JeanHeyd Meneide via Gcc]

Dear Giacomo,

 Apologies, a correction here. I should have more carefully read
it, but this paragraph:

>  My problem is Dr. Richard M. Stallman stands credibly and
> factually accused of Doxxing and GCC contributor/participant and
> knowingly manipulating the project for his own personal reasons.

 This should be "RMS explicitly sanctioned, encouraged, and
blessed the Doxxing of an individual". Apologies, he did not do the
doxxing himself; this was a fat finger on my part. Please take that
into account; the rest is accurate.

Sincerely,
JeanHeyd

Re: Remove RMS from the GCC Steering Committee

[Joseph Myers]

On Tue, 30 Mar 2021, JeanHeyd Meneide via Gcc wrote:

>  So, it boils down to this for me: either GCC is a place where all
> contributions are welcome, or GCC is a place of hypocrisy, where
> contributions are welcome except when Stallman (or someone else in a
> position of power) lobbies a non-technical, non-factual argument
> against you and jumps from their high tower to slam down on
> rank-and-file contributors and participants. You cannot have it both
> ways.

All contributions are welcome.  One of the key functions of the SC is 
actually saying no to RMS.

Central FSF or GNU project infrastructure is not used in developing GCC; 
gcc.gnu.org is entirely independent of central FSF or GNU infrastructure 
such as savannah.  So RMS has no control over policies applied to GCC 
mailing lists, and any influence he might apply to the moderation of lists 
hosted on lists.gnu.org does not apply here.  (Although GCC releases are 
uploaded to ftp.gnu.org, which is central GNU infrastructure, they are 
also available at https://gcc.gnu.org/pub/gcc/releases/ .)  He has an 
ordinary restricted user account on gcc.gnu.org giving the same access to 
push commits as most committers; he does not have shell or administrative 
access.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Remove RMS from the GCC Steering Committee

[Christopher Dimech via Gcc]

> Sent: Wednesday, March 31, 2021 at 4:50 AM
> From: "Martin Jambor" 
> To: "Giacomo Tesio" 
> Cc: "GCC Development" 
> Subject: Re: Remove RMS from the GCC Steering Committee
>
> Dear Giacomo,
> 
> On Tue, Mar 30 2021, Giacomo Tesio wrote:
> > Hi Nathan and hello everybody,
> >
> > On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote:
> >
> >> The USA is not the world and the SC is not the US government.  For
> >> those in the USA, the (inapplicable) first amendment provides 5
> >> rights, including showing an unwelcome guest the door. [...]
> >>
> >> If we fail to do so, it will continue to be harder and harder to
> >> attract new talent to GCC development.
> >
> > I do not know if I qualify to speak here because I'm Italian and
> > I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see
> > http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the
> > pandemic I wasn't able to align it with the new developments and
> > contribute the port upstream. Also, I have no idea if you would be
> > interested in running GCC on a Plan 9 fork and thus accept my
> > contribution.
> >
> >
> > Yet, after a careful read of this thread I realized that I might
> > be considered the kind of "new talent" Nathan is talking about.
> >
> > So here is my perspective on this topic, "in the hope it helps but
> > without any warranty". :-D
> >
> >
> > I do not share many of Stallman's opinions (we are VERY different), but
> > when I write free software and contribute to a free software community,
> > what I want is long term assurances about one and only one topic: that
> > the software will stay free as in freedom, as a common good for the
> > whole humanity.
> >
> > As of today, GPLv3 is the legal tool that best suit this goal.
> > I don't think it's perfect in this regards, but that's another story.
> 
> Nobody suggested that GCC would be relicensed and certainly not to a
> non-free license.  If you decide to contribute your port upstream, it
> will be safe with us, regardless of who will or will not be on the
> steering committee or running the FSF.  Just read the copyright
> assignment text that you have singed or would need to sign to contribute
> and look for FSF obligations as the license holder there.
> 
> > As an Italian I'm having a hard time trying to follow your reasoning
> > about Stallman being a problem to attract new talents.
> 
> I do not believe that being European or Italian has anything to do with
> it. I am European, I understand and agree with everything Nathan wrote
> and apparently I am not the only one.
> 
> The ability to see and stand up to consistent wrongdoing is universal
> and every human of every nationality posses it.  Unfortunately, all
> people are also able to close their eyes and ears and ignore mistreatment
> when they are not the victims and when their friend or their favorite
> public figure is the perpetrator.  There is absolutely nothing American
> or European about either.

Young socialists have been getting organized on colleges campuses 
with these extreme ideas not only in the United States.  France, for
instance has been harbouring a socialist model we should all dread.

France was once a role model for what big government can do for its
people. But it has become an embarrassing example since “The Gilets
Jaunes” took to the streets to demonstrate against the insane amount
of taxes they pay. These guys aren’t upper class. They are the people
who had supported the policies that are inevitable when you have the
government providing so many services and involved so deeply in so much
of the economy.

All those people in America who currently fall for the socialism soup
that that Ocasio-Cortez and Sanders are selling need to realize that if
their dream came to pass, they, not the rich – not the bankers and politicians
– will be ones suffering the most from the high taxes, high unemployment, and
slow growth that go hand in hand with the level of public spending they want.

> Sincerely,
> 
> Martin
>

Re: Remove RMS from the GCC Steering Committee

[JeanHeyd Meneide via Gcc]

Dear Giacomo,

 I want to reply specifically to you because you, like me, are a
new contributor, and I have a few questions and a few points that I
think are salient in this discussion.

> As an Italian I'm having a hard time trying to follow your reasoning
> about Stallman being a problem to attract new talents.
>
> I could understand such statement if he had committed actual crimes,
> was legally persecuted, processed and condemned like Reiser.
>
> But while I try, I cannot really understand why you think that his name
> in the Steering Committee would drive away people from contributing GCC

 The first is that I don't want to get into the conversation about
how the FSF handles Stallman. Other than them having my Copyright
assignment (something I also need to take a look at), the FSF does not
write the code. GCC's contributors, like you and me, do. My biggest
problem with Stallman right now is not about whether or not he likes
US-ians or if he's a good person:

 My problem is Dr. Richard M. Stallman stands credibly and
factually accused of Doxxing and GCC contributor/participant and
knowingly manipulating the project for his own personal reasons.

 When I say this, I want to be clear: when Mark sent his e-mail I
followed up with multiple GCC contributors to determine how factual
his claim actually was. Multiple people have independently
corroborated that Stallman did what Mark said, and worse, and their
quotes of Stallman's words line up word-for-word. In fact, what
Stallman did was worse than what Mark described, and has happened
multiple times before. Stallman is willing to attack and engage in
cancel culture of his own contributors. What his reasons are, I don't
know and I do not want to know: my bottom line here is that Stallman
is a danger to GCC contributors and is harmful to them.

 I make no argument based on my ethnicity, skin color, which side
of the globe I come from. Dr. Stallman's demonstrated behavior is that
he can - and WILL, and HAS - shown up into places where he has very
little to offer technically and utterly derailed or otherwise harmed
individuals or peoples **and their code contributions**.

 So, it boils down to this for me: either GCC is a place where all
contributions are welcome, or GCC is a place of hypocrisy, where
contributions are welcome except when Stallman (or someone else in a
position of power) lobbies a non-technical, non-factual argument
against you and jumps from their high tower to slam down on
rank-and-file contributors and participants. You cannot have it both
ways.

  That is why I switched from "wait and see" to "absolutely not".
I am not going to wait for the day somebody high up enough on the GCC
ladder doesn't like me enough to decide that he's going to
shoulder-slam my contributions with non-technical claptrap, nor am I
going to recommend other people to this project if anyone can do that
to them. Which brings me to another important point...

> I do not really know if the removing Stallman from the Steering
> Committee would attract more US people in GCC development. Or if it
> would attract more US people that now prefer to work in LLVM only
> because of they feel somehow bad working with Stallman in the SC.
>
>
> But I can assure you that, as Pankaj Jangid said before me, many many
> people are attracted to GCC, as users and developers, BECAUSE of
> Stallman presence, because they know that something like this
> https://medium.com/@giacomo_59737/what-i-wish-i-knew-before-contributing-to-open-source-dd63acd20696
> will not happen to them.
>
>
> World wide, people do not LIKE Stallman, but we TRUST him on this.
> Just like the GPLv3, RMS is not perfect, but it does ONE THING well.

 You state it here and many others say it throughout the thread
that Stallman is the only reason they contribute to GCC, or similar
Free Software projects. This deeply concerns me, because the
underlying implication is if that Stallman were to disappear, right
this second, all of you would be gone. Yet, on the other hand, we say
that this is the "Free Software MOVEMENT". A movement cannot be
destroyed because one person disappears; if that is the case, it is
not a movement, but a ring of personality around an individual. Either
this is a Free Software Movement, or this is Stallman's Free Software
Shindig. I contribute to GCC because I expect that when Stallman is
gone and I am Stallman's age, there will still be a Free Software
Movement. Stewarded by the FSF or the CNCF or the {insert gathering of
like-minded OSS contributors and enthusiasts and hard workers here}.

 Is this not the case for you and others?

 If Stallman is the only thing holding this movement together, I
would like to know this now so I can invest my time in an actual
movement elsewhere, independently of whether or not he remains on the
Steering Committee. (I still believe he has no place to have a
position of power on the Steering Committee, and instead should just
be a 

Re: Remove RMS from the GCC Steering Committee

[Markus Böck via Gcc]

Hello Giacomo and everyone else!

As a neighbour to your north (Austria), and another potential
newcomer, I would also like to point out that I do not believe the
views given by Nathan and others in support of him are very
US-centric. At least I would hope that most countries are in pursuit
or see value in having an inclusive environment where no one has to
feel treated unfairly due to either their gender, race or other
things. For what it's worth, Nathan may have simply picked the USA as
an example due familiarity. We don't know that.
As far as I am aware many of the people who have been participating in
this thread are also not from the USA.

I am also of the opinion that legally wrong does not equal morally
wrong. RMS does not have to have committed a crime for the developers
of GCC, the SC or whoever, to feel like he is not representing their
values as a member of the SC well.

Best regards
Markus

On Tue, Mar 30, 2021 at 3:20 PM Giacomo Tesio  wrote:
>
> Hi Nathan and hello everybody,
>
> On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote:
>
> > The USA is not the world and the SC is not the US government.  For
> > those in the USA, the (inapplicable) first amendment provides 5
> > rights, including showing an unwelcome guest the door. [...]
> >
> > If we fail to do so, it will continue to be harder and harder to
> > attract new talent to GCC development.
>
> I do not know if I qualify to speak here because I'm Italian and
> I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see
> http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the
> pandemic I wasn't able to align it with the new developments and
> contribute the port upstream. Also, I have no idea if you would be
> interested in running GCC on a Plan 9 fork and thus accept my
> contribution.
>
>
> Yet, after a careful read of this thread I realized that I might
> be considered the kind of "new talent" Nathan is talking about.
>
> So here is my perspective on this topic, "in the hope it helps but
> without any warranty". :-D
>
>
> I do not share many of Stallman's opinions (we are VERY different), but
> when I write free software and contribute to a free software community,
> what I want is long term assurances about one and only one topic: that
> the software will stay free as in freedom, as a common good for the
> whole humanity.
>
> As of today, GPLv3 is the legal tool that best suit this goal.
> I don't think it's perfect in this regards, but that's another story.
>
>
> As an Italian I'm having a hard time trying to follow your reasoning
> about Stallman being a problem to attract new talents.
>
> I could understand such statement if he had committed actual crimes,
> was legally persecuted, processed and condemned like Reiser.
>
> But while I try, I cannot really understand why you think that his name
> in the Steering Committee would drive away people from contributing GCC
>
>
> I ported GCC to Plan 9 because I want a free compiler suite for my OS.
>
> Porting CLANG would have been easier (to some extent) BUT my choice was
> political and Stallman in the Steering Committee is a long term
> warranty that GCC development will not steer away from the Free
> Software conception that I know, betraying my trust.
>
>
> My impression is that you are, in absolute good faith, projecting your
> own culture (quite US-centric, as far as I can deduce by this thread)
> to the whole world.
>
>
> I do not really know if the removing Stallman from the Steering
> Committee would attract more US people in GCC development. Or if it
> would attract more US people that now prefer to work in LLVM only
> because of they feel somehow bad working with Stallman in the SC.
>
>
> But I can assure you that, as Pankaj Jangid said before me, many many
> people are attracted to GCC, as users and developers, BECAUSE of
> Stallman presence, because they know that something like this
> https://medium.com/@giacomo_59737/what-i-wish-i-knew-before-contributing-to-open-source-dd63acd20696
> will not happen to them.
>
>
> World wide, people do not LIKE Stallman, but we TRUST him on this.
> Just like the GPLv3, RMS is not perfect, but it does ONE THING well.
>
>
> So, since you care about demographics, please consider that.
>
> Removing RMS you might attract more of certain US demographics,
> but you will certainly alienate a lot of people world wide that
> do not align your political values (despite respecting them a lot!)
> and do not think that a compiler suite can fix US systemic issues
> anyway.
>
>
> As for me, I would NOT trust GCC (or FSF) in the long term, had
> you to distance Stallman, because I've already seen with my eyes
> what happen when people do not have anything to loose to betray your
> trust, and Stallman has all to lose by betraying Free Software.
>
>
> Maybe I'm not the "new talent" you are looking for.
>
> But please, do not turn GCC into a US-centric project.
>
>
>
> Giacomo

Re: Remove RMS from the GCC Steering Committee

[Martin Jambor]

Dear Giacomo,

On Tue, Mar 30 2021, Giacomo Tesio wrote:
> Hi Nathan and hello everybody,
>
> On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote:
>
>> The USA is not the world and the SC is not the US government.  For
>> those in the USA, the (inapplicable) first amendment provides 5
>> rights, including showing an unwelcome guest the door. [...]
>>
>> If we fail to do so, it will continue to be harder and harder to
>> attract new talent to GCC development.
>
> I do not know if I qualify to speak here because I'm Italian and
> I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see
> http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the
> pandemic I wasn't able to align it with the new developments and
> contribute the port upstream. Also, I have no idea if you would be
> interested in running GCC on a Plan 9 fork and thus accept my
> contribution.
>
>
> Yet, after a careful read of this thread I realized that I might
> be considered the kind of "new talent" Nathan is talking about.
>
> So here is my perspective on this topic, "in the hope it helps but
> without any warranty". :-D
>
>
> I do not share many of Stallman's opinions (we are VERY different), but
> when I write free software and contribute to a free software community,
> what I want is long term assurances about one and only one topic: that
> the software will stay free as in freedom, as a common good for the
> whole humanity.
>
> As of today, GPLv3 is the legal tool that best suit this goal.
> I don't think it's perfect in this regards, but that's another story.

Nobody suggested that GCC would be relicensed and certainly not to a
non-free license.  If you decide to contribute your port upstream, it
will be safe with us, regardless of who will or will not be on the
steering committee or running the FSF.  Just read the copyright
assignment text that you have singed or would need to sign to contribute
and look for FSF obligations as the license holder there.

> As an Italian I'm having a hard time trying to follow your reasoning
> about Stallman being a problem to attract new talents.

I do not believe that being European or Italian has anything to do with
it. I am European, I understand and agree with everything Nathan wrote
and apparently I am not the only one.

The ability to see and stand up to consistent wrongdoing is universal
and every human of every nationality posses it.  Unfortunately, all
people are also able to close their eyes and ears and ignore mistreatment
when they are not the victims and when their friend or their favorite
public figure is the perpetrator.  There is absolutely nothing American
or European about either.

Sincerely,

Martin

Re: Remove RMS from the GCC Steering Committee

[Richard Kenner via Gcc]

> 3. Most of claims about Stallman are not true (to be more precise -
> they are deliberately misrepresent what Stallman said to make his
> views to look immoral).

I would like to suggest that this discussion will go better without
making accusations that people are "deliberately" doing something.  In
my opinion, there are many different ways both of interpreting what
somebody writes and in making value judgements on the appropriateness
of saying something in a certain way.

Just because you and somebody else interpret a statement in different
ways or have different moral views of the propriety of saying
something in a certain way doesn't mean that either of you are
"deliberately misrepresting" anything.

Remove RMS from the GCC Steering Committee

[Maksim Fomin via Gcc]

‐‐‐ Original Message ‐‐‐
On Friday, 26 March 2021 г., 23:02, Nathan Sidwell  wrote:

> 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.
>
> Perhaps you discount the benefits of white male privilege. You’re wrong.
>
> 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.

[Left most relevant parts of the letter]

The logic of this letter (and sjw in general) is obviously false.

1. There are no examples where Stallman (or people with similar views) censored 
project contribution from non-white non-male people.
In recent decades there is inflow of people from different counties and 2020 is 
definitely more diverse in programming than 2000 or 1980.
This observation (absense of discrimiation) is the first important note which 
blows the login behind the letter.

2. Because the p1 is hard to refute, the discussion moves from objective things 
(for example, rejecting some pull request from people of color) toward 
subjective
things like 'remove Stallman because I am not comfortable with his 
views/claims'. However, once this arguement is naked from the rest of 
discussion it becomes obviously weak.
Why the project should remove Stallman because 'some' people are not 
comfortable? Why sjw consider themselves in the position to judge? What to do 
with the group of people who supports him?
Finally, 'white priviledge' is only one (although  big) subject of dedates. 
What happens if other areas of social, political or economical debates are 
brought to the project? There are plenty of issues which divide people and 
there is no way to make the project to move of on if for each issue one group 
of people will demand removing members of comittee because of their views.

3. Most of claims about Stallman are not true (to be more precise - they are 
deliberately misrepresent what Stallman said to make his views to look immoral).

4. Regarding morality. This letter (like many other sjw creatures) says many 
words about morality, diversity, but at the end of the day it boils down to 
removing Stallman from position. As a citizen of post-soviet country I can 
vividly see that this letter is enterely about politics and looks very similar 
to communist agenda which likes to hide authoritarian policies behind morality. 
It is very surprising for people from former Soviet block countries to see 
western world falling into 'very familiar' but notorious propaganda.

Best regards,
Maxim Fomin

GCC Plugin introduction

[Gabriele Serra]

Hi, Saifi

On Tue, 30 Mar 2021, SAIFI wrote:


Gabriele thanks for sharing the detailed write up.

in the spirit of 'gcc-help', can you please share pointers as to how one can 
profile C++ code using GCC plugins ?

in your example you mention 'f1 ()'; i'd like to replace that with a instance 
of class 'X' created and then profile or instrument a member function.

Have you explored that ? any preliminary thoughts on how does one go about 
doing it ?

warm regards
Saifi.


to be honest, I hadn't the chance to profile C++ code. I think the problem can 
be solved in different ways.
A quick and dirty solution, you can build 'X' as a singleton and then, in the 
profiler function (declared as static) get the singleton instance.
However, if your class need to be instanced multiple times, an idea could be to declare 
the profiler function as static and then pass "this" as the first parameter.
Clearly in this second scenario, your function must "see" in some way the 
instance of the class X mentioned.

These are my preliminary thoughts but I think the way you can implement this 
really depends on the use case.

For instance, if your profiler can be executed after the function prologue,
maybe it is possible to operate directly with GIMPLE and realize something like 
the C++11 lambda function (with the capture list).
Here, unfortunately, I can't say more than this because I hadn't the chance to 
analyze deeper the question.

However, in next few days, I will investigate on that.

Thank for the question
Regards,
Gabriele Serra

Re: GSoC 2021 - Static analyzer project

[David Malcolm via Gcc]

On Tue, 2021-03-30 at 16:36 +0530, Ankur Saini wrote:
> hello sir 
> 
> in my quest of finding a bug ( which ended up being a feature ) along
> with it’s source in the analyzer, I tested the code on these 2 code
> snippets and here’s how I went towards it 
> 
> (1)
> int main()
> {
>     int *ptr = (int *)malloc(sizeof(int));
>     return 0;
> }
> 
> link to running example (https://godbolt.org/z/1jGW1qYez <
> https://godbolt.org/z/1jGW1qYez>)
> 
> (2)
> int definaltly_main()
> {
>     int *ptr = (int *)malloc(sizeof(int));
>     return 0;
> }
> 
> link to running example (https://godbolt.org/z/bzjMYex4M <
> https://godbolt.org/z/bzjMYex4M>)
> 
> 
> where on second snipper analyzer is warning us about the leak as it
> should be, but in the first one it isn’t. 
> 
> and as the gimple representation of both looks exactly the same apart
> from function name, which made me think that either intentionally or
> unintentionally, analyzer handles case of main() differently than any
> other function.

Correct - the analyzer special-cases "main".

Specifically, in impl_region_model_context::on_state_leak, there's this
code:
  
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/analyzer/engine.cc;h=d7866b5598b4fcb791ec6ff511dde9b7615e7794;hb=HEAD#l624

 624   /* Don't complain about leaks when returning from "main".  */
 625   if (m_enode_for_diag->get_supernode ()
 626   && m_enode_for_diag->get_supernode ()->return_p ())
 627 {
 628   tree fndecl = m_enode_for_diag->get_function ()->decl;
 629   if (id_equal (DECL_NAME (fndecl), "main"))
 630 {
 631   if (logger)
 632 logger->log ("not reporting leak from main");
 633   return;
 634 }
 635 }

on the grounds that for the resources that the analyzer currently
tracks, it doesn't matter if they aren't cleaned up as the process
exits, so we don't bother the user with a report about them.

> so while looking at it’s exploded graphs I found out that the only 2
> differences in them 
> 
> 1. There is one less exploded node(after node E-8) created in first
> one ( I earlier thought state merging or state pruning is taking
> place here but it isn’t because the results are not affected even
> after disabling those using  `-fno-analyzer-state-purge` and `-fno-
> analyzer-state-merge` options )

Well spotted.

I see that too.

For (1) EN 8, has 2 stmts, the label and the return, but for (2), it
splits them with EN: 8 having just the label, and the return split into
EN 9.

I was surprised by this and did some digging in gdb, for both (1) and
(2).  The reason seems to be rather arbitrary; specifically in (2),
stmt_requires_new_enode_p is returning true due to hitting this case:

2894  /* If we had a PREV_STMT with an unknown location, and this stmt
2895 has a known location, then if a state change happens here, it
2896 could be consolidated into PREV_STMT, giving us an event with
2897 no location.  Ensure that STMT gets its own exploded_node to
2898 avoid this.  */
2899  if (get_pure_location (prev_stmt->location) == UNKNOWN_LOCATION
2900  && get_pure_location (stmt->location) != UNKNOWN_LOCATION)
2901return true;

and presumably it isn't hitting this for (1).

Specifically, where "stmt" is the return stmt and "prev_stmt" is the
label statement.

for (1):

(gdb) p /x stmt->location
$1 = 0x0
(gdb) p /x prev_stmt->location
$2 = 0x0

whereas for (2):

(gdb) p /x stmt->location
$5 = 0x80f2
(gdb) p /x prev_stmt->location
$6 = 0x0

So with (1) the return stmt has UNKNOWN_LOCATION:

(gdb) call inform (stmt->location, "return stmt in (1)")
In function ‘main’:
cc1: note: return stmt in (1)

whereas for (2) the return stmt has a source location:

(gdb) call inform (stmt->location, "return stmt in (2)")
In function ‘definaltly_main’:
/tmp/2.c:6:12: note: return stmt in (2)
6 | return 0;
  |^

This slight difference in the recorded location of the return stmt for
the "main" vs non-"main" case affects the splitting of the nodes.

Athough a curiosity, I don't think this is significant.  (In theory one
could use a hardware watchpoint on stmt->location to track this
discrepancy down further, but I don't think it's important enough to
bother).


> 2. no diagnosis for malloc leak happening at the end of first one
> even though there exist a pointer in unchecked state at the end (
> according to the malloc state machine )

Correct - the analyzer specialcases "main" and ignores it, as noted
above.


> In quest to find the cause I started navigating through the source
> code of the analyser starting off with the run_checkers() function in
> engine.cc which looks like the entry point of the analyser ( found
> via the commit history of the analyzer ). But finally it ended at
> `impl_region_model_context::on_state_leak()` function where I found
> out that analyzer is intentionally skipping the leak report when it
> is in main. 

Sounds like you successfully tra

Re: Copyright assignment

[David Edelsohn via Gcc]

Replied off-list.

On Tue, Mar 30, 2021 at 9:49 AM George Liakopoulos via Gcc
 wrote:
>
> Dear GCC Community ,
>
> I am planning to contribute in Rust-GCC project (
> https://github.com/Rust-GCC) , so I think it will be good to have the
> copyright assignment from now on .
>
> Waiting for your reply ,
> George Liakopoulos

Copyright assignment

[George Liakopoulos via Gcc]

Dear GCC Community ,

I am planning to contribute in Rust-GCC project (
https://github.com/Rust-GCC) , so I think it will be good to have the
copyright assignment from now on .

Waiting for your reply ,
George Liakopoulos

Re: Remove RMS from the GCC Steering Committee

[Christopher Dimech via Gcc]

> Sent: Wednesday, March 31, 2021 at 1:16 AM
> From: "Giacomo Tesio" 
> To: "Nathan Sidwell" 
> Cc: "GCC Development" 
> Subject: Re: Remove RMS from the GCC Steering Committee
>
> Hi Nathan and hello everybody,
>
> On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote:
>
> > The USA is not the world and the SC is not the US government.  For
> > those in the USA, the (inapplicable) first amendment provides 5
> > rights, including showing an unwelcome guest the door. [...]
> >
> > If we fail to do so, it will continue to be harder and harder to
> > attract new talent to GCC development.
>
> I do not know if I qualify to speak here because I'm Italian and
> I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see
> http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the
> pandemic I wasn't able to align it with the new developments and
> contribute the port upstream. Also, I have no idea if you would be
> interested in running GCC on a Plan 9 fork and thus accept my
> contribution.
>
>
> Yet, after a careful read of this thread I realized that I might
> be considered the kind of "new talent" Nathan is talking about.
>
> So here is my perspective on this topic, "in the hope it helps but
> without any warranty". :-D
>
>
> I do not share many of Stallman's opinions (we are VERY different), but
> when I write free software and contribute to a free software community,
> what I want is long term assurances about one and only one topic: that
> the software will stay free as in freedom, as a common good for the
> whole humanity.
>
> As of today, GPLv3 is the legal tool that best suit this goal.
> I don't think it's perfect in this regards, but that's another story.
>
>
> As an Italian I'm having a hard time trying to follow your reasoning
> about Stallman being a problem to attract new talents.
>
> I could understand such statement if he had committed actual crimes,
> was legally persecuted, processed and condemned like Reiser.
>
> But while I try, I cannot really understand why you think that his name
> in the Steering Committee would drive away people from contributing GCC
>
>
> I ported GCC to Plan 9 because I want a free compiler suite for my OS.
>
> Porting CLANG would have been easier (to some extent) BUT my choice was
> political and Stallman in the Steering Committee is a long term
> warranty that GCC development will not steer away from the Free
> Software conception that I know, betraying my trust.
>
>
> My impression is that you are, in absolute good faith, projecting your
> own culture (quite US-centric, as far as I can deduce by this thread)
> to the whole world.

Correct.  Very good evaluation.

> I do not really know if the removing Stallman from the Steering
> Committee would attract more US people in GCC development. Or if it
> would attract more US people that now prefer to work in LLVM only
> because of they feel somehow bad working with Stallman in the SC.
>
>
> But I can assure you that, as Pankaj Jangid said before me, many many
> people are attracted to GCC, as users and developers, BECAUSE of
> Stallman presence, because they know that something like this
> https://medium.com/@giacomo_59737/what-i-wish-i-knew-before-contributing-to-open-source-dd63acd20696
> will not happen to them.
>
>
> World wide, people do not LIKE Stallman, but we TRUST him on this.
> Just like the GPLv3, RMS is not perfect, but it does ONE THING well.
>
>
> So, since you care about demographics, please consider that.
>
> Removing RMS you might attract more of certain US demographics,
> but you will certainly alienate a lot of people world wide that
> do not align your political values (despite respecting them a lot!)
> and do not think that a compiler suite can fix US systemic issues
> anyway.
>
>
> As for me, I would NOT trust GCC (or FSF) in the long term, had
> you to distance Stallman, because I've already seen with my eyes
> what happen when people do not have anything to loose to betray your
> trust, and Stallman has all to lose by betraying Free Software.
>
>
> Maybe I'm not the "new talent" you are looking for.

The Gnu Project looks for all kind of talent.

> But please, do not turn GCC into a US-centric project.


> Giacomo

Re: Remove RMS from the GCC Steering Committee

[Giacomo Tesio]

Hi Nathan and hello everybody,

On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote:

> The USA is not the world and the SC is not the US government.  For
> those in the USA, the (inapplicable) first amendment provides 5
> rights, including showing an unwelcome guest the door. [...]
>
> If we fail to do so, it will continue to be harder and harder to
> attract new talent to GCC development.

I do not know if I qualify to speak here because I'm Italian and
I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see
http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the
pandemic I wasn't able to align it with the new developments and
contribute the port upstream. Also, I have no idea if you would be
interested in running GCC on a Plan 9 fork and thus accept my
contribution.


Yet, after a careful read of this thread I realized that I might
be considered the kind of "new talent" Nathan is talking about.

So here is my perspective on this topic, "in the hope it helps but
without any warranty". :-D


I do not share many of Stallman's opinions (we are VERY different), but
when I write free software and contribute to a free software community,
what I want is long term assurances about one and only one topic: that
the software will stay free as in freedom, as a common good for the
whole humanity.

As of today, GPLv3 is the legal tool that best suit this goal.
I don't think it's perfect in this regards, but that's another story.


As an Italian I'm having a hard time trying to follow your reasoning
about Stallman being a problem to attract new talents.

I could understand such statement if he had committed actual crimes,
was legally persecuted, processed and condemned like Reiser.

But while I try, I cannot really understand why you think that his name
in the Steering Committee would drive away people from contributing GCC 


I ported GCC to Plan 9 because I want a free compiler suite for my OS.

Porting CLANG would have been easier (to some extent) BUT my choice was
political and Stallman in the Steering Committee is a long term
warranty that GCC development will not steer away from the Free
Software conception that I know, betraying my trust.


My impression is that you are, in absolute good faith, projecting your
own culture (quite US-centric, as far as I can deduce by this thread)
to the whole world.


I do not really know if the removing Stallman from the Steering
Committee would attract more US people in GCC development. Or if it
would attract more US people that now prefer to work in LLVM only
because of they feel somehow bad working with Stallman in the SC.


But I can assure you that, as Pankaj Jangid said before me, many many
people are attracted to GCC, as users and developers, BECAUSE of
Stallman presence, because they know that something like this
https://medium.com/@giacomo_59737/what-i-wish-i-knew-before-contributing-to-open-source-dd63acd20696
will not happen to them.


World wide, people do not LIKE Stallman, but we TRUST him on this.
Just like the GPLv3, RMS is not perfect, but it does ONE THING well.


So, since you care about demographics, please consider that.

Removing RMS you might attract more of certain US demographics,
but you will certainly alienate a lot of people world wide that
do not align your political values (despite respecting them a lot!)
and do not think that a compiler suite can fix US systemic issues
anyway.


As for me, I would NOT trust GCC (or FSF) in the long term, had
you to distance Stallman, because I've already seen with my eyes 
what happen when people do not have anything to loose to betray your
trust, and Stallman has all to lose by betraying Free Software. 


Maybe I'm not the "new talent" you are looking for.

But please, do not turn GCC into a US-centric project.



Giacomo

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[David Malcolm via Gcc]

On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> On Sun, Mar 28, 2021 at 8:03 PM David Malcolm 
> wrote:
> 
> > 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.
> > 
> > Hi, thanks for the effort, sorry for the typo. I now know about the
> godbolt.org and it is certainly useful.
> 
> > 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
> > 
> > That's something new. I also didn't know that. I believe we can
> > shift our
> minimal example to just func() and remove main().

Yes - simpler is better with such examples.

(Occasionally it's helpful to have "main" so that the resulting code
can be executed - especially under valgrind, as a check that something
really is leaking - but a simpler reproducer is usually best when
debugging)

[...snip...]

> > I think an implementation of exception-handling would look somewhat
> > similar.
> > 
> > Thanks, for all the references to the code. I am new to GCC, so
> > apologies
> if I am a bit slow in understanding. I am trying to run and go
> through all
> the references that you gave me.

Sorry if I'm overwhelming you with too much at once...

...and here's yet more information!

I wrote this guide to getting started with hacking on GCC, aimed at
newcomers to the project:
  https://dmalcolm.fedorapeople.org/gcc/newbies-guide/

and in particular you may find the guide to debugging GCC useful:
  https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html

FWIW I like to use
  -fanalyzer-dump-stderr
when stepping through the analyzer in gdb, so that I can put
breakpoints on what I'm interested in, but also have a log of the
activity that happened between the breakpoints.


> > > Please, let me know your thoughts on this.
> > 
> > Looks like you're making a great start.
> > 
> Thanks for the feedback.  In parallel, can I start working on the
> Gsoc
> proposal as well?

Please do work on the formal proposal - without it we can't accept you
as a GSoC student.  The window for submitting proposals opened
yesterday, and I believe it closes in a couple of weeks, and you need
to do that, so any experimentation you do now should really just be in
support of writing a good proposal.  It would be a shame to not have a
good prospective candidate because they didn't allow enough time to do
the proper GSoC paperwork before the deadline.

> I hope, we can get suggestions from the gcc community as
> well once the things are written properly in a document.

Indeed

Hope this is constructive
Dave

[...snip...]

Re: Remove RMS from the GCC Steering Committee

[Richard Kenner via Gcc]

> I respect that you want stay out of the discussion, but I think that to
> present this as some larger societal issue which is somewhat academic
> is wrong. 

Sorry, I didn't mean to say or imply that.  What I meant to say is
that the very specific discussion we're having in this forum *mirrors*
the similar discussion that society is having in that the same issues
that are being discussed here are also being discussed there.

> And I hate to point to others, because I know these people, who
> worked closely with RMS, will get harassed to "proof" their
> allegations or will be told that since they were not physically
> attacked it doesn't count as harassment.

This is exactly what I mean by the need to draw a line.  At what point
does somebody's behavior rise to the level where it's necessary to
take action?  In other words, I think the question is less in understanding
what RMS's behavior has been (I suspect most people would agree on that),
but what the appropriate consequences of that behavior should be.

Re: Remove RMS from the GCC Steering Committee

[Christopher Dimech via Gcc]

> Sent: Tuesday, March 30, 2021 at 11:55 PM
> From: "Richard Kenner" 
> To: dim...@gmx.com
> Cc: gcc@gcc.gnu.org, m...@klomp.org, m...@soulstudios.co.nz, nat...@acm.org
> Subject: Re: Remove RMS from the GCC Steering Committee
>
> > Here is something close to the fundamental issue: Believing in
> > private life, that people are entitled to their own associations and
> > opinions (even bad ones!), and entitled to make their own mistakes,
> > too and that, barring some direct connection to work life or
> > extraordinary circumstance, that none of this is the concern of the
> > little platoons of finks lurking in the community,
>
> But I think that's exactly the question: when does something have a "direct
> connection to work life"?  Remember back in 2007 when US airlines were asking
> their pilots not to wear their uniforms to Unemployment offices because
> they were concerned about negative effect on their companies?

It is somewhat more complicated because his position con be recognised by
various people living in various countries, and thus does not fall into
one jurisdiction.  It seems to me that the situation is quite similar
to international law, where treaties requires all ratifying countries.
This can be extremely difficult.  Because Stallman is the founder, it
is in his prerogative to claim authority over the project.  I have been
a proponent over a transition and discussed this with him.  There could
have been possibilities for this to happen.  But in the climate that has
been created, he won't find the right conditions for a transition to occur.

Many had the chance to work with him but screwed it up.  People got to
understand this.

Christopher

Re: GNU #include RFC

[Pankaj Jangid]

Alexandre Oliva via Gcc  writes:

> I hereby announce my intent to offer online tutoring with the goal of
> helping reduce democraphic imbalances in the GCC development community.
>
> My planned focus is the implementation, in GCC, of the ISA extensions to
> OpenPOWER in the upcoming Libre-SOC processor in GCC, but I may also
> cover some neurodiversity, to try and make some of my quirks less
> difficult to tolerate, and Free Software philosophy/ethics/copyleft,
> because I can't help :-)
>
> Some of the philosophy tutoring may actually be delivered by the Chief
> GNUisance himself, in occasional online group meetings.  (He was very
> receptive and supportive to the whole plan, as I hoped and expected :-)
>
> ...
>
> Would anyone else be willing to participate as mentor?

Sounds like a good beginning (again). But I would participate as a
mentee.

-- 
Regards,
Pankaj Jangid

Re: Remove RMS from the GCC Steering Committee

[Richard Kenner via Gcc]

> For a leadership position, which serves as an example for
> the community and to some extent demonstrates the values shared by the
> community, I think it is reasonable that there is a decreased
> expectation of privacy.

.. and libel and defamation laws in the US reflect that, for example.

Re: Question about points-to analysis, global variables, IPA, and field sensitivity

[Richard Biener via Gcc]

On Tue, Mar 30, 2021 at 1:39 PM Erick Ochoa  wrote:
>
> > If the global is module local we should initialize it with NULL, yes.  If 
> > it is
> > not module local it should be initialized with NONLOCAL (that's both what
> > should currently happen correctly - it's needed for non-field-sensitive init
> > as well).
> >
>
> Awesome, thanks Richard! One more question: in the context of LTO,
> "module local" means the current partition?

Yes.

> I understand that IPA-PTA is a late SIMPLE_IPA_PASS but my
> understanding of the consequences of this is a little fuzzy. I think
> that IPA-PTA also runs in multiple partitions (unless a flag like
> -flto-partition=none is used), but there might be some issue with
> reduced precision. Perhaps this reduced precision comes from NONLOCAL
> constraints with symbols that cross partitions? (This is just
> speculation on my part, as I mention, my understanding is a little bit
> fuzzy.)

Yes.  Also (obviously) from function definitions not visible and thus
functions treated as external calls when they need not (because of LTO)

Richard.

Re: Question about points-to analysis, global variables, IPA, and field sensitivity

[Erick Ochoa via Gcc]

> If the global is module local we should initialize it with NULL, yes.  If it 
> is
> not module local it should be initialized with NONLOCAL (that's both what
> should currently happen correctly - it's needed for non-field-sensitive init
> as well).
>

Awesome, thanks Richard! One more question: in the context of LTO,
"module local" means the current partition?

I understand that IPA-PTA is a late SIMPLE_IPA_PASS but my
understanding of the consequences of this is a little fuzzy. I think
that IPA-PTA also runs in multiple partitions (unless a flag like
-flto-partition=none is used), but there might be some issue with
reduced precision. Perhaps this reduced precision comes from NONLOCAL
constraints with symbols that cross partitions? (This is just
speculation on my part, as I mention, my understanding is a little bit
fuzzy.)

Re: Remove RMS from the GCC Steering Committee

[Jonathan Wakely via Gcc]

On Tue, 30 Mar 2021 at 12:13, Andrew Haley wrote:
>
> On 3/30/21 11:34 AM, Jonathan Wakely wrote:
> > On Tue, 30 Mar 2021 at 11:14, Andrew Haley wrote:
>
> >> We could just rename it to "GCC", in much the same way that Acorn Risc
> >> Machine became Advanced Risc Machines, then just "Arm". But I'd much
> >> prefer that the FSF got its house in order.
> >
> > whynotboth.jpg
>
> I dunno, I don't want to see the FSF become the Parler of free software
> foundations.

I don't think GCC's continued involvement in the GNU Project will stop
that from happening.

Re: Question about points-to analysis, global variables, IPA, and field sensitivity

[Richard Biener via Gcc]

On Tue, Mar 30, 2021 at 10:52 AM Erick Ochoa via Gcc  wrote:
>
> Hi,
>
> I am looking at the points-to analysis in GCC and I found the
> following comment in tree-ssa-structalias.c:
>
>   /* Collect field information.  */
>   if (use_field_sensitive
>   && var_can_have_subvars (decl)
>   /* ???  Force us to not use subfields for globals in IPA mode.
>  Else we'd have to parse arbitrary initializers.  */
>   && !(in_ipa_mode
>&& is_global_var (decl)))
>
>
> From what I understand here the points-to analysis is explicitly not
> using field sensitivity for global variables when in IPA. I am
> wondering,
> 0) Is "initializers" here talking about brace initializers? Or are
> "initializers" a little bit more abstract and refer to anything that
> can initialize a field? Like struct->field = function()?

initializers refers to static initializers (DECL_INITIAL) on global variables
which satisfy the property of being assemblyable by varasm but can
have some arbitrary GENERIC structure in their field initializers
(like address calculations).

> 1) How much work would it be to parse initializers?

It should be pretty straight-forward to come up with sth conservative.
To make it optimal is a little harder but maybe not so much.  Straight-forward
would be to generate constraints from DECL_INITIAL in a non-field-sensitive
manner and then assign each subfield of the constraint variable this
non-field sensitive solution.  Basically do

  get_constraint_for_rhs (DECL_INITIAL (decl), &rhsc);
  process_all_all_constraints (&lhsc, &rhsc);

and then go improve get_constraint_for_1 to handle CONSTRUCTOR
(otherwise you'll get ANYTHING as fallback for everything it does not handle).

Then there's the missing initializer bits which get zero which means NULL
init (but when not considering field sensitive processing that's likely
superfluous unless you want precise modeling of NULL)

> 2) How would global structs which are not initialized using
> initializers be handled? Would all fields get assigned NULL at the
> global variable level, but then as other fields get assigned we just
> create new constraints with the correct offsets?

If the global is module local we should initialize it with NULL, yes.  If it is
not module local it should be initialized with NONLOCAL (that's both what
should currently happen correctly - it's needed for non-field-sensitive init
as well).

>
> Thanks!

GNU #include RFC

[Alexandre Oliva via Gcc]

I hereby announce my intent to offer online tutoring with the goal of
helping reduce democraphic imbalances in the GCC development community.

My planned focus is the implementation, in GCC, of the ISA extensions to
OpenPOWER in the upcoming Libre-SOC processor in GCC, but I may also
cover some neurodiversity, to try and make some of my quirks less
difficult to tolerate, and Free Software philosophy/ethics/copyleft,
because I can't help :-)

Some of the philosophy tutoring may actually be delivered by the Chief
GNUisance himself, in occasional online group meetings.  (He was very
receptive and supportive to the whole plan, as I hoped and expected :-)


I invite other GCC contributors to join me in offering tutoring to
reduce demographic imbalances in our development community.  Other
tutors are free to focus their efforts in other back-ends/targets,
front-ends, middle-end passes, IRs, general bug-fixing, or even accept
tutoring applicant-submitted proposals.

I invite contributors to other GNU subprojects to make similar offers in
their respective subprojects, too.


Now, one clarification: applicants need not fit in any specific
demographic; the goal is not to exclude any applicants but, if demand is
higher than I (we?) can offer, all else being equal, preference would be
given to candidates that make stronger cases of demographic balancing.
(how to tell?)


My plan is to invite candidates to file applications about their
interest in participating in the development of the subproject, their
personal background, and their diverse strengths and demographic balance
improvements they wish to bring to the subproject.


Would anyone else like to help me turn this into more concrete plans, a
formal call for candidates, web page, etc?

Would anyone else be willing to participate as mentor?


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

[Andrew Haley via Gcc]

On 3/30/21 11:34 AM, Jonathan Wakely wrote:
> On Tue, 30 Mar 2021 at 11:14, Andrew Haley wrote:

>> We could just rename it to "GCC", in much the same way that Acorn Risc
>> Machine became Advanced Risc Machines, then just "Arm". But I'd much
>> prefer that the FSF got its house in order.
> 
> whynotboth.jpg

I dunno, I don't want to see the FSF become the Parler of free software
foundations.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Remove RMS from the GCC Steering Committee

[Pankaj Jangid]

Not quoting anyone here. As a long time user of GCC, I am just worried
about the project. Hence my few comments and reasons for being part of
this movement called free-software.

RMS paid a visit to our premise in year 2000 or may be 2001. The
institute where I started working as a Visiting Software Engineer in the
year 2000. After a few years he came to IIT Bombay. I travelled a long
distance just to listen him again. I knew. The speech would be same, the
cause would be same but still I went.

[I am not sure if I am allowed to write here or not. Though I have
contributed to Emacs, but I have never contributed source code to
GCC. And some people have repeatedly made me feel that this long thread
is exclusively for those who have committed source code lines in GCC.]

I don’t even know what is the qualification of the existing Steering
Committee (SC). I use GCC, because there is a cause associated with
it. Since, last five years I have been reading articles about
superiority of a competing compiler technology - LLVM. But the original
concerns of RMS are clearly visible. Apple keeps the important
optimizations to itself. And many other software giants are also doing
it. Fair enough. They stick to their ideology. They release the code
only when it is longer a threat to their competitive advantage.

I have seriously started looking into Rust when I read about resumption
of work on ‘gccrs’. Such is the effect of this movement on me.

Coming to diversity. I have never seen people travelling 12000 miles to
convince people to join a cause. I am not talking about the
sponsored/luxurious conferences. I am talking about sleeping in a
sleeping-bag for weeks and sharing home-cooked meals with fellow
free-software activists in the remotest part of the world. Don’t get me
wrong. I would certainly like someone who has done more than this for
diversity. I am speaking this from experience. And I don’t have the said
privileges.

My only request to the remaining members of the SC is that - do take a
wise decision. And there is no need to overwhelmed
yourself. Organization, cause, and here the project, is bigger than the
people. People may come and go, people may saying anything. The project
should continue to be lazer focused, and serve the society.

-- 
Regards,
Pankaj Jangid

Re: GSoC 2021 - Static analyzer project

[Ankur Saini via Gcc]

hello sir 

in my quest of finding a bug ( which ended up being a feature ) along with it’s 
source in the analyzer, I tested the code on these 2 code snippets and here’s 
how I went towards it 

(1)
int main()
{
int *ptr = (int *)malloc(sizeof(int));
return 0;
}

link to running example (https://godbolt.org/z/1jGW1qYez 
)

(2)
int definaltly_main()
{
int *ptr = (int *)malloc(sizeof(int));
return 0;
}

link to running example (https://godbolt.org/z/bzjMYex4M 
)


where on second snipper analyzer is warning us about the leak as it should be, 
but in the first one it isn’t. 

and as the gimple representation of both looks exactly the same apart from 
function name, which made me think that either intentionally or 
unintentionally, analyzer handles case of main() differently than any other 
function.

so while looking at it’s exploded graphs I found out that the only 2 
differences in them 

1. There is one less exploded node(after node E-8) created in first one ( I 
earlier thought state merging or state pruning is taking place here but it 
isn’t because the results are not affected even after disabling those using  
`-fno-analyzer-state-purge` and `-fno-analyzer-state-merge` options )

2. no diagnosis for malloc leak happening at the end of first one even though 
there exist a pointer in unchecked state at the end ( according to the malloc 
state machine )

In quest to find the cause I started navigating through the source code of the 
analyser starting off with the run_checkers() function in engine.cc which looks 
like the entry point of the analyser ( found via the commit history of the 
analyzer ). But finally it ended at 
`impl_region_model_context::on_state_leak()` function where I found out that 
analyzer is intentionally skipping the leak report when it is in main. 

This gave rise to some questions

1. why does the analyzer make exceptions with the main() function ?

2. even if it is not complaining about the leak then this still doesn’t explain 
the reason for one less exploded node in this case of main() function.

thanks

- Ankur

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[Saloni Garg via Gcc]

On Sun, Mar 28, 2021 at 8:03 PM David Malcolm  wrote:

> 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.
>
> Hi, thanks for the effort, sorry for the typo. I now know about the
godbolt.org and it is certainly useful.

> 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
>
> That's something new. I also didn't know that. I believe we can shift our
minimal example to just func() and remove main().

> : 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).
>
Thanks for confirming.

>
> > 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.
>
> Thanks, for all the references to the code. I am new to GCC, so apologies
if I am a bit slow in understanding. I am trying to run and go through all
the references that you gave me.

> > Please, let me know your thoughts on this.
>
> Looks like you're making a great start.
>
Thanks for the feedback.  In parallel, can I start working on the Gsoc
proposal as well? I hope, we can get suggestions from the gcc community as
well once the things are written properly in a document.

- Saloni

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

Re: Remove RMS from the GCC Steering Committee

[Jonathan Wakely via Gcc]

On Tue, 30 Mar 2021 at 11:14, Andrew Haley wrote:
>
> On 3/30/21 10:47 AM, Didier Kryn wrote:
> > Le 30/03/2021 à 10:25, Jonathan Wakely via Gcc a écrit :
> >> I've been asking myself what benefit GCC gets from being linked to GNU and
> >> all I can think of is the DNS records for gcc.gnu.org.
> >
> > Can you remind the meaning of GCC. Isn't it "*GNU* Compiler
> > Collection" ?
>
> It's been renamed at least once already, from "GNU C Compiler."
>
> > If this is still true, it doesn't seem appropriate to "break the
> > communication channel" as you said in a previous mail. Or maybe you
> > might suggest a new name for the project (~:
>
> We could just rename it to "GCC", in much the same way that Acorn Risc
> Machine became Advanced Risc Machines, then just "Arm". But I'd much
> prefer that the FSF got its house in order.

whynotboth.jpg

Re: Remove RMS from the GCC Steering Committee

[Andrew Haley via Gcc]

On 3/30/21 10:47 AM, Didier Kryn wrote:
> Le 30/03/2021 à 10:25, Jonathan Wakely via Gcc a écrit :
>> I've been asking myself what benefit GCC gets from being linked to GNU and
>> all I can think of is the DNS records for gcc.gnu.org.
> 
>     Can you remind the meaning of GCC. Isn't it "*GNU* Compiler
> Collection" ?

It's been renamed at least once already, from "GNU C Compiler."

>     If this is still true, it doesn't seem appropriate to "break the
> communication channel" as you said in a previous mail. Or maybe you
> might suggest a new name for the project (~:

We could just rename it to "GCC", in much the same way that Acorn Risc
Machine became Advanced Risc Machines, then just "Arm". But I'd much
prefer that the FSF got its house in order.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Remove RMS from the GCC Steering Committee

[Mark Wielaard]

Hi Alexandre,

On Mon, 2021-03-29 at 23:08 -0300, Alexandre Oliva via Gcc wrote:
> I request that, if you found anything that holds up to your high
> standards of evidence-checking, you submit it to the voting members
> of the FSF, so that we can look into it and take appropriate action.

If you are still a (voting) board member of the FSF I request that you
and the rest of the remaining old (voting) board members resign. It is
not that you are a bad person. But it is time for a fresh start of the
FSF. The current board has ignored these issues for too long. And I
know you count RMS as your friend. That makes it naturally hard for you
to see the evidence presented unbiased. And that is not a character
flaw. We all want to stick with our friends, that is only natural. But
it might also mean that we just don't want to see, or explain away, bad
things people tell us what our friends do. In which case it is better
to simply step aside.

Various FSF board members already left, or promised to leave, to make
way for a new generation of leaders, please take inspiration from them,
they are also fiercely dedicated to Free Software and believe it is
time for a fresh start.

Thanks,

Mark

Re: Remove RMS from the GCC Steering Committee

[Didier Kryn]

Le 30/03/2021 à 11:47, Didier Kryn a écrit :

Sorry it wasn't Jonathan Wakely but Richard Biener

> Le 30/03/2021 à 10:25, Jonathan Wakely via Gcc a écrit :
>> I've been asking myself what benefit GCC gets from being linked to GNU and
>> all I can think of is the DNS records for gcc.gnu.org.
>     Can you remind the meaning of GCC. Isn't it "*GNU* Compiler
> Collection" ?
>
>     If this is still true, it doesn't seem appropriate to "break the
> communication channel" as you said in a previous mail. Or maybe you
> might suggest a new name for the project (~:
>
> --     Didier
>
>

Re: Remove RMS from the GCC Steering Committee

[Jonathan Wakely via Gcc]

On Tue, 30 Mar 2021 at 10:48, Didier Kryn wrote:
>
> Le 30/03/2021 à 10:25, Jonathan Wakely via Gcc a écrit :
> > I've been asking myself what benefit GCC gets from being linked to GNU and
> > all I can think of is the DNS records for gcc.gnu.org.
>
> Can you remind the meaning of GCC. Isn't it "*GNU* Compiler
> Collection" ?
>
> If this is still true, it doesn't seem appropriate to "break the
> communication channel" as you said in a previous mail. Or maybe you
> might suggest a new name for the project (~:

Sure, I have a few in mind.

Re: GCC Plugin introduction

[SAIFI]

On Mon, 29 Mar 2021, Gabriele Serra wrote:



I have written a very basic article on GCC Plugins (how to build a plugin 
from the ground, some info on APIs, and how to instrument code). The material 
is based on GCC 9. The code is fully documented and working.


https://gabrieleserra.ml/blog/2020-08-27-an-introduction-to-gcc-and-gccs-plugins.html



Gabriele thanks for sharing the detailed write up.

in the spirit of 'gcc-help', can you please share pointers as to how one can 
profile C++ code using GCC plugins ?

in your example you mention 'f1 ()'; i'd like to replace that with a instance 
of class 'X' created and then profile or instrument a member function.

Have you explored that ? any preliminary thoughts on how does one go about 
doing it ?



warm regards
Saifi.

Re: Remove RMS from the GCC Steering Committee

[Didier Kryn]

Le 30/03/2021 à 10:25, Jonathan Wakely via Gcc a écrit :
> I've been asking myself what benefit GCC gets from being linked to GNU and
> all I can think of is the DNS records for gcc.gnu.org.

    Can you remind the meaning of GCC. Isn't it "*GNU* Compiler
Collection" ?

    If this is still true, it doesn't seem appropriate to "break the
communication channel" as you said in a previous mail. Or maybe you
might suggest a new name for the project (~:

--     Didier

Re: Remove RMS from the GCC Steering Committee

[Mark Wielaard]

Hi Richard,

On Mon, 2021-03-29 at 08:18 -0400, Richard Kenner via Gcc wrote:
> I mostly want to stay out of this and will leave much of this discussion to
> others (though I have met RMS personally on a number of occaisions), but I
> want to mostly say that I agree with Jeff that it's important that this
> discussion stay civil.
> 
> I believe that to a large extent, the discussion here is reflective of a
> much larger discussion in society of to what extent, if at all, an entity
> associated with an person must or should take action based on things that
> that person does while not associated with that entity.

I respect that you want stay out of the discussion, but I think that to
present this as some larger societal issue which is somewhat academic
is wrong. People are talking about behavior that affects our
community. 

Even if it is "just" in some other community or speech addressed to
others it sents a message to those others to avoid the Free Software
community, GNU and GCC because it tolerates unkind behavior and
harassment.

And it does happen in our own community. There have been various
examples given in this thread alone. And I hate to point to others,
because I know these people, who worked closely with RMS, will get
harassed to "proof" their allegations or will be told that since they
were not physically attacked it doesn't count as harassment.

It is also at Free Software conferences (organized by the FSF):

https://wwahammy.com/on-safety-at-libreplanet/

   We write to you as former speakers and keynoters at LibrePlanet. We
   are concerned that the Code of Conduct for the event is not applied
   evenly, and in particular that Officers and Board Members seem to be
   exempt. This creates an intimidating and hostile environment for
   attendees, speakers and potential future participants who hear that
   unchecked harassment is allowed at the event.

It is also in the GNU project and at the FSF:

https://nitter.cc/paulnivin/status/1374499598853545986

   I worked at the FSF for 3 years and volunteered for over 6 years -
   that ended in 2004. I witnessed misogyny, sexual objectification,
   and abuse  carried out by RMS. I banded together with my coworkers,
   formed a union, negotiated a contract, and was elected shop steward.

https://nitter.cc/georgialyle/status/1374504389155508232

   I worked at the FSF from 2015-2018 & was shop steward for a while. I
   recall having a months (MONTHS) long conversation with ED John
   Sullivan about why racist & sexist 'hacker humor' from the 90s
   needed to be  removed from gnu.org. rms didn't get why it was
   harmful.

https://nitter.cc/baconandcoconut/status/1374803434344488967

   Checking in as another former staff person (2006 - 2010) who started
   the Women in Free Software Caucus and maintained a GNU project for
   over a decade. I tried "calling in" or educating for years, but the
   community RMS inspires is sexist, completely toxic and impervious to
   change.

This is not just incidents, it is a pattern where RMS is not facing any
consequences because he feels our common rules of decency and
respecting each other don't apply to him.

What is even worse is that when people try to discuss such issues he
encourages his cult of personality to attack those who try to tell
their stories (as we are already seeing on this list by comments from
people not even associated with GNU or GCC). I earlier talked about
when we had an open discussion about GNU governance issues and a female
GCC hacker spoke up. Once he had arranged "new moderators" for the
mailing-list his exact words were:

   The new moderators have now allowed people to defend the GNU Project
   and to defend me personally.  If you would like to do these things,
   please do not hold back.

The resulting torrent of misogynistic and racist posts were truly
shocking. He turns a community into a toxic and hostile place when
people question his authority by implying such people must be the enemy
of Free Software or GNU and that they must be stopped.

Cheers,

Mark

Re: Remove RMS from the GCC Steering Committee

[Alfred M. Szmidt via Gcc]

A good reason why Richard should be on the SC is to that he does
demonstrates the values of the GNU project, that of the free software
movement and the FSF.  GCC is a important project, and having the head
of the GNU project involved -- even if mostly uninvolved in daily
topics, is a ultimately a good thing.

Question about points-to analysis, global variables, IPA, and field sensitivity

[Erick Ochoa via Gcc]

Hi,

I am looking at the points-to analysis in GCC and I found the
following comment in tree-ssa-structalias.c:

  /* Collect field information.  */
  if (use_field_sensitive
  && var_can_have_subvars (decl)
  /* ???  Force us to not use subfields for globals in IPA mode.
 Else we'd have to parse arbitrary initializers.  */
  && !(in_ipa_mode
   && is_global_var (decl)))


>From what I understand here the points-to analysis is explicitly not
using field sensitivity for global variables when in IPA. I am
wondering,
0) Is "initializers" here talking about brace initializers? Or are
"initializers" a little bit more abstract and refer to anything that
can initialize a field? Like struct->field = function()?
1) How much work would it be to parse initializers?
2) How would global structs which are not initialized using
initializers be handled? Would all fields get assigned NULL at the
global variable level, but then as other fields get assigned we just
create new constraints with the correct offsets?

Thanks!

Re: Remove RMS from the GCC Steering Committee

[Jonathan Wakely via Gcc]

On Mon, 29 Mar 2021, 11:13 Richard Biener via Gcc,  wrote:

>
> I do think that the request at hand puts specific pressure on the SC
> members that
> is unwarranted - you ask for them to respond but they are likely powerless
> as to
> the actual request.


I don't think they are powerless, but it doesn't necessarily matter.


  In fact were I on the SC I would suggest to all
> of my fellow SC
> members to resign and re-organize how GCC wants to be represented.  That
> would
> effectively break the communication channel between GCC and the GNU
> Project [the FSF]
> but at this point it might be the important signal to send.
>


I've been asking myself what benefit GCC gets from being linked to GNU and
all I can think of is the DNS records for gcc.gnu.org.

The downside is the link is that a vocal minority in the GNU community make
it a toxic and hostile place. Anybody who criticises RMS or questions his
authority is treated as an enemy who must be stopped. Ironically, those
rabid supporters of the cult of GNU might be what destroys the FSF as a
meaningful force for good.

I no longer see value in assigning my copyright to the FSF.

>

Re: Remove RMS from the GCC Steering Committee

[Jonathan Wakely via Gcc]

On Tue, 30 Mar 2021, 02:34 Christopher Dimech via Gcc, 
wrote:

>
>
>
>
> Insofar as Stallman is the foundation of all authority, He exercises that
> foundation because He is the founder of His own work.  He is the foundation
> upon which all other authority stands or falls. We use the term foundation
> with respect to the imagery of a building - houses and commercial buildings
> are erected upon a foundation.
>


Read the Four Freedoms at gnu.org. Nothing in the definitions of free
software requires us to obey the founder. You are a cultist who understands
nothing about free software and contributes nothing to it either.

Re: Question about reading LTO function summaries

[Erick Ochoa via Gcc]

Hello,

just trying again to increase visibility of this question. Many thanks
in advance!


On Fri, 26 Mar 2021 at 13:49, Erick Ochoa  wrote:
>
> 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: Remove RMS from the GCC Steering Committee

[Jonathan Wakely via Gcc]

On Tue, 30 Mar 2021, 08:48 mfriley via Gcc,  wrote:

> For the record, I am not a GNU contributor--I am only chiming in as a
>
> FOSS sympathizer. I will not pretend to be unbiased, or to have any sort
>
> of personal experience with, or extensive knowledge of, RMS's behavior
>
> apropos of GCC, or any other GNU project.
>
> > (For the last point, I don't think the free software movement needs a
> > single leader; it needs many people advocating free software, and
> > discussing issues related to free software, from diverse perspectives.
> > RMS's ideas that form the foundation of the free software movement are
> > still of fundamental importance today.  But other people can now build
> > better on those ideas in today's context.)
>
> Perhaps it does not need a *formal* leader, but I am strongly inclined
>
> to believe that guidance in some form or another does matter, and I think
>
> a lot of RMS's supporters (vocal or otherwise) feel similarly. Some have
>
> claimed that RMS has only repelled people from free software, and yet,
>
> in spite of the threat of cancellation, many more people have signed the
>
> letter in support of RMS than the one demanding his removal.
>

We're talking here about whether he should be on the GCC steering
committee, not the FSF board. The GCC community should decide, not
signatories to petitions.



> "Leaderless" movements are always feckless because they lack direction.
>

We're not talking about a movement, were talking about the GCC project. We
have leaders, and a steering committee. RMS does not contribute usefully to
that steering committee.



> They start with good intentions, but when anyone can find a soapbox and
>
> [...]
>

This is not directed at any reasoned criticism of RMS. I doubt that
>
> everyone who wants him removed is so bluntly insane. If GNU and the
>
> FSF see it fit, that is entirely their prerogative. But it will do
>
> absolutely nothing to satisfy these people, because they are acting
>
> in bad faith. As others have suggested, I fear that it will only make
>
> things worse.


Totally irrelevant to his position on the GCC steering committee. If you
want to discuss the broader issues, please do so elsewhere.

Re: Remove RMS from the GCC Steering Committee

[mfriley via Gcc]

For the record, I am not a GNU contributor--I am only chiming in as a

FOSS sympathizer. I will not pretend to be unbiased, or to have any sort

of personal experience with, or extensive knowledge of, RMS's behavior

apropos of GCC, or any other GNU project.

> (For the last point, I don't think the free software movement needs a
> single leader; it needs many people advocating free software, and
> discussing issues related to free software, from diverse perspectives.
> RMS's ideas that form the foundation of the free software movement are
> still of fundamental importance today.  But other people can now build
> better on those ideas in today's context.)

Perhaps it does not need a *formal* leader, but I am strongly inclined

to believe that guidance in some form or another does matter, and I think

a lot of RMS's supporters (vocal or otherwise) feel similarly. Some have

claimed that RMS has only repelled people from free software, and yet,

in spite of the threat of cancellation, many more people have signed the

letter in support of RMS than the one demanding his removal.

"Leaderless" movements are always feckless because they lack direction.

They start with good intentions, but when anyone can find a soapbox and

claim to speak for everyone else, those good intentions are inevitably

thrown under the bus by people seeking personal clout and pursuing their

own agendas.

Say what you will about RMS, but his unwavering laser focus on free

software advocacy shows a level of integrity that is hard not to respect.

This matters more than ever, because as difficult as it is to address

without sounding like a bitter right-wing hack, cancel culture is real,

and it will come for absolutely *anyone*, regardless of your personal

views. I doubt the majority of people signing the Github open letter

have judged the case against him for themselves, or even care one way

or another: people cancel because they can. Social media causes brain

damage, and this is how that brain damage tends to manifest.

There are people developing scripts and browser extensions to

automatically label or block anyone who signed the open letter in

defense of RMS. Just a few examples:

https://github.com/travisbrown/octocrabby
https://github.com/aaronbassett/rm
s-letter-sigs
https://github.com/sticks-stuff/highlight-RMS-supporters

There are also reports of people whose emails are visible on Github

receiving anonymous demands to remove their signatures from the

support letter, on threat of being reported to their employers.

People like this cannot be reasoned with, nor do they want to listen.

If given the chance, they will style themselves as representative of

FOSS, despite clear evidence that this is not the case. They thrive

on interpersonal conflict, so their input is virtually useless in

addressing any genuine issues plaguing GNU or the FOSS community as

a whole.

This is not directed at any reasoned criticism of RMS. I doubt that

everyone who wants him removed is so bluntly insane. If GNU and the

FSF see it fit, that is entirely their prerogative. But it will do

absolutely nothing to satisfy these people, because they are acting

in bad faith. As others have suggested, I fear that it will only make

things worse.