Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

Please, get serious.

=> this topic is closed for me, so STOP CC''ing ME, it is not welcome.


On Sun, 23 May 2021 at 19:03, Mike Stump  wrote:

> This isn't a patch to gcc, please stop posting non-technical content to
> this list.  Please review what this list is for and the rules for this list
> before you post again, thanks.
>
> > On May 14, 2021, at 7:47 AM, abebeos via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> >
> > Hi there IT-fascists, clowns, master-clowns,
> > totally-confused-incompetent-code-plumbers,
> > activity-trapped-silent-high-performers,
> > stay-out-of-trouble-silent-high-performers! (Guess where G.J. Lay fits in
> > the collection...).
> >
> > Please be aware that I do not read any messages here (including the one
> I'm
> > replying to), in this unregulated circus-show ("The GCC Project"). I've
> > polluted my mind enough with your nonsense justifications, to be honest
> it
> > is becoming quite disgusting.
> >
> > If any serious person from the FSF (as to my tiny research, the FSF is in
> > the end legally and ethically responsible for what happens on GCC) want
> to
> > comment on this, please send me additionally a copy of your message.
> >
> > FSF:
> >
> > Copyright: https://www.fsf.org/about/dmca-notice
> > Privacy:
> https://www.fsf.org/about/free-software-foundation-privacy-policy
> > IT-fascists, Bullying, discrimination, workers-abuse, rigged voting
> > processes: ???
>

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

Hi there IT-fascists, clowns, master-clowns,
totally-confused-incompetent-code-plumbers,
activity-trapped-silent-high-performers,
stay-out-of-trouble-silent-high-performers! (Guess where G.J. Lay fits in
the collection...).

Please be aware that I do not read any messages here (including the one I'm
replying to), in this unregulated circus-show ("The GCC Project"). I've
polluted my mind enough with your nonsense justifications, to be honest it
is becoming quite disgusting.

If any serious person from the FSF (as to my tiny research, the FSF is in
the end legally and ethically responsible for what happens on GCC) want to
comment on this, please send me additionally a copy of your message.

FSF:

Copyright: https://www.fsf.org/about/dmca-notice
Privacy: https://www.fsf.org/about/free-software-foundation-privacy-policy
IT-fascists, Bullying, discrimination, workers-abuse, rigged voting
processes: ???

.

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

On Sat, 8 May 2021 at 18:49, abebeos 
wrote:

> (failed to join gcc, so posting here)
>
> Is there any private email where one can file complaints re
> project-maintainers (or "those who are supervising the maintainers") ?
>
> Is there any information about the process for such complaints?
>
> Related Issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
>
> (please note that this complaint will most possibly escalate up to the
> person(s) who are responsible for policies/rules)
>

This topic is "closed" for me (for now).

"
Now, the headline would be:

"Physik FU-Berlin, Microchip, Google, RedHat, IBM and more to Support
Abuse, Discrimination and even 'IT-fascism' via/on GCC/GNU/FSF
Project-Resources".

See, nobody cares, until a valid(!) headline gets some visibility.

But for now I'll stop here, as I don't want to open/activate accounts in
order to publish. And in the end, I would analyze GCC/GNU/FSF weaknesses
and threads without getting payed.

Just one last thing:

John Paul Adrian Glaubitz, you have attacked my professional reputation in
public, saying more or less that I claimed the bounty without having done
any work for it.

But the indisputable fact is that any person that declares "assessment,
validation, integration and general reuse of existent results" as "copying"
should simply stay away from OSS software.

And persons which abuse their (position of) power to brute-force violate
voting procedures (or to not intervene), are just some (more or less worse)
form  of IT-fascists.

People like you should be kicked out immediately from OSS projects.

Well, at least in a perfect world.

Cu around, clowns.
"
source: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c61

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

On Tue, 11 May 2021 at 01:43, Jeff Law  wrote:

>
> On 5/10/2021 3:45 PM, abebeos via Gcc-patches wrote:
> >
> > I've described this in my message here:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569913.html
> >
> > The summary is possibly
> > * I identified via necessary week-long work a (shelved) patch as valid
> for
> > (re)use.
> > * The gcc project(members) simply downplayed my week-long efforts to
> > essentially "nothing".
> > * Issue-author, patch-author and other gcc participants kept silence when
> > the voting-process was rigged.
> > * (and some other things, like e.g. missing
> complaint-addresses/procedures
> > which enable "wild-west" abuse of workers).
> >
> > See, I do hard/soft/firmware, but before that, I setup stable
> reproducible
> > dev-environments (which gcc lacks, at least for avr).
> > Then I try to validate/reuse/extend existent results.
> > Only then, I go to implement own solutions.
> >
> > This is a usual process, nothing special for professionals.
> >
> > But here comes the bomb:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c55
> > "You have no claim in this whole effort. You just tried to copy someone
> > else's work."
>
> This comment is from the person who set up the bounty.  Your issue is
> with him and/or bountysource.  The GCC project does not control or
> directly influence the bountysource program.
>

This is ridiculous.

GCC issue, GCC resources(!), GCC committers, GCC participants.

Be aware that each and every person which noticed the non-attribution and
the rigged vote, without intervening, does this:

=> Supporting IT-fascism, in the name of GCC/GNU.

Including you - whoever you are.


>
>
> Jeff
>
>
>

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

On Tue, 11 May 2021 at 01:35, Ian Lance Taylor  wrote:

> On Mon, May 10, 2021 at 2:45 PM abebeos 
> wrote:
> >
> > The bounty was filed/advertised by the gcc project, so the gcc project
> should have intervened immediately at the point where an anonymous coward
> rigged the voting process (aborted the vote before end of the voting
> period).
> >
> > The fact that I need to explain this is quite a tragedy.
>
> I've already done my best to explain the distinction between GCC and
> Bountysource.


There is not distinction. GCC project-resources were used, GCC participants
everywhere, so this is a GCC matter.

I'll not comment further on your beyond ridiculous "line of defense".

I just hope that you are in no way related to the leadership of GCC/GNU.


>   You are blaming the wrong people here.  The bounty was
> not filed by the GCC project.  It was not advertised by the GCC
> project.  I know nothing about the Bountysource voting process because
> it has nothing to do with GCC.  The fact that people associated in
> some way with the bounty process commented on a GCC bug report does
> not mean that the GCC project had anything to do with the bounty.
>
> Ian
>

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

On Mon, 10 May 2021 at 23:32, Ian Lance Taylor  wrote:

