date:20210331

On Wed, 31 Mar 2021 at 12:36, Mark Wielaard wrote:
> Again, it isn't about this one or two incidents. I am sure someone can
> find a way to explained it away by saying people simply misunderstood
> his intentions or that no law was broken. But it is about a pattern of
> behavior that shows RMS creates a misogynist, racist and transphobic
> environment by (hopefully unknowingly) setting the example that others
> will then follow and amplify.

Probably unintentionally, but he has allowed the GNU Project to become
a nasty cult of personality. The FSF seems to be imploding (with mass
resignations in the past week). I don't think GCC benefits from being
associated with either of them.

Is there any incident where FSF being the copyright holder for GCC has
made a difference? Are there any GPL violations involving GCC code
that were resolved only because all copyright resides with a single
entity, that couldn't have been resolved on behalf of individual
copyright holders?

Are we still worried about BigCorp trying to do a proprietary fork of
GCC? Because BigCorp, OtherCorp etc. have shown that they would prefer
to create a new toolchain from scratch rather than use GNU code. And
if EvilCorp want to make their own proprietary compiler with secret
optimizations, they'll just use LLVM instead of bothering to violate
the GPL. The work done to make it impossible to steal GCC code was a
success: nobody is even interested in stealing it now. There is an
easier option.

Can we break our (already weak) ties to GNU?

Re: Remove RMS from the GCC Steering Committee

On Wed, 31 Mar 2021 at 13:29, Richard Biener wrote:
> And just to repeat - all the GCC governance structure (the "SC") represents
> all of the same non-openess as the FSF governance structure (because
> the "SC" is in fact appointed by the Chief GNUisance "or his delegates").

The SC was appointed by the egcs community. They were then blessed as
"the official GNU maintainer" of the GNU project when egcs replaced
gcc as "the compiler for the GNU system", but we don't have to *be* a
GNU project. GNU cannot remove the SC, if they tried we'd just say
we're independent of GNU and then they don't get to have a say.

So no, the SC is not appointed by RMS, except in the same way that the
UK government is "chosen" by the Queen. By convention she appoints a
Prime Minister (the SC) and asks the PM to form a government (the GCC
devs). But in reality her "choice" is the party that won the election.
She is not allowed to choose for herself, or there would be ...
problems. If RMS or GNU tried to "choose" a new maintainer or replace
the SC, there would be ... problems.

Re: Remove RMS from the GCC Steering Committee

On Wed, Mar 31, 2021 at 8:28 AM Richard Biener via Gcc  wrote:
>
> On Wed, Mar 31, 2021 at 1:36 PM Mark Wielaard  wrote:
> >
> > You are referencing the recent open letter which isn't really what
> > people are discussing here. Although many probably sympathize with
> > calling for the removal of the entire Board of the Free Software
> > Foundation and calling for Richard M. Stallman to be removed from all
> > leadership positions, including the GNU Project
> >
> > You can disagree with the specific way that was worded and still come
> > to the same conclusion. See for example https://www.arp242.net/rms.html
>
> Ah, this one is _very_ well written and captures my thoughts when
> writing my response to Nathan (but not willing to spend so much time
> on this to coherently formulate what I was thinking).
>
> And just to repeat - all the GCC governance structure (the "SC") represents
> all of the same non-openess as the FSF governance structure (because
> the "SC" is in fact appointed by the Chief GNUisance "or his delegates").

Richard historically has approved nominees to the GCC SC because the
GNU Project considers the SC the official "maintainers" of GCC, but he
has not nominated or suggested any of the members.  I don't remember
him rejecting a proposed nominee.  And many major contributors to GCC
have not wished to be members of the GCC SC whose major purpose is to
be a buffer between the GCC Community and the Free Software
Foundation.

Has the GCC SC micro-managed you or prevented you from doing anything
as Global Reviewer and Release Manager?  Not that I'm aware of.

Has the GCC SC blocked any new port or major feature?  Not that I'm aware of.

Has the GCC SC blocked any qualified maintainer nominations?  Not that
I'm aware of.

Has the GCC SC instructed GCC developers on which features to work?  No.

Has the GCC SC inserted itself or voted on any disagreements?  No.

The reality is that the governance of GCC is extremely open because
it's performed by the developers in the community, not the GCC SC.
And GCC is much less bureaucratic than other, large Open Source
projects.  It doesn't have multiple committees and SIGs.  Everything
is worked out among the developers.  Projects are started by
developers who take the initiative to start a project.

Be careful what you wish for because it may be much worse than the
freedom that you currently enjoy.

Thanks, David

Re: Interested In extend the static analysis pass

Just one comment ...

On Wed, 31 Mar 2021 at 12:30, Gagandeep Bhatia via Gcc  wrote:
> Right now the code is in GCC’s master branch for GCC 10

N.B. the master branch is for GCC 11. Make sure you are using that,
not the gcc-10 branch, as there are lots of improvements to the static
analysis code.

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread Richard Biener via Gcc

