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

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

[abebeos]

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

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

[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 passes            87504
# of unexpected failures        1105
# of unexpected successes       15
# of expected failures          581
# of unresolved testcases       16786
# of unsupported tests          5370

                === g++ Summary ===

# of expected passes            140663
# of unexpected failures        7932
# of unexpected successes       21
# of expected failures          620
# of unresolved testcases       8603
# of unsupported tests          11305

=================================================
pipcet/avr-ccmode

                === gcc Summary ===

# of expected passes            87463
# of unexpected failures        1221
# of unexpected successes       15
# of expected failures          581
# of unresolved testcases       16799
# of unsupported tests          5359

                === g++ Summary ===

# of expected passes            140529
# of unexpected failures        8205
# of unexpected successes       21
# of expected failures          620
# of unresolved testcases       8607
# of unsupported tests          11301

=================================================
saadhu/avr-cc0
                === gcc Summary ===

# of expected passes            87504
# of unexpected failures        1105
# of unexpected successes       15
# of expected failures          581
# of unresolved testcases       16786
# of unsupported tests          5370

                === g++ Summary ===

# of expected passes            140663
# of unexpected failures        7932
# of unexpected successes       21
# of expected failures          620
# of unresolved testcases       8603
# of unsupported tests          11305

On a side note, I build and test AVR backend in mainline everyday. If there is 
interest from AVR maintainers I can post daily results to gcc-testresults@ 
mailing list.

Regards,
Dimitar

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

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

[Richard Biener]

On Thu, Dec 10, 2020 at 6:42 AM Dimitar Dimitrov <dimitar@dinux.eu> 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 passes            87504
> # of unexpected failures        1105
> # of unexpected successes       15
> # of expected failures          581
> # of unresolved testcases       16786
> # of unsupported tests          5370
>
>                 === g++ Summary ===
>
> # of expected passes            140663
> # of unexpected failures        7932
> # of unexpected successes       21
> # of expected failures          620
> # of unresolved testcases       8603
> # of unsupported tests          11305
>
> =================================================
> pipcet/avr-ccmode
>
>                 === gcc Summary ===
>
> # of expected passes            87463
> # of unexpected failures        1221
> # of unexpected successes       15
> # of expected failures          581
> # of unresolved testcases       16799
> # of unsupported tests          5359
>
>                 === g++ Summary ===
>
> # of expected passes            140529
> # of unexpected failures        8205
> # of unexpected successes       21
> # of expected failures          620
> # of unresolved testcases       8607
> # of unsupported tests          11301
>
> =================================================
> saadhu/avr-cc0
>                 === gcc Summary ===
>
> # of expected passes            87504
> # of unexpected failures        1105
> # of unexpected successes       15
> # of expected failures          581
> # of unresolved testcases       16786
> # of unsupported tests          5370
>
>                 === g++ Summary ===
>
> # of expected passes            140663
> # of unexpected failures        7932
> # of unexpected successes       21
> # of expected failures          620
> # of unresolved testcases       8603
> # of unsupported tests          11305
>
> On a side note, I build and test AVR backend in mainline everyday. If there is
> interest from AVR maintainers I can post daily results to gcc-testresults@
> mailing list.

I'd appreciate such postings, not necessarily daily (if there are no changes).
Also (as usual) for active release branches (say once a week or biweekly
or even monthly).

Without any hints on gcc-testresults its hard to asses whether ports
pass some very basic functionality criteria (AVR is neither primary nor
secondary but shipping totally broken ports isn't in our interest).

Thanks a lot,
Richard.

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

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

[abebeos]

Στις Πέμ, 10 Δεκ 2020 στις 7:42 π.μ., ο/η Dimitar Dimitrov <dimitar@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.

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"

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

[abebeos]

Στις Πέμ, 10 Δεκ 2020 στις 7:42 π.μ., ο/η Dimitar Dimitrov <dimitar@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.
>   - 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 passes            87504
> # of unexpected failures        1105
> # of unexpected successes       15
> # of expected failures          581
> # of unresolved testcases       16786
> # of unsupported tests          5370
>
>                 === g++ Summary ===
>
> # of expected passes            140663
> # of unexpected failures        7932
> # 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)

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

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

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

>
>
> 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=e7d55c6b81733335d81e35f7c0116bbdffccb682;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)

[Segher Boessenkool]

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 <law@redhat.com> έγραψε:
> > 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=e7d55c6b81733335d81e35f7c0116bbdffccb682;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 :-)