> On Mon, May 10, 2021, 9:52 AM abebeos 
> wrote:
>
>> Again, just heavily fascinating to see how you ignore the overall essence
>> of this, which is of course directly related to gcc.
>>
>> (bountysource is just a secondary disaster, it all starts here, at gcc.
>>
>
> What do you think that the GCC project has done wrong for this specific
> issue?
>

I've described this in my message here:

https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569913.html

The summary is possibly
* I identified via necessary week-long work a (shelved) patch as valid for
(re)use.
* The gcc project(members) simply downplayed my week-long efforts to
essentially "nothing".
* Issue-author, patch-author and other gcc participants kept silence when
the voting-process was rigged.
* (and some other things, like e.g. missing complaint-addresses/procedures
which enable "wild-west" abuse of workers).

See, I do hard/soft/firmware, but before that, I setup stable reproducible
dev-environments (which gcc lacks, at least for avr).
Then I try to validate/reuse/extend existent results.
Only then, I go to implement own solutions.

This is a usual process, nothing special for professionals.

But here comes the bomb:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c55
"You have no claim in this whole effort. You just tried to copy someone
else's work."

What is this joke? Obviously zero understanding of basic dev-processes.

Why has this person the freedom to abuse contributors on the gcc project?

Is there no process within gcc to stop "circus-shows" and
"wild-west-behavior"?

To me it is clear that this person has no idea about higher-grade
development-work:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c40

-

And why can an anonymous coward (possibly the same person as above) rig
voting processes, based on such totally unfounded assessments of my work?

The very funny things is that when I started working, the patch wasn't even
visible, it was forgotten:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c21

I get at this point "zero attribution", which translates to "zero % of the
bounty".

Even just for the attribution:

Shame on you, gcc.

  In answering please do not mention anything about bounties or
> Bountysource, as those have nothing to do with the GCC project.
>

What?

The bounty is directly related to the issue.

The bounty was filed/advertised by the gcc project, so the gcc project
should have intervened immediately at the point where an anonymous coward
rigged the voting process (aborted the vote before end of the voting
period).

The fact that I need to explain this is quite a tragedy.




> Ian
>
>>

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

(unable to comment to this without loosing my temper. So... no comment)

On Mon, 10 May 2021 at 05:49, Ian Lance Taylor  wrote:

> On Sun, May 9, 2021 at 8:33 AM abebeos 
> wrote:
> >
> > To me this sounds quite like an "disorganized mess, where bullies,
> abusers and even IT-fascists can thrive".
> >
> > It is clear to me that some gcc project maintainers, the steering
> committee and bountysource are crossing ethical (if not legal) boundaries.
>
> The GCC project maintainers and the steering committee are definitely
> not crossing ethical or legal boundaries here.
>
> I don't know anything about Bountysource.  Bountysource is completely
> separate from GCC.  It appears from your link that John Paul Adrian
> Glaubitz posted a bounty for some GCC work.  A number of people and
> organizations supported the bounty, but the GCC project itself did
> not.  Although the work is for GCC, the GCC project has nothing to do
> with that bounty.  That is handled entirely by Bountysource.
>
>
> > The Issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
> >
> > The Bounty (a bit higher than $7K)
> >
> >
> https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> >
> > The Complaint re Voting Process:
> >
> > https://github.com/bountysource/core/issues/1532
> >
> > Bountysource may write whatever they want in their terms-of-service -
> the relevant law is still above. And of course OSS-ethics, which are more
> that a basic code-monkey-mentality of the kind "only code is work, only
> patch authors are workers".
> >
> > * there is a bounty
> > * I start work (working around a major gcc project deficit, which is a
> missing CI, testing testing testing, concluding, "reviving" and existent
> patch)
> > * I claim 50%
> > * a dispute starts, which is then aborted non-transparently by some
> anonymous coward, without waiting for the major backers votes,  and all gcc
> participants simply keep silence.
> >
> > I am aware that the effort to fight for 50% of a $7K bounty is not worth
> it - even the distraction for opening a discussion here is essentially not
> worth the effort.
> >
> > I cared more or less only on what Microchip ($5K contibution to the
> bounty) had to say, and the other two top backers. And I'm still curious
> about this.
> >
> > If they too say "research, analysis and integration work is no work" and
> "effort to validate abandoned patches and reuse of them is no work" - well,
> then I guess I'll rest my case.
> >
> > But at least it gets "on file", so other people which struggle with gcc
> (especially in combination with bountysource) have a point-of-reference.
> >
> > Very disappointing all this.
> >
> > I mean really? An OSS project which brute-force aborts a
> voting-procedure (=IT-fascism)? Just to award a monetary value to an
> gcc-project insider?
> >
> > And everyone keeps silence?
>
> If I'm reading the Bountysource page correctly, the bounty was awarded
> to saaadhu, who I assume is Senthil Kumar Selvaraj.  Senthil has been
> a GCC contributor for a while with some 70 committed patches.  But I
> wouldn't describe them as a GCC project insider.  They are not a GCC
> maintainer or reviewer.
>
>
>
> > We all know that reproducing such things in order to have an informed
> opinion/vote costs terribly high amounts of time. The simplified method
> would be:
> >
> > * enter the issues here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c9
> > * then, just try to validate the until then available patch
> >   * => you'll fail, as no stable environment is available (major failure
> of the steering comitee, which should insist "all targets need to have an
> functioning CI"
> > * => here you start integrating a dev/ci environment, try to find
> reference points/versions etc., etc.
> >
> > @ Steering Committee
> >
> > A functioning CI across targets is a non-disputable must requirement in
> todays IT landscape:
> >
> > * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98574
> >
> > Or at least reference-repos, like e.g. this one:
> >
> > * https://github.com/abebeos/avr-gnu
> >
> > We would not have this topic here, if the gcc-project had a decent CI,
> or a build-setup used by all developers.
>
> I agree that having a good CI for GCC would be really great.  It's
> also really hard.  GCC generates code for many different targets, and
> the nature of GCC is such that running tests on a simulator rather
> than real hardware, while helpful, is simply not good enough in
> practice.  So a good CI for GCC requires supporting a large variety of
> hardware.  That is very desirable.  It's also very hard and very
> expensive.  The GCC project must rely on volunteers for this work.
> You can see the available support at
> https://gcc.gnu.org/wiki/CompileFarm and on the gcc-testresults
> mailing list.  Should the project have better CI?  Yes, absolutely.
> Who is going to put in the time, effort, and money to make that
> happen?
>
>
> In any case, 

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

Again, just heavily fascinating to see how you ignore the overall essence
of this, which is of course directly related to gcc.

(bountysource is just a secondary disaster, it all starts here, at gcc.



On Mon, 10 May 2021 at 12:19, Jakub Jelinek  wrote:

> On Sun, May 09, 2021 at 07:48:50PM -0700, Ian Lance Taylor via Gcc-patches
> wrote:
> > On Sun, May 9, 2021 at 8:33 AM abebeos 
> wrote:
> > >
> > > To me this sounds quite like an "disorganized mess, where bullies,
> abusers and even IT-fascists can thrive".
> > >
> > > It is clear to me that some gcc project maintainers, the steering
> committee and bountysource are crossing ethical (if not legal) boundaries.
> >
> > The GCC project maintainers and the steering committee are definitely
> > not crossing ethical or legal boundaries here.
> >
> > I don't know anything about Bountysource.  Bountysource is completely
> > separate from GCC.  It appears from your link that John Paul Adrian
> > Glaubitz posted a bounty for some GCC work.  A number of people and
> > organizations supported the bounty, but the GCC project itself did
> > not.  Although the work is for GCC, the GCC project has nothing to do
> > with that bounty.  That is handled entirely by Bountysource.
>
> Yeah, all that happened on the GCC project side is the agreement
> to deprecate and eventually remove ports that still rely on internal
> details that were obsolete 20 years ago, see
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01256.html
> and then patch review of changes that were posted to gcc-patches.
> The GCC reviewers review posted patches based on the technical
> merits and whether copyright assignment for parts that require copyright
> assignment is available, regardless of whether the people who submit their
> work did the work in their spare time without being compensated for it,
> whether their employers compensated them for it, whether they got
> contracted by
> some company for that work or other means (e.g. bountysource).
> All that is outside of the scope of the GCC project.
> Bountysource AFAIK has its own terms and rules and I believe ultimately it
> is the people who donated money for it that vote about that.
>
> Jakub
>
>

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

It is just fascinating to see how you don't realize that this affects
mainly gcc.

On Mon, 10 May 2021 at 01:42, Eric Botcazou 
wrote:

> > It is a gcc issue, see the very first link you've quoted (
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729).
>
> IIUC you're complaining about the bounty process, not about the GCC PR, so
> this technical list is not the appropriate place to do it.  AFAICS you
> have
> already filed a complaint with Bountysource, so it's up to them to decide
> whether to accept or reject it.
>
> --
> Eric Botcazo
>
>
>

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

On Sun, 9 May 2021 at 20:32, Koning, Paul  wrote:

>
>
> > On May 9, 2021, at 11:33 AM, abebeos via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> >
> > Thank you for your quick response.
> >
> > ...
> > The Issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
> >
> > The Bounty (a bit higher than $7K)
> >
> >
> https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> >
> > The Complaint re Voting Process:
> >
> > https://github.com/bountysource/core/issues/1532
>
> I don't understand why you're coming to the GCC lists to debate this.  The
> issue you're talking about isn't a GCC issue at all.

[...]

It is a gcc issue, see the very first link you've quoted (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729).

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

Thank you for your quick response.

To me this sounds quite like an "disorganized mess, where bullies, abusers
and even IT-fascists can thrive".

It is clear to me that some gcc project maintainers, the steering committee
and bountysource are crossing ethical (if not legal) boundaries.

The Issue:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

The Bounty (a bit higher than $7K)

https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

The Complaint re Voting Process:

https://github.com/bountysource/core/issues/1532

Bountysource may write whatever they want in their terms-of-service - the
relevant law is still above. And of course OSS-ethics, which are more that
a basic code-monkey-mentality of the kind "only code is work, only patch
authors are workers".

* there is a bounty
* I start work (working around a major gcc project deficit, which is a
missing CI, testing testing testing, concluding, "reviving" and existent
patch)
* I claim 50%
* a dispute starts, which is then aborted non-transparently by some
anonymous coward, without waiting for the major backers votes,  and all gcc
participants simply keep silence.

I am aware that the effort to fight for 50% of a $7K bounty is not worth it
- even the distraction for opening a discussion here is essentially not
worth the effort.

I cared more or less only on what Microchip ($5K contibution to the bounty)
had to say, and the other two top backers. And I'm still curious about this.

If they too say "research, analysis and integration work is no work" and
"effort to validate abandoned patches and reuse of them is no work" - well,
then I guess I'll rest my case.

But at least it gets "on file", so other people which struggle with gcc
(especially in combination with bountysource) have a point-of-reference.

Very disappointing all this.

I mean really? An OSS project which brute-force aborts a voting-procedure
(=IT-fascism)? Just to award a monetary value to an gcc-project insider?

And everyone keeps silence?

Shame on you people.

P.S.:

We all know that reproducing such things in order to have an informed
opinion/vote costs terribly high amounts of time. The simplified method
would be:

* enter the issues here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c9
* then, just try to validate the until then available patch
  * => you'll fail, as no stable environment is available (major failure of
the steering comitee, which should insist "all targets need to have an
functioning CI"
* => here you start integrating a dev/ci environment, try to find reference
points/versions etc., etc.

@ Steering Committee

A functioning CI across targets is a non-disputable must requirement in
todays IT landscape:

* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98574

Or at least reference-repos, like e.g. this one:

* https://github.com/abebeos/avr-gnu

We would not have this topic here, if the gcc-project had a decent CI, or a
build-setup used by all developers.



On Sun, 9 May 2021 at 05:06, Ian Lance Taylor  wrote:

> On Sat, May 8, 2021 at 8:49 AM abebeos via Gcc-patches
>  wrote:
> >
> > Is there any private email where one can file complaints re
> > project-maintainers (or "those who are supervising the maintainers") ?
> >
> > Is there any information about the process for such complaints?
> >
> > Related Issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
> >
> > (please note that this complaint will most possibly escalate up to the
> > person(s) who are responsible for policies/rules)
>
> The GCC project does not have a code of conduct, and it does not have
> a managing hierarchy.  Nobody supervises the maintainers.  GCC has a
> minimum of non-technical policies/rules, and it has no enforcement
> mechanism.  There really isn't any place to file a complaint.  You can
> complain to the GCC steering committee if you like
> (https://gcc.gnu.org/steering.html; I am a member), but there are a
> very limited number of actions that the steering committee could take,
> and it is very unlikely that the committee would actually do anything.
>
> Basically, GCC is a cooperative project.  It's not a company.  People
> don't work for GCC.
>
> I'm sorry you are having trouble, but I don't think there is much that
> the GCC project can do to help.
>
> Ian
>

[GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

(failed to join gcc, so posting here)

Is there any private email where one can file complaints re
project-maintainers (or "those who are supervising the maintainers") ?

Is there any information about the process for such complaints?

Related Issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480

(please note that this complaint will most possibly escalate up to the
person(s) who are responsible for policies/rules)

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Tue, 5 Jan 2021 at 20:24, Jeff Law  wrote:

>
>
> On 1/5/21 10:54 AM, Rainer Orth wrote:
> >
> > I fear I'm a bit lost here myself.  I do have a little experience
> > running various builders:
> >
> > * I inherited a Golang one on Solaris/amd64 (based on their own builder
> >   infrastructure).
> >
> > * I do run builders for GDB (mostly dormant since Sergio left RedHat)
> >   and LLVM on Solaris/amd64 and sparcv9 (both using buildbot).
> >
> > In all three cases the projects provide documentation how to configure
> > your own builders and add them to the infrastructure.  Is something like
> > this possible for the GCC Jenkins (say adding Solaris builders) and if
> > so how?  Or would one need to setup one's own instance, in which case it
> > would be extremely helpful to learn the necessary config: doing
> > something like this from scratch is a major effort, as seen in Paul
> > Matos' effort (also buildbot-based) of a couple of years ago.
> We don't have any procedures in place for this (yet).  I'd like to add
> them, but I'm swamped.
>

Ok, I've done the first step, possibly enough folks is interested to get
this done:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98574

I'm certainly open to having others contribute here.  As a long standing
> member of the community I'd be happy to set up an account for you so you
> could wire in a sparc/solaris system executor and set up the build scripts.
>
> Jeff
>
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Tue, 5 Jan 2021 at 21:25, Rainer Orth 
wrote:

> Hi Jeff,
>
> > On 1/5/21 10:54 AM, Rainer Orth wrote:
> >>
> >> I fear I'm a bit lost here myself.  I do have a little experience
> >> running various builders:
> >>
> >> * I inherited a Golang one on Solaris/amd64 (based on their own builder
> >>   infrastructure).
> >>
> >> * I do run builders for GDB (mostly dormant since Sergio left RedHat)
> >>   and LLVM on Solaris/amd64 and sparcv9 (both using buildbot).
> >>
> >> In all three cases the projects provide documentation how to configure
> >> your own builders and add them to the infrastructure.  Is something like
> >> this possible for the GCC Jenkins (say adding Solaris builders) and if
> >> so how?  Or would one need to setup one's own instance, in which case it
> >> would be extremely helpful to learn the necessary config: doing
> >> something like this from scratch is a major effort, as seen in Paul
> >> Matos' effort (also buildbot-based) of a couple of years ago.
> > We don't have any procedures in place for this (yet).  I'd like to add
> > them, but I'm swamped.
>
> understood.  Often it's easier for an outsider to document a procedure
> since he's certain to stumble across every possible roadblock someone
> familiar with the system has long forgotten about.
>

Many roadblocks/barriers, and the complaining newcomers(outsiders) are many
times even attacked by the regulars, kind of "it's just opening bash, do
this, that, then that that that, pick this, ready".

@steering committee

Consider transforming the gcc-jenkins to be an open-project (repository,
usually patch-update-processes)


> > I'm certainly open to having others contribute here.  As a long standing
> > member of the community I'd be happy to set up an account for you so you
> > could wire in a sparc/solaris system executor and set up the build
> scripts.
>

Do I need an account to look at how things work there?

I am unable to find even one script from the jenkins UI.

Any direct link?


> That would be nice.  Although my current manual daily regtests do help
> and a considerable part of the work is investigating and reporting
> failures found, any automatism takes part of the legwork.
>
> Rainer
>
> --
>
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Tue, 5 Jan 2021 at 18:50, Jeff Law  wrote:

>
>
> On 1/5/21 2:18 AM, abebeos wrote:
> >
> > On Mon, 4 Jan 2021 at 21:40, Jeff Law  > > wrote:
> >
> > On 12/31/20 7:13 AM, abebeos wrote:
> > [...]
> > > > I'm definitely curious about the testing setup and
> > > whether or
> > > > not it can
> > > > be replicated into our Jenkins setup.
> > > >
> > > >
> > > > Where can I find this Jenkins setup?
> > > >
> > > >
> > > > To close this: assuming " into our Jenkins setup" is some
> > redhat
> > > > internal jenkins setup.
> > > No, it's public.
> > >
> > > http://gcc.gnu.org/jenkins 
> > >
> > >
> > >
> > > (sidenote: This resolves on my side to the (insecure)
> > > http://3.14.90.209:8080/ 
> > >)
> > Yup.
> >
> > >
> > > Is the source-code of  http://gcc.gnu.org/jenkins
> > 
> > > >
> > available somewhere? I could not locate it.
> > Jenkins is a project independent of GCC for building continuous
> > testing/delivery systems.  See http://jenkins.io 
> >
> >
> > Oh, my bad - I was referring to the sources of gcc's project jenkins
> > setup (the scripts, configs etc. for the different targets, including
> > avr).
> The Generators subdirectory has jobs which are used to rebuild the
> various target jobs.  They're broadly categorized by the type of build.
> ie, pure native, qemu-emulated native, glibc cross, newlib cross and no
> runtime library.  avr IIRC fits into the final category as it doesn't
> have an upstreamed glibc or newlib port.
>

Ok, but I'm still unable to find the sources ("Generators subdirectory"?).
Can you (or anyone else) give me a direct link to the sources? E.g. I want
to change the avr part, where do I start (usually, a git repo.)?


>
> Jeff
>
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Mon, 4 Jan 2021 at 21:40, Jeff Law  wrote:

> On 12/31/20 7:13 AM, abebeos wrote:
> [...]
> > > I'm definitely curious about the testing setup and
> > whether or
> > > not it can
> > > be replicated into our Jenkins setup.
> > >
> > >
> > > Where can I find this Jenkins setup?
> > >
> > >
> > > To close this: assuming " into our Jenkins setup" is some redhat
> > > internal jenkins setup.
> > No, it's public.
> >
> > http://gcc.gnu.org/jenkins 
> >
> >
> > (sidenote: This resolves on my side to the (insecure)
> > http://3.14.90.209:8080/ )
> Yup.
>
> >
> > Is the source-code of  http://gcc.gnu.org/jenkins
> >  available somewhere? I could not locate it.
> Jenkins is a project independent of GCC for building continuous
> testing/delivery systems.  See http://jenkins.io


Oh, my bad - I was referring to the sources of gcc's project jenkins setup
(the scripts, configs etc. for the different targets, including avr).

jeff
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Wed, 30 Dec 2020 at 05:41, Jeff Law  wrote:

>
>
> On 12/23/20 9:01 AM, abebeos wrote:
> >
> >
> > On Sun, 13 Dec 2020 at 20:14, abebeos  > <http://lazaridis.com>+abeb...@gmail.com <mailto:abeb...@gmail.com>>
> > wrote:
> >
> >
> >
> > On Fri, 11 Dec 2020 at 20:32, Jeff Law  > <mailto:l...@redhat.com>> wrote:
> >
> >
> >
> > On 12/9/20 6:12 AM, abebeos via Gcc-patches wrote:
> > > Essence:
> > >
> > > I need a confirmation that the testsuite setup as presented in:
> > >
> > > https://github.com/abebeos/avr-gnu
> > <https://github.com/abebeos/avr-gnu>
> > >
> > > works fine.
> > >
> > > The problem with the avr target is that the testsuite cannot
> > be run easily,
> > > mainly because of the need for a special simulated-target
> > setup, which does
> > > not work for avr as documented. This led developers to a
> > dead-end with
> > > their non-cc0-avr-backends (the non-cc0 backend is needed
> > thus avr is not
> > > dropped from gcc11).
> > >
> > > I integrated a toolchain/testsetup to be able to run the gcc
> > testsuite
> > > against a simulated avr target.
> > >
> > > I then used this toolchain to test 2 different existent
> > > non-cc0-avr-backends (from pipcet and saaadhu, both github).
> > >
> > > The result is that saaadhu's backend seems to be working
> > 100%. It has
> > > identical testsuite results with the existing (but
> > deprecated) cc0-backend,
> > > which means that it can be used "as-is" for inclusion in gcc11.
> > >
> > > Please note that I did this work in context of a bounty @
> > bountysouce, more
> > > information within the issue:
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35>
> > I haven't looked at the github repo.  But I do have a couple
> > comments here.
> >
> > First, the author of the changes (pipcet and saaadhu) need to
> have
> > copyright assignments on file with the FSF.  Otherwise we can
> > not use
> > their work at all.
> >
> > Second, the work needs to be submitted for inclusion.  I don't
> > recall
> > seeing an official submission from either of them to gcc-patches.
> >
> > I'm definitely curious about the testing setup and whether or
> > not it can
> > be replicated into our Jenkins setup.
> >
> >
> > Where can I find this Jenkins setup?
> >
> >
> > To close this: assuming " into our Jenkins setup" is some redhat
> > internal jenkins setup.
> No, it's public.
>
> http://gcc.gnu.org/jenkins


(sidenote: This resolves on my side to the (insecure)
http://3.14.90.209:8080/)

Is the source-code of  http://gcc.gnu.org/jenkins available somewhere? I
could not locate it.


>
> jeff
>
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Sun, 13 Dec 2020 at 20:14, abebeos 
wrote:

>
>
> On Fri, 11 Dec 2020 at 20:32, Jeff Law  wrote:
>
>>
>>
>> On 12/9/20 6:12 AM, abebeos via Gcc-patches wrote:
>> > Essence:
>> >
>> > I need a confirmation that the testsuite setup as presented in:
>> >
>> > https://github.com/abebeos/avr-gnu
>> >
>> > works fine.
>> >
>> > The problem with the avr target is that the testsuite cannot be run
>> easily,
>> > mainly because of the need for a special simulated-target setup, which
>> does
>> > not work for avr as documented. This led developers to a dead-end with
>> > their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is
>> not
>> > dropped from gcc11).
>> >
>> > I integrated a toolchain/testsetup to be able to run the gcc testsuite
>> > against a simulated avr target.
>> >
>> > I then used this toolchain to test 2 different existent
>> > non-cc0-avr-backends (from pipcet and saaadhu, both github).
>> >
>> > The result is that saaadhu's backend seems to be working 100%. It has
>> > identical testsuite results with the existing (but deprecated)
>> cc0-backend,
>> > which means that it can be used "as-is" for inclusion in gcc11.
>> >
>> > Please note that I did this work in context of a bounty @ bountysouce,
>> more
>> > information within the issue:
>> >
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
>> I haven't looked at the github repo.  But I do have a couple comments
>> here.
>>
>> First, the author of the changes (pipcet and saaadhu) need to have
>> copyright assignments on file with the FSF.  Otherwise we can not use
>> their work at all.
>>
>> Second, the work needs to be submitted for inclusion.  I don't recall
>> seeing an official submission from either of them to gcc-patches.
>>
>> I'm definitely curious about the testing setup and whether or not it can
>> be replicated into our Jenkins setup.
>
>
> Where can I find this Jenkins setup?
>

To close this: assuming " into our Jenkins setup" is some redhat internal
jenkins setup.


> It is my understanding there is
>> no newlib support for avr so I'm curious what you're using for a basic
>> runtime library.
>>
>> jeff
>>
>>

Re: [PATCH] avr: cc0 to mode_cc conversion

[abebeos via Gcc-patches]

On Fri, 18 Dec 2020 at 20:31, Segher Boessenkool 
wrote:

> On Fri, Dec 18, 2020 at 06:13:22PM +0100, Georg-Johann Lay wrote:
> > Segher Boessenkool schrieb:
> > >On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote:
> > >>>On Dec 17, 2020, at 6:21 AM, Segher Boessenkool
> > >>> wrote:
> > >>>On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via
> > >>>Gcc-patches wrote:
> > The work on my github branch was not complete - I'd blindly followed
> > whatever the CC0 Transition wiki mentioned (the first three steps of
> > case #2), and fixed any regression fallout (for ATmega128).
>
[...]

@Senthil Kumar Selvaraj 

Remember that a full polish of the avr-backend is beyond the scope of the
task/bounty:

avr-cc0 ---[eliminate cc0]---> avr-non-cc0 with similar (or even worse)
quality.

Possibly this one is relevant as for "effort":

https://gcc.gnu.org/pipermail/gcc/2020-April/000455.html
as mentioned here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c9

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Fri, 11 Dec 2020 at 23:20, abebeos 
wrote:

> Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
> seg...@kernel.crashing.org> έγραψε:
>
[...]

> I'd ask the original author, but it seems he's busy with other work, so to
>> > avoid delays...
>>
>> Please try to ask him first?  That is always nice,
>
>
> contacted days ago both authors via email (naturally closing with "feel
> free to  ignore if you're busy"), pip replied, saa not. Though both are on
> the cc of the issue, too.
>
>
>> but you all also need to figure out what to do with the bounty.
>>
>
> Yes, the final "drama", but in the end, the bounty-backers decide about
> any claims.
>
> If they e.g. decide to hand out the bounty to the patch-producer... well.
>

clarification:

patch-producer = patch-author

Me currently anyways more in "want to get this done" (before my attention
> window closes).
>
> Segher
>>
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Wed, 16 Dec 2020 at 22:44, abebeos 
wrote:
[...]

> And look at this:
>
> * 200h (estimation) for the patch
>

Not my work, other author(s).

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

+cc: Law, Biener,
On Wed, 16 Dec 2020 at 20:27, Dimitar Dimitrov  wrote:

> On понеделник, 14 декември 2020 г. 20:53:36 EET Dimitar Dimitrov wrote:
> > On петък, 11 декември 2020 г. 19:00:35 EET abebeos wrote:
> > > After "digesting" a bit more your review, I need to thank you for
> opening
> > > my eyes re "cherrypick" suggestion and... the missing g++ summaries. I
> > > need
> > > to update my setup to provide the g++ test-deltas, too. Note that in my
> > > test-setup, more c++ tests pass than in yours, not exactly sure why.
> It's
> > > in the "unresovled testcases".
> >
> > Regarding the additional "unresolved testcases" in my results. I traced
> it
> > to a bug in my setup. I did not prepare $HOME/.dejagnurc properly for
> AVR.
> > I'll rerun the tests and post the results.
> >
> > I'm using stock avr-libc, while I see you are using the avr-libc3 fork.
> > Hopefully the main differences are in HW support, not core libc.
> >
> > Regards,
> > Dimitar
>
> Here are the tests results with my environment fixes. Outcome is the same
> -
> saaadhu has no regressions.
>

Very nice!

@all

This review:

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561757.html

shows that there is still much work to do.

But the patch author seems "away" (and not available anyways), the listed
avr maintainer seems "super-away", main "executing analyst" (me) refuses to
"touch even whitespace".

To my understanding, the non-availability of the avr maintainer should mean
that the "upper-up" maintainers decide.

Commiting means essentially:

=> A low-quality avr-cc0 backend will be replaced with a 0-regressions
low(possibly even lower)-quality avr-mode_cc backend.

If anyone insists to polish things even more in context of a $7K bounty...
start thinking about this:

* Where is the line where bounty-work becomes IT-worker-abuse?
* Do you want people start saying (rightfully) that "gcc bounties are
essentially slave-labour"?
* Enjoying fixed employment?

And look at this:

* 200h (estimation) for the patch
* 200+h for the integration-work (dev-systems, testing etc.) - general
reading not counted.
* 100h (estimation) polishing
* 400h (estimation) for quality enhancement

no way, dishwashing pays better (
https://www.payscale.com/research/US/Job=Dishwasher/Hourly_Rate).

I could, as a follow-up task, "enhance the quality of the avr-mode-cc
backend", nothing special with the code.

But me not sure if it's worth assimilating "gcc's md & related internals"
to the point neccessary to fulfill the task at hand.

I've done my work here.

Note that I'll stop monitoring gcc-patches, but I'm still monitoring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c41


=
> baseline beb9afcaf1466996a301c778596c5df209e7913c
> === gcc Summary ===
>
> # of expected passes105527
> # of unexpected failures584
> # of unexpected successes   16
> # of expected failures  582
> # of untested testcases 2
> # of unresolved testcases   33
> # of unsupported tests  5031
>
> === g++ Summary ===
>
> # of expected passes146432
> # of unexpected failures8012
> # of unexpected successes   21
> # of expected failures  624
> # of untested testcases 10
> # of unresolved testcases   3174
> # of unsupported tests  2
>
>
> =
> pipcet/avr-ccmode
> === gcc Summary ===
>
> # of expected passes105431
> # of unexpected failures709
> # of unexpected successes   16
> # of expected failures  582
> # of untested testcases 2
> # of unresolved testcases   69
> # of unsupported tests  5032
>
> === g++ Summary ===
>
> # of expected passes146229
> # of unexpected failures8291
> # of unexpected successes   21
> # of expected failures  624
> # of untested testcases 10
> # of unresolved testcases   3236
> # of unsupported tests  2
>
> =
> saadhu/avr-cc0
> === gcc Summary ===
>
> # of expected passes105527
> # of unexpected failures584
> # of unexpected successes   16
> # of expected failures  582
> # of untested testcases 2
> # of unresolved testcases   33
> # of unsupported tests  5031
>
> === g++ Summary ===
>
> # of expected passes146432
> # of unexpected failures8012
> # of unexpected successes   21
> # of expected failures  624
> # of untested testcases 10
> # of unresolved testcases   3174
> # of unsupported tests  2
>
> Regards,
> Dimitar
>
>
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Tue, 15 Dec 2020 at 04:01, Jeff Law  wrote:

>
>
> On 12/14/20 12:10 PM, Dimitar Dimitrov wrote:
> > On четвъртък, 10 декември 2020 г. 10:24:50 EET Richard Biener wrote:
> >> On Thu, Dec 10, 2020 at 6:42 AM Dimitar Dimitrov 
> wrote:
> >>> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches
> wrote:
> >>>> Essence:
> >>>>
> >>>> I need a confirmation that the testsuite setup as presented in:
> >>>>
> >>>> https://github.com/abebeos/avr-gnu
> >>>>
> >>>> works fine.
> >>>>
> >>>> The problem with the avr target is that the testsuite cannot be run
> >>>> easily,
> >>>> mainly because of the need for a special simulated-target setup, which
> >>>> does
> >>>> not work for avr as documented. This led developers to a dead-end with
> >>>> their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is
> >>>> not
> >>>> dropped from gcc11).
> >>>>
> >>>> I integrated a toolchain/testsetup to be able to run the gcc testsuite
> >>>> against a simulated avr target.
> >>>>
> >>>> I then used this toolchain to test 2 different existent
> >>>> non-cc0-avr-backends (from pipcet and saaadhu, both github).
> >>>>
> >>>> The result is that saaadhu's backend seems to be working 100%. It has
> >>>> identical testsuite results with the existing (but deprecated)
> >>>> cc0-backend,
> >>>> which means that it can be used "as-is" for inclusion in gcc11.
> >>>>
> >>>> Please note that I did this work in context of a bounty @ bountysouce,
> >>>> more
> >>>> information within the issue:
> >>>>
> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> >>> Hi,
> >>>
> >>> I tested the trees you have given with my own AVR test setup [1]. I
> >>> confirm
> >>>
> >>> your results:
> >>>   - saaadhu's tree does not introduce any regressions.
> >>>   - pipcet's tree has 142 gcc and 299 g++ regressions (although many of
> >>>   them
> >>>
> >>> are duplicates, e.g. same test case with different optimization
> >>> levels).
> >>>
> >>> It's a bit awkward to copy gcc/config/avr into a mainline tree.
> Looking at
> >>> their github history, both authors made some small changes in other
> areas.
> >>> I would have prefered to cherry-pick or apply patches.
> >>>
> >>> =
> >>> baseline beb9afcaf1466996a301c778596c5df209e7913c
> >>>
> >>> === gcc Summary ===
> >>>
> >>> # of expected passes87504
> >>> # of unexpected failures1105
> >>> # of unexpected successes   15
> >>> # of expected failures  581
> >>> # of unresolved testcases   16786
> >>> # of unsupported tests  5370
> >>>
> >>> === g++ Summary ===
> >>>
> >>> # of expected passes140663
> >>> # of unexpected failures7932
> >>> # of unexpected successes   21
> >>> # of expected failures  620
> >>> # of unresolved testcases   8603
> >>> # of unsupported tests  11305
> >>>
> >>> =
> >>> pipcet/avr-ccmode
> >>>
> >>> === gcc Summary ===
> >>>
> >>> # of expected passes87463
> >>> # of unexpected failures1221
> >>> # of unexpected successes   15
> >>> # of expected failures  581
> >>> # of unresolved testcases   16799
> >>> # of unsupported tests  5359
> >>>
> >>> === g++ Summary ===
> >>>
> >>> # of expected passes140529
> >>> # of unexpected failures8205
> >>> # of unexpected successes   21
> >>> # of expected failures  620
> >>> # of unresolved testcases   8607
> >>> # of unsupported tests  11301
> >>>
> >>> =
> >>&g

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Thu, 10 Dec 2020 at 15:57, abebeos 
wrote:

>
>
> Στις Πέμ, 10 Δεκ 2020 στις 7:42 π.μ., ο/η Dimitar Dimitrov <
> dimi...@dinux.eu> έγραψε:
>
>> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches wrote:
>> > Essence:
>> >
>> > I need a confirmation that the testsuite setup as presented in:
>> >
>> > https://github.com/abebeos/avr-gnu
>> >
>> > works fine.
>> >
>> > The problem with the avr target is that the testsuite cannot be run
>> easily,
>> > mainly because of the need for a special simulated-target setup, which
>> does
>> > not work for avr as documented. This led developers to a dead-end with
>> > their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is
>> not
>> > dropped from gcc11).
>> >
>> > I integrated a toolchain/testsetup to be able to run the gcc testsuite
>> > against a simulated avr target.
>> >
>> > I then used this toolchain to test 2 different existent
>> > non-cc0-avr-backends (from pipcet and saaadhu, both github).
>> >
>> > The result is that saaadhu's backend seems to be working 100%. It has
>> > identical testsuite results with the existing (but deprecated)
>> cc0-backend,
>> > which means that it can be used "as-is" for inclusion in gcc11.
>> >
>> > Please note that I did this work in context of a bounty @ bountysouce,
>> more
>> > information within the issue:
>> >
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
>> Hi,
>>
>> I tested the trees you have given with my own AVR test setup [1]. I
>> confirm
>> your results:
>>   - saaadhu's tree does not introduce any regressions.
>>
>
> ok
>
>   - pipcet's tree has 142 gcc and 299 g++ regressions (although many of
>> them
>> are duplicates, e.g. same test case with different optimization
>> levels).
>>
>> It's a bit awkward to copy gcc/config/avr into a mainline tree
>
>
> Possibly a matter of preference, but when I'm insecure, I prefer low-level
> ops (e.g. filesystem).
>
>
>> Looking at their github history, both authors made some small changes in
>> other areas.
>
>
> saaadhu has one change, already in upstream:
> https://github.com/saaadhu/gcc-avr-cc0/issues/1
>
> I don't remember why choose to ignored the 2 changes (outside
> gcc/config/avr) of pipcet's.
>
> I'll repeat the test-run later with the two files recreated.
>

3 files are changed outside config/avr.

testresults are the same on my side (applying / not applying the 3
additional patches).


>
> I would have prefered to cherry-pick or apply patches.
>>
> [...]
>

I added the patches:

https://github.com/abebeos/avr-gnu/tree/master/patches

 (see comment in cp-avr-*  : "#TD: nonsense script, use a direct git
> checkout")
>
> https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-avr.sh
>>
>
> Nice one, this is kind of what I was asking for within
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c11
>
> before going on to integrate an own one.
>
> But the main thing is anyways:
>
> " - saaadhu's tree does not introduce any regressions"
>
>
>
>
>

Re: [PATCH] avr: cc0 to mode_cc conversion

[abebeos via Gcc-patches]

On Sun, 13 Dec 2020 at 20:51, Georg-Johann Lay  wrote:

> > (I really tried to follow this
> https://gcc.gnu.org/contribute.html#patches,
> > but my stomach)
> >
> > Hi there all!
> >
> > The attached patch contains a new avr-backend, stripped from cc0.
> >
> > The author is gcc maintainer Snethil Kumar Selvaraj (saaadhu),
>
> Hi, AFAIK Senthil has write-after-approval state.  The only avr
> maintainer, at least according to MAINTAINERS, is still Denis, cf.
>
>
> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=MAINTAINERS;h=32f8a2b72923b791f9687d6a2d555a1780535078;hb=HEAD#l59
>
> I allowed me CCing them.
>
> > the source can be found here:
> >
> > https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed
> >
> > The gcc/g++ testsuites show zero regressions, tested with:
> >
> > https://github.com/abebeos/avr-gnu
> >
> > and confirmed with another testsetup, see:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561489.html
> >
> > Some more background information within:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561668.html
> >
> > and
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
> >
> > (i have this dark feeling that I did the patch submission wrong...
> pressing
> > Send anyways!)
>

(hey, "between us": where did my real-name came from in your email? I
choosed to appear here with an alias "abebeos" - not that it's difficult to
find my real name, but still, it's my choice...)


>
> Sometimes it's more convenient to have a .diff text file, but I don't
> see anything wrong with your submission.


ok

And what it really nice to
> have hunks defined for "(define_" or "^(define_") in your git diff
> setup.  That way it's easier to track in which entity of the machine
> description a change is located.  Just like when you have a change
> in the middle of a long C function, and the diff chunk spells out
> the C function in which it is located.
>

ok

> diff --git a/gcc/config/avr/avr-dimode.md b/gcc/config/avr/avr-dimode.md
>
[...] - (review)

Thank you for taking the time to review.

The author (currently not available) assessed the work as "semi working":

The (lets say) integrator (me), assessed the work as "good enough" - given
status of the gcc10 avr-backend this should be the prioriity (saving it
from extinction).

Possibly all details should be ignored for now, thus it can be merged.

My process/decision (given circumstances) is to "not touch even whitespace"
in the 0-regression-patch.

So, what remains for me now is to produce a tiny document for the
bounty-backers, and just hope that the folks here finds peace to do
the right thing.

Over

a
n
d

Out!

.

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Fri, 11 Dec 2020 at 20:32, Jeff Law  wrote:

>
>
> On 12/9/20 6:12 AM, abebeos via Gcc-patches wrote:
> > Essence:
> >
> > I need a confirmation that the testsuite setup as presented in:
> >
> > https://github.com/abebeos/avr-gnu
> >
> > works fine.
> >
> > The problem with the avr target is that the testsuite cannot be run
> easily,
> > mainly because of the need for a special simulated-target setup, which
> does
> > not work for avr as documented. This led developers to a dead-end with
> > their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is not
> > dropped from gcc11).
> >
> > I integrated a toolchain/testsetup to be able to run the gcc testsuite
> > against a simulated avr target.
> >
> > I then used this toolchain to test 2 different existent
> > non-cc0-avr-backends (from pipcet and saaadhu, both github).
> >
> > The result is that saaadhu's backend seems to be working 100%. It has
> > identical testsuite results with the existing (but deprecated)
> cc0-backend,
> > which means that it can be used "as-is" for inclusion in gcc11.
> >
> > Please note that I did this work in context of a bounty @ bountysouce,
> more
> > information within the issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> I haven't looked at the github repo.  But I do have a couple comments here.
>
> First, the author of the changes (pipcet and saaadhu) need to have
> copyright assignments on file with the FSF.  Otherwise we can not use
> their work at all.
>
> Second, the work needs to be submitted for inclusion.  I don't recall
> seeing an official submission from either of them to gcc-patches.
>
> I'm definitely curious about the testing setup and whether or not it can
> be replicated into our Jenkins setup.


Where can I find this Jenkins setup?

It is my understanding there is
> no newlib support for avr so I'm curious what you're using for a basic
> runtime library.
>
> jeff
>
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Sat, 12 Dec 2020 at 01:15, Segher Boessenkool 
wrote:

> On Fri, Dec 11, 2020 at 11:20:01PM +0200, abebeos wrote:
> > Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
> > seg...@kernel.crashing.org> έγραψε:
> > > > Ok, to speed things up, is it ok if I simply pick the patch that I've
> > > > attached to the issue:
> > > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c21
> > >
> > > I see no patch attached there?  Just a link to github.
> >
> > sorry, it's on top of the issue.
> >
> > direct link:
> > https://gcc.gnu.org/bugzilla/attachment.cgi?bugid=92729=viewall
>
> Ah, you linked to comment 21, so I only looked in that comment :-)
>
> > > I'd ask the original author, but it seems he's busy with other work,
> so to
> > > > avoid delays...
> > >
> > > Please try to ask him first?  That is always nice,
> >
> > contacted days ago both authors via email (naturally closing with "feel
> > free to  ignore if you're busy"), pip replied, saa not. Though both are
> on
> > the cc of the issue, too.
>
> Let's hope he replies soon after you post it.


Here it is:

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561718.html

My understanding is that patches are neutral (no signature, no names), so
if saaadhu signs it off and commits it, all will be fine (legal and ethics).


> We aren't in a super
> hurry of course, most of the work is done after all and GCC 12
> development won't start until months from now.
>

The only ones in hurry a those who want to get "closure" (that's me: it
ends, when it's merged in main/upstream), and of course those who want to
claim the bounty (poor me, again, and possibly some others).

(As a sidenote: did you know that Bountysource takes a 10% cut, and pays
out manually "once a week depending on availability of volunteers"?
Super-strange processes, getting closure a bit hellish. See yourself:

*"Note:* The timing here can vary substantially based on volunteer
availability. If your request is still pending after a week or two please send
us a support request  and poke it occasionally
until somebody can get to it"
source:
https://github.com/bountysource/core/wiki/Frequently-Asked-Questions#i-submitted-a-cash-out-request-when-will-i-be-paid

This is worth filing an issue "Consider replacing bountysource with a
faster alternative")


> (Please cc: all interested parties on the patch -- they aren't on this
> mail thread either?)
>

Not sure I understand: you mean that the traffic on gcc-patches is so huge,
than one needs to ping interested parties via cc?


Segher
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
seg...@kernel.crashing.org> έγραψε:

> On Fri, Dec 11, 2020 at 10:16:44PM +0200, abebeos wrote:
> > Στις Παρ, 11 Δεκ 2020 στις 10:02 μ.μ., ο/η Segher Boessenkool <
> > seg...@kernel.crashing.org> έγραψε:
> > > > My understanding of "non-FSF world-legals" is that something that is
> > > > already released/assigned needs no submission.
> > >
> > > It's not just that: all patches should hit gcc-patches@.  For
> > > transparency, and so that everyone can easily comment on it.
> > >
> > > If someone has published a modified GCC anywhere public, anyone can
> > > take that code.  That is how the GPL works.
> > >
> > > But we still need it on gcc-patches to review it :-)
> >
> > Ok, to speed things up, is it ok if I simply pick the patch that I've
> > attached to the issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c21
>
> I see no patch attached there?  Just a link to github.
>

sorry, it's on top of the issue.

direct link:
https://gcc.gnu.org/bugzilla/attachment.cgi?bugid=92729=viewall


>
> > and post it here to the gcc-patches list within at [PATCH] tagged new
> topic?
>
> Yes, all patches should always be a new thread.  Multiple versions of a
> series in one thread is much harder to work with then necessary; and a
> patch somewhere deep in a thread is easily lost or overlooked.
>

ok

> I'd ask the original author, but it seems he's busy with other work, so to
> > avoid delays...
>
> Please try to ask him first?  That is always nice,


contacted days ago both authors via email (naturally closing with "feel
free to  ignore if you're busy"), pip replied, saa not. Though both are on
the cc of the issue, too.



> but you all also need to figure out what to do with the bounty.
>

Yes, the final "drama", but in the end, the bounty-backers decide about any
claims.

If they e.g. decide to hand out the bounty to the patch-producer... well.

Me currently anyways more in "want to get this done" (before my attention
window closes).

Segher
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

Στις Παρ, 11 Δεκ 2020 στις 10:02 μ.μ., ο/η Segher Boessenkool <
seg...@kernel.crashing.org> έγραψε:

> Hi!
>
> Thanks for trying to push this forward.
>
> On Fri, Dec 11, 2020 at 09:49:18PM +0200, abebeos via Gcc-patches wrote:
> > Στις Παρ, 11 Δεκ 2020 στις 8:32 μ.μ., ο/η Jeff Law 
> έγραψε:
> > > On 12/9/20 6:12 AM, abebeos via Gcc-patches wrote:
> > saaadhu (1st choice, zero regressions) should have one, has recently
> > commited something, too:
> >
> >
> https://gcc.gnu.org/git/?p=gcc.git;a=search;h=e7d55c6b8175d81e35f7c0116bbdffccb682;s=Senthil+Kumar+Selvaraj;st=committer
>
> Yes, he is in MAINTAINERS.
>
> > Second, the work needs to be submitted for inclusion.  I don't recall
> > > seeing an official submission from either of them to gcc-patches.
> >
> > My understanding of "non-FSF world-legals" is that something that is
> > already released/assigned needs no submission.
>
> It's not just that: all patches should hit gcc-patches@.  For
> transparency, and so that everyone can easily comment on it.
>
> If someone has published a modified GCC anywhere public, anyone can
> take that code.  That is how the GPL works.
>
> But we still need it on gcc-patches to review it :-)
>

Ok, to speed things up, is it ok if I simply pick the patch that I've
attached to the issue:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c21

and post it here to the gcc-patches list within at [PATCH] tagged new topic?

I'd ask the original author, but it seems he's busy with other work, so to
avoid delays...


> Segher
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

Στις Παρ, 11 Δεκ 2020 στις 8:32 μ.μ., ο/η Jeff Law  έγραψε:

>
>
> On 12/9/20 6:12 AM, abebeos via Gcc-patches wrote:
> > Essence:
> >
> > I need a confirmation that the testsuite setup as presented in:
> >
> > https://github.com/abebeos/avr-gnu
> >
> > works fine.
> >
> > The problem with the avr target is that the testsuite cannot be run
> easily,
> > mainly because of the need for a special simulated-target setup, which
> does
> > not work for avr as documented. This led developers to a dead-end with
> > their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is not
> > dropped from gcc11).
> >
> > I integrated a toolchain/testsetup to be able to run the gcc testsuite
> > against a simulated avr target.
> >
> > I then used this toolchain to test 2 different existent
> > non-cc0-avr-backends (from pipcet and saaadhu, both github).
> >
> > The result is that saaadhu's backend seems to be working 100%. It has
> > identical testsuite results with the existing (but deprecated)
> cc0-backend,
> > which means that it can be used "as-is" for inclusion in gcc11.
> >
> > Please note that I did this work in context of a bounty @ bountysouce,
> more
> > information within the issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> I haven't looked at the github repo.  But I do have a couple comments here.
>
> First, the author of the changes (pipcet and saaadhu) need to have
> copyright assignments on file with the FSF.  Otherwise we can not use
> their work at all.
>

saaadhu (1st choice, zero regressions) should have one, has recently
commited something, too:

https://gcc.gnu.org/git/?p=gcc.git;a=search;h=e7d55c6b8175d81e35f7c0116bbdffccb682;s=Senthil+Kumar+Selvaraj;st=committer

pipcet (2nd choice, some regressions) is willing to release his code, see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c21

saaadhu (like pipcet) is willing to help (was not necessary till now,
technically)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c18


Second, the work needs to be submitted for inclusion.  I don't recall
> seeing an official submission from either of them to gcc-patches.
>

My understanding of "non-FSF world-legals" is that something that is
already released/assigned needs no submission.

E.g., a copyright-agreement that includes future work on the
projects/products code, makes it unnecessary to submit futuer changes: a
publicly available modification is already assigned to the project.

Sometimes gnu/fsf has his own legal thinking, so possibly "submission by
the authors" is a necessity here.

But I don't think that those 2 authors are reluctant to submit their code.

(just those delays...)


>
> I'm definitely curious about the testing setup and whether or not it can
> be replicated into our Jenkins setup.  It is my understanding there is
> no newlib support for avr so I'm curious what you're using for a basic
> runtime library.
>

I think you're asking about avr-libc, but not sure...

( I come from hardware design, niche-machines usually, mostly solo-work, so
I'm used to achieve goals by inhibiting many many stuff to avoid getting
"drowned in complexity", to the point that I look even dumb to others, like
"how can he achieve the goal without knowing...".)

After inhibiting the official docs (which simply don't work with avr), I
evaluated a dozen avr setups, then produced an own setup step by step.

My focus was to have testresults close to those (very few) published in the
mail archives. I got there.

Then, my focus was to achieve a "zero regression" with existing non-cc0
avr-gcc code (I got there, with saaadhu's code).

(eliminating the test-fails would be a next step, after getting the code in
gcc11 and "saving" the avr backend)

CI integration should be possible, really nothing special in my test-setup.



>
> jeff
>
>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

Στις Πέμ, 10 Δεκ 2020 στις 7:42 π.μ., ο/η Dimitar Dimitrov 
έγραψε:

> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches wrote:
> > Essence:
> >
> > I need a confirmation that the testsuite setup as presented in:
> >
> > https://github.com/abebeos/avr-gnu
> >
> > works fine.
> >
> > The problem with the avr target is that the testsuite cannot be run
> easily,
> > mainly because of the need for a special simulated-target setup, which
> does
> > not work for avr as documented. This led developers to a dead-end with
> > their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is not
> > dropped from gcc11).
> >
> > I integrated a toolchain/testsetup to be able to run the gcc testsuite
> > against a simulated avr target.
> >
> > I then used this toolchain to test 2 different existent
> > non-cc0-avr-backends (from pipcet and saaadhu, both github).
> >
> > The result is that saaadhu's backend seems to be working 100%. It has
> > identical testsuite results with the existing (but deprecated)
> cc0-backend,
> > which means that it can be used "as-is" for inclusion in gcc11.
> >
> > Please note that I did this work in context of a bounty @ bountysouce,
> more
> > information within the issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> Hi,
>
> I tested the trees you have given with my own AVR test setup [1]. I
> confirm
> your results:
>   - saaadhu's tree does not introduce any regressions.
>   - pipcet's tree has 142 gcc and 299 g++ regressions (although many of
> them
> are duplicates, e.g. same test case with different optimization
> levels).
>
> It's a bit awkward to copy gcc/config/avr into a mainline tree. Looking at
> their github history, both authors made some small changes in other areas.
> I
> would have prefered to cherry-pick or apply patches.
>
> =
> baseline beb9afcaf1466996a301c778596c5df209e7913c
>
> === gcc Summary ===
>
> # of expected passes87504
> # of unexpected failures1105
> # of unexpected successes   15
> # of expected failures  581
> # of unresolved testcases   16786
> # of unsupported tests  5370
>
> === g++ Summary ===
>
> # of expected passes140663
> # of unexpected failures7932
> # of unexpected successes   21
> # of expected failures  620
> # of unresolved testcases   8603
> # of unsupported tests  11305
>

[...]

After "digesting" a bit more your review, I need to thank you for opening
my eyes re "cherrypick" suggestion and... the missing g++ summaries. I need
to update my setup to provide the g++ test-deltas, too. Note that in my
test-setup, more c++ tests pass than in yours, not exactly sure why. It's
in the "unresovled testcases".

=== g++ Summary ===

# of expected passes 146064
# of unexpected failures 8120
# of unexpected successes 21
# of expected failures 624
# of untested testcases 10
# of unresolved testcases 3306
# of unsupported tests 11200


> [1] https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-avr.sh


This contains very nice constructs!

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

Στις Πέμ, 10 Δεκ 2020 στις 7:42 π.μ., ο/η Dimitar Dimitrov 
έγραψε:

> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches wrote:
> > Essence:
> >
> > I need a confirmation that the testsuite setup as presented in:
> >
> > https://github.com/abebeos/avr-gnu
> >
> > works fine.
> >
> > The problem with the avr target is that the testsuite cannot be run
> easily,
> > mainly because of the need for a special simulated-target setup, which
> does
> > not work for avr as documented. This led developers to a dead-end with
> > their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is not
> > dropped from gcc11).
> >
> > I integrated a toolchain/testsetup to be able to run the gcc testsuite
> > against a simulated avr target.
> >
> > I then used this toolchain to test 2 different existent
> > non-cc0-avr-backends (from pipcet and saaadhu, both github).
> >
> > The result is that saaadhu's backend seems to be working 100%. It has
> > identical testsuite results with the existing (but deprecated)
> cc0-backend,
> > which means that it can be used "as-is" for inclusion in gcc11.
> >
> > Please note that I did this work in context of a bounty @ bountysouce,
> more
> > information within the issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> Hi,
>
> I tested the trees you have given with my own AVR test setup [1]. I
> confirm
> your results:
>   - saaadhu's tree does not introduce any regressions.
>

ok

  - pipcet's tree has 142 gcc and 299 g++ regressions (although many of them
> are duplicates, e.g. same test case with different optimization
> levels).
>
> It's a bit awkward to copy gcc/config/avr into a mainline tree