On Wed, Mar 31, 2021 at 2:59 PM David Edelsohn  wrote:
>
> On Wed, Mar 31, 2021 at 8:28 AM Richard Biener via Gcc  
> wrote:
> >
> > On Wed, Mar 31, 2021 at 1:36 PM Mark Wielaard  wrote:
> > >
> > > You are referencing the recent open letter which isn't really what
> > > people are discussing here. Although many probably sympathize with
> > > calling for the removal of the entire Board of the Free Software
> > > Foundation and calling for Richard M. Stallman to be removed from all
> > > leadership positions, including the GNU Project
> > >
> > > You can disagree with the specific way that was worded and still come
> > > to the same conclusion. See for example https://www.arp242.net/rms.html
> >
> > Ah, this one is _very_ well written and captures my thoughts when
> > writing my response to Nathan (but not willing to spend so much time
> > on this to coherently formulate what I was thinking).
> >
> > And just to repeat - all the GCC governance structure (the "SC") represents
> > all of the same non-openess as the FSF governance structure (because
> > the "SC" is in fact appointed by the Chief GNUisance "or his delegates").
>
> Richard historically has approved nominees to the GCC SC because the
> GNU Project considers the SC the official "maintainers" of GCC, but he
> has not nominated or suggested any of the members.  I don't remember
> him rejecting a proposed nominee.  And many major contributors to GCC
> have not wished to be members of the GCC SC whose major purpose is to
> be a buffer between the GCC Community and the Free Software
> Foundation.
>
> Has the GCC SC micro-managed you or prevented you from doing anything
> as Global Reviewer and Release Manager?  Not that I'm aware of.
>
> Has the GCC SC blocked any new port or major feature?  Not that I'm aware of.
>
> Has the GCC SC blocked any qualified maintainer nominations?  Not that
> I'm aware of.
>
> Has the GCC SC instructed GCC developers on which features to work?  No.
>
> Has the GCC SC inserted itself or voted on any disagreements?  No.

That's all true.  It's still true that since GCC is a GNU project, formally
its maintainers are appointed by RMS (I've just read the official governance
structure document!).  It's also true that the SC is only indirectly reachable,
that we didn't vote on our representatives, or that there's no traces of
its work (assuming it does any).  Just to point to the pieces that
make it "not open".

> The reality is that the governance of GCC is extremely open because
> it's performed by the developers in the community, not the GCC SC.
> And GCC is much less bureaucratic than other, large Open Source
> projects.  It doesn't have multiple committees and SIGs.  Everything
> is worked out among the developers.  Projects are started by
> developers who take the initiative to start a project.
>
> Be careful what you wish for because it may be much worse than the
> freedom that you currently enjoy.

I'm actually enjoying not needing to interact with RMS or the FSF
and indeed the SC appears to handle things well.  But since people
are throwing in ideas to disassociate GCC from GNU I wanted to
point out that GCC needs to think of its own governance structure.

Richard.

>
> Thanks, David

Re: Remove RMS from the GCC Steering Committee

Hi Martin,

On Wed, 31 Mar 2021 10:53:20 +0200 Martin Jambor wrote:

> Dear Giacomo,
> 
> On Tue, Mar 30 2021, Giacomo Tesio wrote:
> > On Tue, 30 Mar 2021 18:50:52 +0200 Martin Jambor wrote:
> >  
> >> 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.  
> >
> > Martin, what you imply here, is an insult I do not deserve.  
> 
> I am sorry.

No problem, apology accepted! ;-)

> I wanted to underline that the questions discussed here
> are not cultural or somehow defined geographically.

But it IS cultural (and thus storical and geographical): we interpret
any datum according to our existing knowledge and perspectives.

It's happening even now: I write these words trying to express what I
think in my mind and in the very instant you are reading them, you
interpret them according to your current positions and beliefs.

> > But in Italy we have a legal principle called "Presumption of
> > innocence".  
> 
> Nevertheless, I am convinced that all the many accusations are clear,
> consistent and most of them are beyond any doubt (a lot of it is on
> RMS's own blog).

If you consider software as a form of human expression and Free
Software as an obvious extension of Free Speech (that is a complex
human right, probably the most complex as it has to be balanced BY LAW
with all the others, privacy and personal safety above all), I think
you can see how controversial positions on a personal blogs cannot
constitute a valid argument against RMS.

If you marginalize people with controversial (but legal) positions you
select people that only do vague statements that everybody can
interpret as they like.

Ultimately, you select people whose real opinions you do not really
know and that only pretend to defend "Free Software as in Free Speech" 
because they do not practice Free Speech at all.

> They easily clear the bar for legitimate reasons why
> he should not be an official representative of GCC.
>
> I do not understand people which keep doubting the "evidence" or
> describe it as hearsay, the only explanation I can think of is that
> they simply do not wish to not accept the facts.  If you are certain
> that this is not your case (no "proof" or explanation necessary) then
> please accept my apologies.

Again, apologies accepted. :-)

Giacomo

Re: Remove RMS from the GCC Steering Committee

Hi Mark,

I'm a bit in a hurry and do not really want to focus on what happened
in Harvey: to my eyes that story just show you cannot trust people just
because they are nice and well known "open source" contributors, or
because they work for big multinational that "do no evil" or even
join the Good Guys (TM) of Software Freedom Conservancy.

But let me clarify 

On Wed, 31 Mar 2021 13:34:17 +0200 Mark Wielaard wrote:

> I looked a bit at that issue you filed and how they handled your
> request to remove your code from the project. And I must say I don't
> really understand what you believe they did wrong, they seemed to have
> acknowledged and corrected their mistake and then removed all the code
> you wanted to have removed. 