Segher

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

[abebeos]

Στις Παρ, 11 Δεκ 2020 στις 10:02 μ.μ., ο/η Segher Boessenkool <
segher@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 <law@redhat.com>
> έγραψε:
> > > 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=e7d55c6b81733335d81e35f7c0116bbdffccb682;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)

[Segher Boessenkool]

On Fri, Dec 11, 2020 at 10:16:44PM +0200, abebeos wrote:
> Στις Παρ, 11 Δεκ 2020 στις 10:02 μ.μ., ο/η Segher Boessenkool <
> segher@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.

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

> 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, but you all also need
to figure out what to do with the bounty.


Segher

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

[abebeos]

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

> On Fri, Dec 11, 2020 at 10:16:44PM +0200, abebeos wrote:
> > Στις Παρ, 11 Δεκ 2020 στις 10:02 μ.μ., ο/η Segher Boessenkool <
> > segher@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&action=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)

[Segher Boessenkool]

On Fri, Dec 11, 2020 at 11:20:01PM +0200, abebeos wrote:
> Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
> segher@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&action=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.  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.

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


Segher

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

[John Paul Adrian Glaubitz]

Hello!

>> 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, but you all also need
> to figure out what to do with the bounty.

Going through the messages in this thread, my suggestion would be to pick
Senthil's conversion as it apparently has no regressions as reported by
Dimitar [1].

Since the largest share of the bounty was donated by Atmel/Microchip, there
might be a conflict of interest as Senthil works for them from what I have
seen on his homepage.

If claiming the bounty should be a problem in this case, I would suggest
that Senthil donates the money for a good cause or maybe puts the money
on a different Bountysource campaign to either benefit GCC (I'm sure there
are enough other areas that could see some love) itself or another open source
project.

Either way, the money is awarded to the individual who did the heavy lifting
and it's important that we keep it that way. Otherwise, there is a risk
that future potential contributors will refrain from picking up the task
from such a Bountysource campaign if there is a reduced chance for them
to claim such a bounty.

After all, the whole idea of Bountysource is to delegate tasks that the
community is interested to being worked on to skilled developers who are
willing to spend a lot of their free time and to give them a small financial
reward in return. Normally, buying developer time for such extensive tasks
is way more expensive, so the community should appreciate anyone willing
to do such work for a comparably little amount of money.

For what it's worth, there are certainly more tasks coming in the future,
so I'd recommend everyone interested in claiming a bounty regularly checking
Bountysource.com (Disclaimer: I'm not affiliated with them, I just chose them
because the seem to be the most popular site) or similar campaign sites for
such offers.

Thanks,
Adrian

> [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561489.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Segher Boessenkool]

Hi!

On Sat, Dec 12, 2020 at 12:17:19PM +0100, John Paul Adrian Glaubitz wrote:
> >> 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, but you all also need
> > to figure out what to do with the bounty.
> 
> Going through the messages in this thread, my suggestion would be to pick
> Senthil's conversion as it apparently has no regressions as reported by
> Dimitar [1].

It is up to the avr maintainer what patch is accepted, of course :-)

> Since the largest share of the bounty was donated by Atmel/Microchip, there
> might be a conflict of interest as Senthil works for them from what I have
> seen on his homepage.

This is something that Senthil can clarify, there is no need to
second-guess it -- there should be no conflict at all if he did it on his
own time, for example.

> If claiming the bounty should be a problem in this case, I would suggest
> that Senthil donates the money for a good cause or maybe puts the money
> on a different Bountysource campaign to either benefit GCC (I'm sure there
> are enough other areas that could see some love) itself or another open source
> project.
> 
> Either way, the money is awarded to the individual who did the heavy lifting
> and it's important that we keep it that way. Otherwise, there is a risk
> that future potential contributors will refrain from picking up the task
> from such a Bountysource campaign if there is a reduced chance for them
> to claim such a bounty.