Possibly a matter of preference, but when I'm insecure, I prefer low-level
ops (e.g. filesystem).


> Looking at their github history, both authors made some small changes in
> other areas.


saaadhu has one change, already in upstream:
https://github.com/saaadhu/gcc-avr-cc0/issues/1

I don't remember why choose to ignored the 2 changes (outside
gcc/config/avr) of pipcet's.

I'll repeat the test-run later with the two files recreated.

I would have prefered to cherry-pick or apply patches.
>
[...]

 (see comment in cp-avr-*  : "#TD: nonsense script, use a direct git
checkout")

https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-avr.sh
>

Nice one, this is kind of what I was asking for within

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c11

before going on to integrate an own one.

But the main thing is anyways:

" - saaadhu's tree does not introduce any regressions"

[RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

Essence:

I need a confirmation that the testsuite setup as presented in:

https://github.com/abebeos/avr-gnu

works fine.

The problem with the avr target is that the testsuite cannot be run easily,
mainly because of the need for a special simulated-target setup, which does
not work for avr as documented. This led developers to a dead-end with
their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is not
dropped from gcc11).

I integrated a toolchain/testsetup to be able to run the gcc testsuite
against a simulated avr target.

I then used this toolchain to test 2 different existent
non-cc0-avr-backends (from pipcet and saaadhu, both github).

The result is that saaadhu's backend seems to be working 100%. It has
identical testsuite results with the existing (but deprecated) cc0-backend,
which means that it can be used "as-is" for inclusion in gcc11.

Please note that I did this work in context of a bounty @ bountysouce, more
information within the issue:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35