I asked them to `git revert` my changes referencing the issue, so that
the code I reused in my own fork of Plan 9 was safe that nobody could
claim copyright of my work after, say, a change in the version control
system adopted by the project.

Instead they did a `git rebase` over which, I was pretty surprised
actually, they "accidentaly" squashed some of my own commits verbatim
(but without my name) in incredibly large commits.
And you know, they had to git push -f such rebase, breaking all the
existing github forks (while the `git revert` approach would not have
caused any issue to anybody)

> There is some disagreement over whether a
> mass change of function declarations is copyrightable or not.

And implementations. And kernel changes that took a couple of days to
get right (Harvey kernel was pretty unstable back then). And more I did
not remember but I noticed back then: 

> But I happen to agree with them that if there is only one way to do
> it, then having someone else do the same transformation is a correct
> way to resolve this.

Sure!

But first, there were several different ways to do that (several
equivalent typedefs were already in place in u.h, without even
mentioning macros and so on), and more importantly if you actually
redo the same work in the same way because there is a single way
to do that, you do in a dedicated commit with an author that takes
the clear responsibility for change.

Instead my work (or a totally, byte-for-byte equivalent, one) got
squashed into gigantic commits that include several very large commits
of several authors (all mentioned in the commit message... but me).

> To make this copyright issue somewhat relevant to GCC. GCC doesn't
> currently contain individual copyright statements and most of the code
> is currently assigned to the FSF. So the above mistake won't happen
> when contributing to GCC, but mostly because of the technicality that
> you sign away your copyright up front.

Oh sorry, I wasn't clear enough about this.

I'm SURE that this specific issue would not happen on GCC.
Nor on Linux. Nor in several other Free Software and Open Source
communities.

But I think you are missing the valuable lesson that the Harvey team
(some of which actually signed the rms-open-letter) tauht me: I didn't
expected ANYTHING like this to happen. And I didn't expect SFC to not
expell a project doing something like this.

I trusted them both. All of them.

So ultimately I do not expect this specific issue to occur in a
hypothetical GCC lead by a Stallman-less Steering Comittee.

But I DO expect that, in the long run, a Stallman-less Steering
Comittee might do something not aligned with the long-term
interests of Free Software, abusing my trust again.

Maybe not you. Maybe not the CURRENT Steering Committee.

But people, groups and incentives changes.
Stallman does not.

Giacomo

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread Florian Weimer

* David Edelsohn via Gcc:

> Has the GCC SC blocked any new port or major feature?  Not that I'm aware of.

What about the plugin framework?  The libgcc licensing change would
not have happened naturally.  Someone had to step in and delay the
plugin framework feature until the licensing changes were in place.

Re: Remove RMS from the GCC Steering Committee

On Wed, 31 Mar 2021 at 14:30, Giacomo Tesio wrote:
> But people, groups and incentives changes.
> Stallman does not.

Well, he's not immortal. Are you really suggesting that his crowning
achievement (the free software movement and copyleft) is actually not
sustainable, and only works if he's watching?

Re: Interested In extend the static analysis pass

2021-03-31 Thread David Malcolm via Gcc

On Wed, 2021-03-31 at 16:59 +0530, Gagandeep Bhatia via Gcc wrote:
> Hey Team GNU Compiler, I'm Gagandeep Bhatia, currently pursuing the
> 2nd year at Christ University, Bangalore, India. You can reach me at
> gagandeepbhatia2...@gmail.com 
> or +919466935025.
> I went through your upcoming projects on Google Summer of Code, your
> idea on  extend the static analysis pass is really impressive. 

Thank you.

> Right now the code is in GCC’s master branch for GCC 10 and can be
> tried out on Compiler Explorer, aka godbolt.org. It works well for
> small and medium-sized examples, but there are bugs that mean it’s
> not ready for production use. I’m working hard on fixing things in
> the hope that the feature will be meaningfully usable for C code.

You seem to have simply copied and pasted the above three sentences
from my March 2020 blog post on the analyzer.

As Jonathan notes, the code has substantially changed since the GCC 10
release.

>  I truly want to become part of this project for better mutual
> achievement, in the past, I have done a few projects, which will help
> me to contribute my best in this project.
> It will be really kind if you can share some more details about your
> project, so I learn more about your project.
> with regards.

There are some more concrete ideas about the analyzer on the wiki page
here:
  https://gcc.gnu.org/wiki/SummerOfCode
and there is a link there to the wiki page about the analyzer which has
lots more information.

You may want to read the archives of this mailing list, where some of
those ideas are discussed in more detail with other prospective GSoC
students.

Hope this is constructive
Dave

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread Christopher Dimech via Gcc

> Sent: Wednesday, March 31, 2021 at 11:34 PM
> From: "Mark Wielaard" 
> To: "Giacomo Tesio" 
> Cc: "GCC Development" , "Nathan Sidwell" 
> Subject: Re: Remove RMS from the GCC Steering Committee
>
> Hi Giacomo,
> 
> On Tue, Mar 30, 2021 at 11:28:49PM +0200, Giacomo Tesio wrote:
> > 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.
> 
> Yes, I am pretty sure the perspective changes for people who have had
> longer, or more direct, exposure to Richard, while working on GNU or
> GCC over the years.
>  
> > 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 ).
> 
> So this for example depends on whether you believe this is the one and
> only incident that can easily be explained away or if it is a decades
> long pattern of behavior where people finally had enough. See for
> example this blog that links and lists various other past events
> https://www.harihareswara.net/sumana/2021/03/26/0