The individual(s) who wrote the code.  Yes.

> After all, the whole idea of Bountysource is to delegate tasks that the
> community is interested to being worked on to skilled developers who are
> willing to spend a lot of their free time and to give them a small financial
> reward in return. Normally, buying developer time for such extensive tasks
> is way more expensive, so the community should appreciate anyone willing
> to do such work for a comparably little amount of money.

+1.  Well, +100 or such :-)


Segher

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

[abebeos]

On Sat, 12 Dec 2020 at 01:15, Segher Boessenkool <segher@kernel.crashing.org>
wrote:

> On Fri, Dec 11, 2020 at 11:20:01PM +0200, abebeos wrote:
> > Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
> > segher@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&action=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 <support@bountysource.com> 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&cheaper 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)

[Jeff Law]

On 12/12/20 11:33 AM, abebeos wrote:
>
>
> On Sat, 12 Dec 2020 at 01:15, Segher Boessenkool
> <segher@kernel.crashing.org <mailto:segher@kernel.crashing.org>> wrote:
>
>     On Fri, Dec 11, 2020 at 11:20:01PM +0200, abebeos wrote:
>     > Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
>     > segher@kernel.crashing.org <mailto:segher@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
>     <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&action=viewall
>     <https://gcc.gnu.org/bugzilla/attachment.cgi?bugid=92729&action=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
> <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).
The FSF has very specific requirements for copyright assignments.  The
author needs a copyright assignment on file with the FSF and the FSF may
also require their author's employer to sign an employer disclaimer
before the contributions can be accepted.

Jeff

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

[Segher Boessenkool]

On Sun, Dec 13, 2020 at 09:49:25AM -0700, Jeff Law wrote:
> On 12/12/20 11:33 AM, abebeos wrote:
> > Here it is:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561718.html
> > <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 do not do sign-offs.  You need to have a copyright assignment before
you can commit anything, so it would be superfluous.

> The FSF has very specific requirements for copyright assignments.  The
> author needs a copyright assignment on file with the FSF and the FSF may
> also require their author's employer to sign an employer disclaimer
> before the contributions can be accepted.

Senthil already has write-after-approval, and he has committed many
patches to avr/ already.


Segher

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

[abebeos]

On Fri, 11 Dec 2020 at 20:32, Jeff Law <law@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
> >
> > 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)

[Georg-Johann Lay]

On Fri, 11 Dec 2020 at 20:32, Jeff Law <law@redhat.com> wrote:
> I'm definitely curious about the testing setup and whether or not it can
> be replicated into our Jenkins setup.

Hi, Jeff.

The gcc testsuite setup is described in the readme of avrtest:

https://sourceforge.net/p/winavr/code/HEAD/tree/trunk/avrtest/

SourceForge changed code URLs some time ago, thus some links
in the GCC page are outdated and lead to nowhere...

The repo above should be the most recent one, at least it's the place
I am using to commit.


HTH, Johann

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

[abebeos]

On Thu, 10 Dec 2020 at 15:57, abebeos <lazaridis.com+abebeos@gmail.com>
wrote:

>
>
> Στις Πέμ, 10 Δεκ 2020 στις 7:42 π.μ., ο/η Dimitar Dimitrov <
> dimitar@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: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Dimitar Dimitrov]

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

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

[Dimitar Dimitrov]

On четвъртък, 10 декември 2020 г. 10:24:50 EET Richard Biener wrote:
> On Thu, Dec 10, 2020 at 6:42 AM Dimitar Dimitrov <dimitar@dinux.eu> 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 passes            87504
> > # of unexpected failures        1105
> > # of unexpected successes       15
> > # of expected failures          581
> > # of unresolved testcases       16786
> > # of unsupported tests          5370
> > 
> >                 === g++ Summary ===
> > 
> > # of expected passes            140663
> > # of unexpected failures        7932
> > # of unexpected successes       21
> > # of expected failures          620
> > # of unresolved testcases       8603
> > # of unsupported tests          11305
> > 
> > =================================================
> > pipcet/avr-ccmode
> > 
> >                 === gcc Summary ===
> > 
> > # of expected passes            87463
> > # of unexpected failures        1221
> > # of unexpected successes       15
> > # of expected failures          581
> > # of unresolved testcases       16799
> > # of unsupported tests          5359
> > 
> >                 === g++ Summary ===
> > 
> > # of expected passes            140529
> > # of unexpected failures        8205
> > # of unexpected successes       21
> > # of expected failures          620
> > # of unresolved testcases       8607
> > # of unsupported tests          11301
> > 
> > =================================================
> > saadhu/avr-cc0
> > 
> >                 === gcc Summary ===
> > 
> > # of expected passes            87504
> > # of unexpected failures        1105
> > # of unexpected successes       15
> > # of expected failures          581
> > # of unresolved testcases       16786
> > # of unsupported tests          5370
> > 
> >                 === g++ Summary ===
> > 
> > # of expected passes            140663
> > # of unexpected failures        7932
> > # of unexpected successes       21
> > # of expected failures          620
> > # of unresolved testcases       8603
> > # of unsupported tests          11305
> > 
> > On a side note, I build and test AVR backend in mainline everyday. If
> > there is interest from AVR maintainers I can post daily results to
> > gcc-testresults@ mailing list.
> 
> I'd appreciate such postings, not necessarily daily (if there are no
> changes). Also (as usual) for active release branches (say once a week or
> biweekly or even monthly).

I'll start sending biweekly the AVR testresults from all active branches.

Yesterday my test results were temporarily held back due to large email size, 
but eventually reached gcc-testresults@ . I'd like to know if I need to trim 
them somehow.


> 
> Without any hints on gcc-testresults its hard to asses whether ports
> pass some very basic functionality criteria (AVR is neither primary nor
> secondary but shipping totally broken ports isn't in our interest).
> 
> Thanks a lot,
> Richard.
> 
> > Regards,
> > Dimitar
> > 
> > [1] https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-avr.sh

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

[Jeff Law]

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 <dimitar@dinux.eu> 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 passes            87504
>>> # of unexpected failures        1105
>>> # of unexpected successes       15
>>> # of expected failures          581
>>> # of unresolved testcases       16786
>>> # of unsupported tests          5370
>>>
>>>                 === g++ Summary ===
>>>
>>> # of expected passes            140663
>>> # of unexpected failures        7932
>>> # of unexpected successes       21
>>> # of expected failures          620
>>> # of unresolved testcases       8603
>>> # of unsupported tests          11305
>>>
>>> =================================================
>>> pipcet/avr-ccmode
>>>
>>>                 === gcc Summary ===
>>>
>>> # of expected passes            87463
>>> # of unexpected failures        1221
>>> # of unexpected successes       15
>>> # of expected failures          581
>>> # of unresolved testcases       16799
>>> # of unsupported tests          5359
>>>
>>>                 === g++ Summary ===
>>>
>>> # of expected passes            140529
>>> # of unexpected failures        8205
>>> # of unexpected successes       21
>>> # of expected failures          620
>>> # of unresolved testcases       8607
>>> # of unsupported tests          11301
>>>
>>> =================================================
>>> saadhu/avr-cc0
>>>
>>>                 === gcc Summary ===
>>>
>>> # of expected passes            87504
>>> # of unexpected failures        1105
>>> # of unexpected successes       15
>>> # of expected failures          581
>>> # of unresolved testcases       16786
>>> # of unsupported tests          5370
>>>
>>>                 === g++ Summary ===
>>>
>>> # of expected passes            140663
>>> # of unexpected failures        7932
>>> # of unexpected successes       21
>>> # of expected failures          620
>>> # of unresolved testcases       8603
>>> # of unsupported tests          11305
>>>
>>> On a side note, I build and test AVR backend in mainline everyday. If
>>> there is interest from AVR maintainers I can post daily results to
>>> gcc-testresults@ mailing list.
>> I'd appreciate such postings, not necessarily daily (if there are no
>> changes). Also (as usual) for active release branches (say once a week or
>> biweekly or even monthly).
> I'll start sending biweekly the AVR testresults from all active branches.
>
> Yesterday my test results were temporarily held back due to large email size, 
> but eventually reached gcc-testresults@ . I'd like to know if I need to trim 
> them somehow.
You might consider using contrib/compare_tests rather than dumping the
entire results to the list.  compare_tests focuses on things that
changed from one run to the next.  So you need to keep the results from
the prior run for comparison purposes.