In 2017, Marianne Corvellec was discussing GNU Philosophy and his
elaborations were valid.  Having worked with both, I agree with   
Richard stance.

Regarding, the Glibc Controversy, the comment was a criticism about
the United States Federal Censorship Regulations that were being
proposed.  This was the result of Roe vs. Wade that affirmed a woman’s
constitutional right to an abortion.  Opponents of the ruling have
steadfastly refused to accept it, and have tried to overturn it altogether.

I disagree with the conclusions resulting from Roe vs. Wade.  Doing what
you want does not mean you can act at any level of irresponsibility.  People
have to understand this - there are many documented cases where families 
have killed their own daughters.  I am particularly saying this because it
happens more to girls.  Because the parents believe that after they are
their children and if things don't turn out the way they wanted, they 
can kill them.

I personally disagree with Stallman regarding the joke.  But, I do not
fall within the camp that worked to remove it.

As for the "safe spaces" phase, this is about eliminating anything and
everything that could emotionally troubling students. This assumes a high
degree of fragility among western students.  I work as a journalist and
have had colleagues blown to smithereens - foot there, bits of brain there.
I wonder how many of you bitches, have ever been shot or had a bomb blown
up your ass.   

After scrutinising many of the presented arguments for removing Richard
Stallman from public and working life.  

I have to conclude that the drive is another ridiculous and sad story of a 
smear campaign in the media and on social networks.  This includes the big
companies that do a lot of high level work for the government and for big
corporations - e.g. Red Hat subsidiary of IBM, Facebook.  Digging into minor
and fabricated events to somehow attack his credibility.

Peaple have lost the narrative.  I therefore deplore the offensive against 
Richard Stallman and those who support him.  I see a huge opportunity for
journalists to dig into the real story.

> You are referencing the recent open letter which isn't really what
> people are discussing here. Although many probably sympathize with
> calling for the removal of the entire Board of the Free Software
> Foundation and calling for Richard M. Stallman to be removed from all
> leadership positions, including the GNU Project
> 
> You can disagree with the specific way that was worded and still come
> to the same conclusion. See for example https://www.arp242.net/rms.html
> 
> > 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...

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread Paul Koning via Gcc

I may have lost it in the enormous flood of text, but I want to ask these 
general questions.

1. Is there a published code of conduct for GCC community members, possibly 
different ones depending on which level of the organization you're in?

2. Is there a formal process for receiving claims of infraction of this code, 
and for adjudicating such claims?

paul

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread Joel Sherrill

On Wed, Mar 31, 2021 at 9:23 AM Paul Koning via Gcc  wrote:

> I may have lost it in the enormous flood of text, but I want to ask these
> general questions.
>
> 1. Is there a published code of conduct for GCC community members,
> possibly different ones depending on which level of the organization you're
> in?
>

As a GNU project, this should apply.:

https://www.gnu.org/philosophy/kind-communication.en.html


> 2. Is there a formal process for receiving claims of infraction of this
> code, and for adjudicating such claims?
>

I admit to not looking for one but does any FLOSS organization have this?

--joel


>
> paul
>
>

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread Christopher Dimech via Gcc