Jeff

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

[abebeos]

On Tue, 15 Dec 2020 at 04:01, Jeff Law <law@redhat.com> 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 <dimitar@dinux.eu>
> 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 passes            87504
> >>> # of unexpected failures        1105
> >>> # of unexpected successes       15
> >>> # of expected failures          581
> >>> # of unresolved testcases       16786
> >>> # of unsupported tests          5370
> >>>
> >>>                 === g++ Summary ===
> >>>
> >>> # of expected passes            140663
> >>> # of unexpected failures        7932
> >>> # of unexpected successes       21
> >>> # of expected failures          620
> >>> # of unresolved testcases       8603
> >>> # of unsupported tests          11305
> >>>
> >>> =================================================
> >>> pipcet/avr-ccmode
> >>>
> >>>                 === gcc Summary ===
> >>>
> >>> # of expected passes            87463
> >>> # of unexpected failures        1221
> >>> # of unexpected successes       15
> >>> # of expected failures          581
> >>> # of unresolved testcases       16799
> >>> # of unsupported tests          5359
> >>>
> >>>                 === g++ Summary ===
> >>>
> >>> # of expected passes            140529
> >>> # of unexpected failures        8205
> >>> # of unexpected successes       21
> >>> # of expected failures          620
> >>> # of unresolved testcases       8607
> >>> # of unsupported tests          11301
> >>>
> >>> =================================================
> >>> saadhu/avr-cc0
> >>>
> >>>                 === gcc Summary ===
> >>>
> >>> # of expected passes            87504
> >>> # of unexpected failures        1105
> >>> # of unexpected successes       15
> >>> # of expected failures          581
> >>> # of unresolved testcases       16786
> >>> # of unsupported tests          5370
> >>>
> >>>                 === g++ Summary ===
> >>>
> >>> # of expected passes            140663
> >>> # of unexpected failures        7932
> >>> # of unexpected successes       21
> >>> # of expected failures          620
> >>> # of unresolved testcases       8603
> >>> # of unsupported tests          11305
> >>>
> >>> On a side note, I build and test AVR backend in mainline everyday. If
> >>> there is interest from AVR maintainers I can post daily results to
> >>> gcc-testresults@ mailing list.
> >> I'd appreciate such postings, not necessarily daily (if there are no
> >> changes). Also (as usual) for active release branches (say once a week
> or
> >> biweekly or even monthly).
> > I'll start sending biweekly the AVR testresults from all active branches.
> >
> > Yesterday my test results were temporarily held back due to large email
> size,
> > but eventually reached gcc-testresults@ . I'd like to know if I need to
> trim
> > them somehow.
> You might consider using contrib/compare_tests rather than dumping the
> entire results to the list.  compare_tests focuses on things that
> changed from one run to the next.  So you need to keep the results from
> the prior run for comparison purposes.
>

2 remarks here:

* contrib/compare_tests produced some strange/inconsistent results during
my avr regression tests, so check it first. I switched to
contrib/dg-cmp-results for the regressions.

* it looks like the list gcc-testresults expects the results created
from contrib/test_summary
(if i remember it lists only the failures), and the list gcc-regression
only(!) the regressions.

https://gcc.gnu.org/lists.html
- * gcc-testresults <https://gcc.gnu.org/ml/gcc-testresults/>* is a
moderate volume list where test results for the GCC compilers are posted.
- *gcc-regression <https://gcc.gnu.org/ml/gcc-regression/>* is a moderate
volume list where regression results for the GCC compilers are posted.

- Note that me a newcomer, so possibly I got something wrong.


> Jeff
>
>

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

[Dimitar Dimitrov]

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.


=================================================
baseline beb9afcaf1466996a301c778596c5df209e7913c
                === gcc Summary ===

# of expected passes            105527
# of unexpected failures        584
# of unexpected successes       16
# of expected failures          582
# of untested testcases         2
# of unresolved testcases       33
# of unsupported tests          5031

                === g++ Summary ===