> Sent: Thursday, April 01, 2021 at 1:28 AM
> From: "Giacomo Tesio" 
> To: "Mark Wielaard" 
> Cc: "GCC Development" , "Nathan Sidwell" 
> Subject: Re: Remove RMS from the GCC Steering Committee
>
> Hi Mark,
>
> I'm a bit in a hurry and do not really want to focus on what happened
> in Harvey: to my eyes that story just show you cannot trust people just
> because they are nice and well known "open source" contributors, or
> because they work for big multinational that "do no evil" or even
> join the Good Guys (TM) of Software Freedom Conservancy.
>
> But let me clarify
>
> On Wed, 31 Mar 2021 13:34:17 +0200 Mark Wielaard wrote:
>
> > I looked a bit at that issue you filed and how they handled your
> > request to remove your code from the project. And I must say I don't
> > really understand what you believe they did wrong, they seemed to have
> > acknowledged and corrected their mistake and then removed all the code
> > you wanted to have removed.
>
> I asked them to `git revert` my changes referencing the issue, so that
> the code I reused in my own fork of Plan 9 was safe that nobody could
> claim copyright of my work after, say, a change in the version control
> system adopted by the project.
>
> Instead they did a `git rebase` over which, I was pretty surprised
> actually, they "accidentaly" squashed some of my own commits verbatim
> (but without my name) in incredibly large commits.
> And you know, they had to git push -f such rebase, breaking all the
> existing github forks (while the `git revert` approach would not have
> caused any issue to anybody)
>
> > There is some disagreement over whether a
> > mass change of function declarations is copyrightable or not.
>
> And implementations. And kernel changes that took a couple of days to
> get right (Harvey kernel was pretty unstable back then). And more I did
> not remember but I noticed back then:
>
>
> > But I happen to agree with them that if there is only one way to do
> > it, then having someone else do the same transformation is a correct
> > way to resolve this.
>
> Sure!
>
> But first, there were several different ways to do that (several
> equivalent typedefs were already in place in u.h, without even
> mentioning macros and so on), and more importantly if you actually
> redo the same work in the same way because there is a single way
> to do that, you do in a dedicated commit with an author that takes
> the clear responsibility for change.
>
> Instead my work (or a totally, byte-for-byte equivalent, one) got
> squashed into gigantic commits that include several very large commits
> of several authors (all mentioned in the commit message... but me).
>
>
> > To make this copyright issue somewhat relevant to GCC. GCC doesn't
> > currently contain individual copyright statements and most of the code
> > is currently assigned to the FSF. So the above mistake won't happen
> > when contributing to GCC, but mostly because of the technicality that
> > you sign away your copyright up front.
>
> Oh sorry, I wasn't clear enough about this.
>
> I'm SURE that this specific issue would not happen on GCC.
> Nor on Linux. Nor in several other Free Software and Open Source
> communities.
>
> But I think you are missing the valuable lesson that the Harvey team
> (some of which actually signed the rms-open-letter) tauht me: I didn't
> expected ANYTHING like this to happen. And I didn't expect SFC to not
> expell a project doing something like this.
>
> I trusted them both. All of them.
>
>
> So ultimately I do not expect this specific issue to occur in a
> hypothetical GCC lead by a Stallman-less Steering Comittee.
>
> But I DO expect that, in the long run, a Stallman-less Steering
> Comittee might do something not aligned with the long-term
> interests of Free Software, abusing my trust again.
>
> Maybe not you. Maybe not the CURRENT Steering Committee.
>
> But people, groups and incentives changes.
> Stallman does not.

It is likely that anothep person or group will evolve, which
although not Stallman-Like, work within the free software idea.

After Newton, there were other illustrious people.  Does not mean
everything stops forever after the demise of Richard.

> Giacomo
>

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread David Malcolm via Gcc

On Wed, 2021-03-31 at 16:18 +0200, Christopher Dimech via Gcc wrote:

[...snip...]

> As for the "safe spaces" phase, this is about eliminating anything
> and
> everything that could emotionally troubling students. This assumes a
> high
> degree of fragility among western students.  I work as a journalist
> and
> have had colleagues blown to smithereens - foot there, bits of brain
> there.
> I wonder how many of you bitches, have ever been shot or had a bomb
> blown
> up your ass.   

I've been attempting to decide if you're merely trolling us, or if you
genuinely believe the stuff you've been posting to this list.

With your latest missive I'm leaning to the former interpretation, but
if the latter, may I humbly suggest that referring to us as "bitches"
might not be the best way to win people over, and that it's not normal
to have to work in a literal war zone, and that most reasonable people
do not want to work in a figurative war zone.

[...snip...]

Hope this is constructive
Dave

(my opinions only, not my employer's)

gnu.org

2021-03-31 Thread Ellie Smith via Gcc

Hello Jason,

Do you have any interest in the domain “*JavaSource.com*”?

Please let me know.

Regards,
Ellie
+1 (385) 999-3081

Re: Remove RMS from the GCC Steering Committee

On Wed, Mar 31, 2021 at 9:46 AM Florian Weimer  wrote:
>
> * David Edelsohn via Gcc:
>
> > Has the GCC SC blocked any new port or major feature?  Not that I'm aware 
> > of.
>
> What about the plugin framework?  The libgcc licensing change would
> not have happened naturally.  Someone had to step in and delay the
> plugin framework feature until the licensing changes were in place.

I wrote blocked, not delayed.  In order to continue the alignment of
GCC with the FSF, the GCC SC agreed to delay deployment of LTO and
Plugins until a license to allow such features could be implemented.
We didn't feel that a rupture with the FSF would be beneficial.

Because I foresaw the need for such features and the need for the
license to accommodate it, I had been designing and negotiating with
the FSF for an appropriate license exception for years before LTO and
Plugins were proposed.  Richard Stallman, Richard Fontana, Brad Kuhn
and I all worked to resolve the issue.

I and other members of the GCC SC have worked diligently behind the
scenes to ensure that GCC and GNU Toolchain development can proceed as
smoothly and unhindered as possible.  We have prevented or resolved
many conflicts and issues without disturbing the broader community and
allow the community to focus on its important tasks and great progress
for the toolchain itself. I, at least, view that as my role as a
member of the GCC SC.  It's like a good manager: regardless of the
openness, hopefully the GCC community feels that the GCC SC "has their
back", manages the politics, and removes real or potential roadblocks
so that the software engineer can focus on being productive.

Thanks, David

Having trouble getting my school to sign the copyright disclaimer

2021-03-31 Thread PKU via Gcc

Hello,

I’m trying to get my school to sign the copyright disclaimer. Unfortunately the 
officials are reluctant to do that. Can anyone suggest what to do next?

They claim that university owns copyright to my code if I wrote it for a 
school-related research project. However, since I’m an undergraduate and thus 
do not have an advisor, nobody in the campus knows me well enough to prove that 
it’s not the case. They do promise(verbally) that they won’t interfere if I’m 
working on my own.

Is there a way to get around that? Any suggestion is appreciated.

Thanks

Yizhe

Re: Having trouble getting my school to sign the copyright disclaimer

On Wed, Mar 31, 2021 at 11:28 AM PKU via Gcc  wrote:
>
> Hello,
>
> I’m trying to get my school to sign the copyright disclaimer. Unfortunately 
> the officials are reluctant to do that. Can anyone suggest what to do next?
>
> They claim that university owns copyright to my code if I wrote it for a 
> school-related research project. However, since I’m an undergraduate and thus 
> do not have an advisor, nobody in the campus knows me well enough to prove 
> that it’s not the case. They do promise(verbally) that they won’t interfere 
> if I’m working on my own.
>
> Is there a way to get around that? Any suggestion is appreciated.

Will the university sign a copyright assignment?

Also, you seem to be in China.  It's the people's code.  Ask the
university why they are claiming ownership to something that belongs
to the people.

Thanks, David

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread Richard Biener via Gcc

On March 31, 2021 5:23:09 PM GMT+02:00, David Edelsohn  
wrote:
>On Wed, Mar 31, 2021 at 9:46 AM Florian Weimer 
>wrote:
>>
>> * David Edelsohn via Gcc:
>>
>> > Has the GCC SC blocked any new port or major feature?  Not that I'm
>aware of.
>>
>> What about the plugin framework?  The libgcc licensing change would
>> not have happened naturally.  Someone had to step in and delay the
>> plugin framework feature until the licensing changes were in place.
>
>I wrote blocked, not delayed.  In order to continue the alignment of
>GCC with the FSF, the GCC SC agreed to delay deployment of LTO and
>Plugins until a license to allow such features could be implemented.
>We didn't feel that a rupture with the FSF would be beneficial.
>
>Because I foresaw the need for such features and the need for the
>license to accommodate it, I had been designing and negotiating with
>the FSF for an appropriate license exception for years before LTO and
>Plugins were proposed.  Richard Stallman, Richard Fontana, Brad Kuhn
>and I all worked to resolve the issue.
>
>I and other members of the GCC SC have worked diligently behind the
>scenes to ensure that GCC and GNU Toolchain development can proceed as
>smoothly and unhindered as possible.  We have prevented or resolved
>many conflicts and issues without disturbing the broader community and
>allow the community to focus on its important tasks and great progress
>for the toolchain itself. I, at least, view that as my role as a
>member of the GCC SC.  It's like a good manager: regardless of the
>openness, hopefully the GCC community feels that the GCC SC "has their
>back", manages the politics, and removes real or potential roadblocks
>so that the software engineer can focus on being productive.

Indeed. I believe without the SC doing this GCC would either have disassociated 
itself from GNU (again) or be of marginal importance today (without those 
features). 

Richard. 

>
>Thanks, David

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread Ian Lance Taylor via Gcc

On Wed, Mar 31, 2021 at 5:28 AM Richard Biener via Gcc  wrote:
>
> And just to repeat - all the GCC governance structure (the "SC") represents
> all of the same non-openess as the FSF governance structure (because
> the "SC" is in fact appointed by the Chief GNUisance "or his delegates").

While that is true in a formal sense it's not true in a practical
sense.  In practice the steering committee appoints its own members.

That said I think it would be entirely reasonable to use a different
structure.  I just don't know what it would be.  The steering
committee doesn't really take very many actions, which is as it should
be.  The main and by and large only action is appointing, or perhaps a
better word would be anointing, maintainers: the people listed in the
MAINTAINERS file.

Thoughts on changing the steering committee system should probably be
on a separate thread from the RMS discussion.

Ian

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread Christopher Dimech via Gcc

> Sent: Thursday, April 01, 2021 at 2:56 AM
> From: "David Malcolm" 
> To: "Christopher Dimech" , "Mark Wielaard" 
> Cc: "GCC Development" , "Nathan Sidwell" 
> Subject: Re: Remove RMS from the GCC Steering Committee
>
> On Wed, 2021-03-31 at 16:18 +0200, Christopher Dimech via Gcc wrote:
> 
> [...snip...]
> 
> > As for the "safe spaces" phase, this is about eliminating anything
> > and
> > everything that could emotionally troubling students. This assumes a
> > high
> > degree of fragility among western students.  I work as a journalist
> > and
> > have had colleagues blown to smithereens - foot there, bits of brain
> > there.
> > I wonder how many of you bitches, have ever been shot or had a bomb
> > blown
> > up your ass.   
> 
> I've been attempting to decide if you're merely trolling us, or if you
> genuinely believe the stuff you've been posting to this list.
> 
> With your latest missive I'm leaning to the former interpretation, but
> if the latter, may I humbly suggest that referring to us as "bitches"
> might not be the best way to win people over, and that it's not normal
> to have to work in a literal war zone, and that most reasonable people
> do not want to work in a figurative war zone.
> 
> [...snip...]

I recognise it is not the best way, but the contempt is mainly directed
to those with a history of unjust accusations against Stallman.  
Although one can lean towards your interpretation, it is very easy to verify
my credentials.

https://www.corrieredimalta.com/coronavirus/la-diffusione-del-covid-19-a-malta-evento-b/

https://theshiftnews.com/2019/03/01/university-of-malta-building-fails-to-comply-with-safety-standards/

https://theshiftnews.com/2018/05/09/the-return-to-infantilism/

https://www.islesoftheleft.org/digital-rights-and-blockchain/



> Hope this is constructive
> Dave

Yes, I consider it constructive criticsism. 
 
> (my opinions only, not my employer's)
> 
>

Re: Remove RMS from the GCC Steering Committee

2021-03-31 Thread Ian Lance Taylor via Gcc

On Wed, Mar 31, 2021 at 7:44 AM Joel Sherrill  wrote:
>
> On Wed, Mar 31, 2021 at 9:23 AM Paul Koning via Gcc  wrote:
>
> > I may have lost it in the enormous flood of text, but I want to ask these
> > general questions.
> >
> > 1. Is there a published code of conduct for GCC community members,
> > possibly different ones depending on which level of the organization you're
> > in?
> >
>
> As a GNU project, this should apply.:
>
> https://www.gnu.org/philosophy/kind-communication.en.html

Yes, although that is, by design, not a code of conduct as the term is
normally used.


> > 2. Is there a formal process for receiving claims of infraction of this
> > code, and for adjudicating such claims?
> >
>
> I admit to not looking for one but does any FLOSS organization have this?

Yes, many.  For example:

LLVM: https://llvm.org/docs/CodeOfConduct.html
Go: https://golang.org/conduct
Apache: https://www.apache.org/foundation/policies/conduct.html

and there are many more.

The GNU Cauldron also has a code of conduct:
https://gcc.gnu.org/wiki/cauldron2019#Code_of_Conduct

Ian

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

2021-03-31 Thread Saloni Garg via Gcc

On Tue, Mar 30, 2021 at 6:42 PM David Malcolm  wrote:

> 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...]
>
Ok, I will keep this in mind. Thanks.

>
> > > 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.
>
No, it's actually fun learning all this. Thank you for sharing all the
references. Although, I was already using gdb to travel inside the code.

>
> > > > 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.
>
Thanks for understanding. Here is an initial draft (
https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing)
of my GSoC proposal. I am yet to fill in the missing blocks.
Please, let me know if you have any comments on the document itself.

>
> > 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...]
>
> I also request the GCC community also to please provide any suggestions
possible on the above-shared document.