# of expected passes            146432
# of unexpected failures        8012
# of unexpected successes       21
# of expected failures          624
# of untested testcases         10
# of unresolved testcases       3174
# of unsupported tests          11112


=================================================
pipcet/avr-ccmode
                === gcc Summary ===

# of expected passes            105431
# of unexpected failures        709
# of unexpected successes       16
# of expected failures          582
# of untested testcases         2
# of unresolved testcases       69
# of unsupported tests          5032

                === g++ Summary ===

# of expected passes            146229
# of unexpected failures        8291
# of unexpected successes       21
# of expected failures          624
# of untested testcases         10
# of unresolved testcases       3236
# of unsupported tests          11112

=================================================
saadhu/avr-cc0
                === gcc Summary ===

# of expected passes            105527
# of unexpected failures        584
# of unexpected successes       16
# of expected failures          582
# of untested testcases         2
# of unresolved testcases       33
# of unsupported tests          5031

                === g++ Summary ===

# of expected passes            146432
# of unexpected failures        8012
# of unexpected successes       21
# of expected failures          624
# of untested testcases         10
# of unresolved testcases       3174
# of unsupported tests          11112

Regards,
Dimitar

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

[abebeos]

+cc: Law, Biener,
On Wed, 16 Dec 2020 at 20:27, Dimitar Dimitrov <dimitar@dinux.eu> 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 passes            105527
> # of unexpected failures        584
> # of unexpected successes       16
> # of expected failures          582
> # of untested testcases         2
> # of unresolved testcases       33
> # of unsupported tests          5031
>
>                 === g++ Summary ===
>
> # of expected passes            146432
> # of unexpected failures        8012
> # of unexpected successes       21
> # of expected failures          624
> # of untested testcases         10
> # of unresolved testcases       3174
> # of unsupported tests          11112
>
>
> =================================================
> pipcet/avr-ccmode
>                 === gcc Summary ===
>
> # of expected passes            105431
> # of unexpected failures        709
> # of unexpected successes       16
> # of expected failures          582
> # of untested testcases         2
> # of unresolved testcases       69
> # of unsupported tests          5032
>
>                 === g++ Summary ===
>
> # of expected passes            146229
> # of unexpected failures        8291
> # of unexpected successes       21
> # of expected failures          624
> # of untested testcases         10
> # of unresolved testcases       3236
> # of unsupported tests          11112
>
> =================================================
> saadhu/avr-cc0
>                 === gcc Summary ===
>
> # of expected passes            105527
> # of unexpected failures        584
> # of unexpected successes       16
> # of expected failures          582
> # of untested testcases         2
> # of unresolved testcases       33
> # of unsupported tests          5031
>
>                 === g++ Summary ===
>
> # of expected passes            146432
> # of unexpected failures        8012
> # of unexpected successes       21
> # of expected failures          624
> # of untested testcases         10
> # of unresolved testcases       3174
> # of unsupported tests          11112
>
> Regards,
> Dimitar
>
>
>

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

[abebeos]

On Wed, 16 Dec 2020 at 22:44, abebeos <lazaridis.com+abebeos@gmail.com>
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]

On Fri, 11 Dec 2020 at 23:20, abebeos <lazaridis.com+abebeos@gmail.com>
wrote:

> Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
> segher@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]

On Sun, 13 Dec 2020 at 20:14, abebeos <lazaridis.com+abebeos@gmail.com>
wrote:

>
>
> On Fri, 11 Dec 2020 at 20:32, Jeff Law <law@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
>> >
>> > 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: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Jeff Law]

On 12/23/20 9:01 AM, abebeos wrote:
>
>
> On Sun, 13 Dec 2020 at 20:14, abebeos <lazaridis.com
> <http://lazaridis.com>+abebeos@gmail.com <mailto:abebeos@gmail.com>>
> wrote:
>
>
>
>     On Fri, 11 Dec 2020 at 20:32, Jeff Law <law@redhat.com
>     <mailto:law@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

jeff

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

[abebeos]

On Wed, 30 Dec 2020 at 05:41, Jeff Law <law@redhat.com> wrote:

>
>
> On 12/23/20 9:01 AM, abebeos wrote:
> >
> >
> > On Sun, 13 Dec 2020 at 20:14, abebeos <lazaridis.com
> > <http://lazaridis.com>+abebeos@gmail.com <mailto:abebeos@gmail.com>>
> > wrote:
> >
> >
> >
> >     On Fri, 11 Dec 2020 at 20:32, Jeff Law <law@redhat.com
> >     <mailto:law@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)

[Jeff Law]

On 12/31/20 7:13 AM, abebeos wrote:
>
>
> On Wed, 30 Dec 2020 at 05:41, Jeff Law <law@redhat.com
> <mailto:law@redhat.com>> wrote:
>
>
>
>     On 12/23/20 9:01 AM, abebeos wrote:
>     >
>     >
>     > On Sun, 13 Dec 2020 at 20:14, abebeos <lazaridis.com
>     <http://lazaridis.com>
>     > <http://lazaridis.com <http://lazaridis.com>>+abebeos@gmail.com
>     <mailto:abebeos@gmail.com> <mailto:abebeos@gmail.com
>     <mailto:abebeos@gmail.com>>>
>     > wrote:
>     >
>     >
>     >
>     >     On Fri, 11 Dec 2020 at 20:32, Jeff Law <law@redhat.com
>     <mailto:law@redhat.com>
>     >     <mailto:law@redhat.com <mailto:law@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>
>     >         <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>
>     >         <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 <http://gcc.gnu.org/jenkins>
>
>
> (sidenote: This resolves on my side to the (insecure)
> http://3.14.90.209:8080/ <http://3.14.90.209:8080/>)
Yup.

>
> Is the source-code of  http://gcc.gnu.org/jenkins
> <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

jeff

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

[abebeos]

On Mon, 4 Jan 2021 at 21:40, Jeff Law <law@redhat.com> 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 <http://gcc.gnu.org/jenkins>
> >
> >
> > (sidenote: This resolves on my side to the (insecure)
> > http://3.14.90.209:8080/ <http://3.14.90.209:8080/>)
> Yup.
>
> >
> > Is the source-code of  http://gcc.gnu.org/jenkins
> > <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)

[Jeff Law]

On 1/5/21 2:18 AM, abebeos wrote:
>
> On Mon, 4 Jan 2021 at 21:40, Jeff Law <law@redhat.com
> <mailto:law@redhat.com>> 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 <http://gcc.gnu.org/jenkins>
>     <http://gcc.gnu.org/jenkins <http://gcc.gnu.org/jenkins>>
>     >
>     >
>     > (sidenote: This resolves on my side to the (insecure)
>     > http://3.14.90.209:8080/ <http://3.14.90.209:8080/>
>     <http://3.14.90.209:8080/ <http://3.14.90.209:8080/>>)
>     Yup.
>
>     >
>     > Is the source-code of  http://gcc.gnu.org/jenkins
>     <http://gcc.gnu.org/jenkins>
>     > <http://gcc.gnu.org/jenkins <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 <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.

Jeff

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

[abebeos]

On Tue, 5 Jan 2021 at 18:50, Jeff Law <law@redhat.com> wrote:

>
>
> On 1/5/21 2:18 AM, abebeos wrote:
> >
> > On Mon, 4 Jan 2021 at 21:40, Jeff Law <law@redhat.com
> > <mailto:law@redhat.com>> 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 <http://gcc.gnu.org/jenkins>
> >     <http://gcc.gnu.org/jenkins <http://gcc.gnu.org/jenkins>>
> >     >
> >     >
> >     > (sidenote: This resolves on my side to the (insecure)
> >     > http://3.14.90.209:8080/ <http://3.14.90.209:8080/>
> >     <http://3.14.90.209:8080/ <http://3.14.90.209:8080/>>)
> >     Yup.
> >
> >     >
> >     > Is the source-code of  http://gcc.gnu.org/jenkins
> >     <http://gcc.gnu.org/jenkins>
> >     > <http://gcc.gnu.org/jenkins <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 <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)

[Jeff Law]

On 1/5/21 10:09 AM, abebeos wrote:
>
>
> On Tue, 5 Jan 2021 at 18:50, Jeff Law <law@redhat.com
> <mailto:law@redhat.com>> wrote:
>
>
>
>     On 1/5/21 2:18 AM, abebeos wrote:
>     >
>     > On Mon, 4 Jan 2021 at 21:40, Jeff Law <law@redhat.com
>     <mailto:law@redhat.com>
>     > <mailto:law@redhat.com <mailto:law@redhat.com>>> 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
>     <http://gcc.gnu.org/jenkins> <http://gcc.gnu.org/jenkins
>     <http://gcc.gnu.org/jenkins>>
>     >     <http://gcc.gnu.org/jenkins <http://gcc.gnu.org/jenkins>
>     <http://gcc.gnu.org/jenkins <http://gcc.gnu.org/jenkins>>>
>     >     >
>     >     >
>     >     > (sidenote: This resolves on my side to the (insecure)
>     >     > http://3.14.90.209:8080/ <http://3.14.90.209:8080/>
>     <http://3.14.90.209:8080/ <http://3.14.90.209:8080/>>
>     >     <http://3.14.90.209:8080/ <http://3.14.90.209:8080/>
>     <http://3.14.90.209:8080/ <http://3.14.90.209:8080/>>>)
>     >     Yup.
>     >
>     >     >
>     >     > Is the source-code of  http://gcc.gnu.org/jenkins
>     <http://gcc.gnu.org/jenkins>
>     >     <http://gcc.gnu.org/jenkins <http://gcc.gnu.org/jenkins>>
>     >     > <http://gcc.gnu.org/jenkins <http://gcc.gnu.org/jenkins>
>     <http://gcc.gnu.org/jenkins <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
>     <http://jenkins.io> <http://jenkins.io <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.)?
You're not going to be able to change the scripts.   BUt they are
accessable from the web site.  They're not in GIT or anything like that.

jeff

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

[Rainer Orth]

Hi Jeff,

> On 1/5/21 10:09 AM, abebeos wrote:
>>
>>
>> On Tue, 5 Jan 2021 at 18:50, Jeff Law <law@redhat.com
>> <mailto:law@redhat.com>> wrote:
>>
>>
>>
>>     On 1/5/21 2:18 AM, abebeos wrote:
>>     >
>>     > On Mon, 4 Jan 2021 at 21:40, Jeff Law <law@redhat.com
>>     <mailto:law@redhat.com>
>>     > <mailto:law@redhat.com <mailto:law@redhat.com>>> 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
>>     <http://gcc.gnu.org/jenkins> <http://gcc.gnu.org/jenkins
>>     <http://gcc.gnu.org/jenkins>>
>>     >     <http://gcc.gnu.org/jenkins <http://gcc.gnu.org/jenkins>
>>     <http://gcc.gnu.org/jenkins <http://gcc.gnu.org/jenkins>>>
>>     >     >
>>     >     >
>>     >     > (sidenote: This resolves on my side to the (insecure)
>>     >     > http://3.14.90.209:8080/ <http://3.14.90.209:8080/>
>>     <http://3.14.90.209:8080/ <http://3.14.90.209:8080/>>
>>     >     <http://3.14.90.209:8080/ <http://3.14.90.209:8080/>
>>     <http://3.14.90.209:8080/ <http://3.14.90.209:8080/>>>)
>>     >     Yup.
>>     >
>>     >     >
>>     >     > Is the source-code of  http://gcc.gnu.org/jenkins
>>     <http://gcc.gnu.org/jenkins>
>>     >     <http://gcc.gnu.org/jenkins <http://gcc.gnu.org/jenkins>>
>>     >     > <http://gcc.gnu.org/jenkins <http://gcc.gnu.org/jenkins>
>>     <http://gcc.gnu.org/jenkins <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
>>     <http://jenkins.io> <http://jenkins.io <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.)?
> You're not going to be able to change the scripts.   BUt they are
> accessable from the web site.  They're not in GIT or anything like that.

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.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

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

[Jeff Law]

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.

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)

[Rainer Orth]

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.

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

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]

On Tue, 5 Jan 2021 at 21:25, Rainer Orth <ro@cebitec.uni-bielefeld.de>
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]

On Tue, 5 Jan 2021 at 20:24, Jeff Law <law@redhat.com> 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
>
>