-Saloni

Re: Having trouble getting my school to sign the copyright disclaimer

2021-03-31 Thread Richard Kenner via Gcc

> They claim that university owns copyright to my code if I wrote it
> for a school-related research project. 

That's potentially correct.  And the purpose of them signing the
disclaimer is to release that interest so that only you need to sign
the assignment.

The other way of doing it would be for them to sign the assignment and
you sign the disclaimer, which would essentially acknowlege that they
own the copright.

But because of of you have a potential interest in the copyright, both
of you need to sign something.

> However, since I'm an undergraduate and thus do not have an advisor,
> nobody in the campus knows me well enough to prove that it's not the case.

The purpose of having both of you sign is so that there's no potential
issue going forward where they might later assert that claim.  That way,
we don't ever need to decide who currently owns the copyright.

Re: Having trouble getting my school to sign the copyright disclaimer

2021-03-31 Thread Jim Wilson

On Wed, Mar 31, 2021 at 8:27 AM PKU via Gcc  wrote:

> I’m trying to get my school to sign the copyright disclaimer.
> Unfortunately the officials are reluctant to do that. Can anyone suggest
> what to do next?
>

Maybe the PLCT Lab at the Chinese Academy of Sciences can help.  They are
doing GCC and LLVM work, and have GCC etc assignments.  Even if they can't
help get an assignment for your current work, if you want to continue doing
GCC work, maybe your next patch can be written for them.  They hold regular
meetings for people doing GCC/LLVM work in China to meet and discuss their
work.  The PLCT work is primarily RISC-V focused though.

https://github.com/lazyparser/weloveinterns
https://github.com/lazyparser/weloveinterns/blob/master/open-internships.md#bj37-gccbinutilsglibclinker-%E5%BC%80%E5%8F%91%E5%AE%9E%E4%B9%A0%E7%94%9F-10%E5%90%8D

You might be able to find more appropriate links.  I don't actually read
Mandarin.  This is just a link I happen to know about which has good info
about the PLCT Lab.

Jim

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

2021-03-31 Thread David Malcolm via Gcc

On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote:
> On Tue, Mar 30, 2021 at 6:42 PM David Malcolm 
> wrote:
> 
> > On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <
> > > dmalc...@redhat.com>
> > > wrote:

[...snip...]

> > > 
> No, it's actually fun learning all this. Thank you for sharing all
> the
> references. Although, I was already using gdb to travel inside the
> code.

Great!

> > 
> > > > > 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.
> > 
> Thanks for understanding. Here is an initial draft (
>   
> https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing
> )
> of my GSoC proposal. I am yet to fill in the missing blocks.
> Please, let me know if you have any comments on the document itself.

Caveat: I'm not familiar with the expected format of such documents.

Looks like a good first draft.

Some notes:
- maybe update the title to be more specific (i.e. that it's about
extending the pass to support C++ exception-handling)
- my email address is misspelled (missing the leading "d")
- in Example 2, maybe spell out why it's a leak - when does the
allocated buffer stop being referenceable?
- you have a simple example of a false negative; is it possible to give
a simple example of a false positive?  (I think "new" is meant to raise
an exception if it fails, so a diagnostics about a NULL-deref on
unchecked new might be a false positive.  I'm not sure)
- maybe specify that this is exception-handling specifically for C++
code (GCC supports many languages)
- "sample example programs": for "sample" did you mean to write
"simple" here?
- as well as understanding code, you'll need to understand data,
specifically getting a feel for the kinds of control flow graphs that
the analyzer is receiving as inputs i.e. what the analyzer "sees" when
the user inputs various C++ language constructs; what interprocedural
vs intraprocedural raise/try/catch situations look like, etc.

Hope this makes sense and is helpful
Dave

Re: Remove RMS from the GCC Steering Committee

[I previously sent this from another email account, but it seems to be
lost.  I am sending this on behalf of the GCC Steering Committee.]

In 2012 RMS was added to the GCC Steering Committee web page
based on his role in the GNU Project, though his role as a member
of the Steering Committee has been ambiguous and he was not a member
of the Steering Committee when EGCS became GCC[1].  We no longer feel
that this listing serves the best interests of the GCC developer and
user community.  Therefore, we are removing him from the page.

GCC supports the principles of Free Software and has remained aligned
with the GNU Project since EGCS became GCC, but effectively has continued
to operate as an autonomous project.

The GCC Steering Committee is committed to providing a friendly, safe
and welcoming environment for all, regardless of gender identity and
expression, sexual orientation, disabilities, neurodiversity, physical
appearance, body size, ethnicity, nationality, race, age, religion, or
similar personal characteristics.

- The GCC Steering Committee

[1] https://static.lwn.net/1999/0429/a/gcc.html

RMS removed from the GCC Steering Committee (was: Remove RMS...)

Hi David, thanks for sharing!

On Wed, 31 Mar 2021 14:27:29 -0400 David Edelsohn via Gcc wrote:

> In 2012 RMS was added to the GCC Steering Committee web page
> based on his role in the GNU Project [...]
> we are removing him from the page.

I have to admit that I had never carefully observed the list of members
of the GCC steering committee. As I explained before in this thread,
the presence of Stallman gave me enough reassurance that GCC would have
honoured the values of Free Software.

As I said, enough to chose to port GCC to Jehanne instead of another
C compiler, in the hope to contribute back the port upstream, to GNU.

But now that I'm comparing the old web page [1] and the new one [2],
I realized something entirely new to me.

10 out of 13 members of the GCC steering committee work either for
American corporations (8), their subsidiaries (1) or an American
University (1) recently covered by the press in India [3].
Also, 4 of these work for the same corporation (IBM / Red Hat).

The other 3 are from German GmbH (2) or from a Nederlands public agency.

To me, and to billions of people, this shows a huge cultural bias.

Even ignoring the huge, unfair and invisible influence that such
American companies could have on the project development, even ignoring
that so many members are subject to the same Law (a Law that includes
the US Cloud Act, FISA, PPD 128, E.O. 12333, etc) decades after the
Thompson's lecture on trust in compilers development [4], the sole fact
that a single culture and economy can influence so heavily GCC
development through its leaders decisions should be fixed.

GCC is an international project.

I didn't saw this before because I trusted RMS to defend Free Software
values at any cost, but now I do not even need to recall my previous
adventures with Google and Software Freedom Conservancy to see a huge
risk not only to contribute to GCC development, but to rely on GCC.

Just like the Galactic President in The Hitchhiker's Guide, our trust
in RMS was distracting all of us from the very real and very dangerous
geopolitical-diversity issue in GCC leadership.

I'm afraid that if you wanted to attract more developers by cutting
GCC's ties with Stallman, you just proved that he was not even enough.

The GCC Steering Committee doesn't look more inclusive, without RMS.
On the contrary, it reveals itself as very "exclusive" to the world.

Please, fix it.

Giacomo

[1]
http://web.archive.org/web/20210330171044/https://gcc.gnu.org/steering.html

[2]
http://web.archive.org/web/20210331192841/https://gcc.gnu.org/steering.html

[3]
https://timesofindia.indiatimes.com/world/us/twitter-faceoff-rutgers-university-backs-controversial-historian-audrey-truschke-netizens-react/articleshow/81412939.cms

[4]
https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

Re: RMS removed from the GCC Steering Committee (was: Remove RMS...)

2021-03-31 Thread Jeff Law via Gcc




On 3/31/2021 5:11 PM, Giacomo Tesio wrote:


10 out of 13 members of the GCC steering committee work either for
American corporations (8), their subsidiaries (1) or an American
University (1) recently covered by the press in India [3].
Also, 4 of these work for the same corporation (IBM / Red Hat).


Actually, it's just 3 working for IBM/Red Hat.  My affiliation changed 
earlier this month.  I've updated the page appropriately.





The other 3 are from German GmbH (2) or from a Nederlands public agency.


To me, and to billions of people, this shows a huge cultural bias.


It's more historical than anything.  The majority of members on the 
committee were there since its inception back in the late 90s.  We are 
looking at how to increase diversity on the committee, but that's a 
separate and distinct issue from removal of RMS.



Jeff

Re: RMS removed from the GCC Steering Committee (was: Remove RMS...)