Bug 92729 - [avr] Convert the backend to MODE_CC so it can be kept in future releases
Summary: [avr] Convert the backend to MODE_CC so it can be kept in future releases
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 10.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: https://www.bountysource.com/issues/8...
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-29 14:38 UTC by John Paul Adrian Glaubitz
Modified: 2021-02-06 15:21 UTC (History)
11 users (show)

See Also:
Host:
Target: avr-*-*
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-01-30 00:00:00


Attachments
Patch by Senthil Kumar Selvaraj, non-cc0-avr-backend (37.13 KB, patch)
2020-12-04 19:31 UTC, abebeos
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Paul Adrian Glaubitz 2019-11-29 14:38:00 UTC
This is a tracker bug for the convert the avr backend from CC0 to MODE_CC so it can be kept in future releases.

See: https://gcc.gnu.org/wiki/CC0Transition

I will be using this bug report to create a bounty on BountySource.com.

We have already successfully funded such a conversion for the m68k backend, see #91851.
Comment 1 Tobias Burnus 2020-02-24 16:02:12 UTC
(In reply to John Paul Adrian Glaubitz from comment #0)
> We have already successfully funded such a conversion for the m68k backend,
> see #91851.
PR 91851.

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

Regarding the deprecation, see
  https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
and the follow up remark regarding the deprecation at
  https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01773.html


[BTW: cris is being converted in the GIT branch vendors/axis/cris-decc0, scheduled for GCC 11 Stage 1. m68k has been converted and is in GCC 10. h8300, cr16 and vax are still deprecated. For h8300, see also https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02068.html]

[Side remark: once MODE_CC is used, at some point the register allocator should also be changed from 'reload' to LRA, cf. https://gcc.gnu.org/wiki/LRAIsDefault ; for now, only CC0 was suggested to be deprecated in GCC 10 and scheduled for removal in GCC 11.]
Comment 2 Max 2020-05-22 04:53:00 UTC
I am interested in working on this, because it would be a big shame to see AVR support dropped from GCC. However, while I studied computer science at university and of course have decent experience with the AVR platform, I do not have a background in compilers nor have ever contributed to GCC before.

I have read some of the GCC internals manual and browsed around the source tree, including gcc/config/avr, but I am still missing out on some foundational understanding of how everything fits together inside GCC. 

Is there anyone more familiar with GCC internals and/or the AVR backend who I would be able to consult or possibly work with on this?
Comment 3 John Paul Adrian Glaubitz 2020-05-22 06:26:24 UTC
(In reply to Max from comment #2)
> Is there anyone more familiar with GCC internals and/or the AVR backend who
> I would be able to consult or possibly work with on this?

I think Jeff Law mentioned on the gcc-patches mailing list that he would be willing to answer questions and assist anyone willing to work on MODE_CC conversion.

So, I would ask on the list: https://gcc.gnu.org/mailman/listinfo/gcc-patches
Comment 4 Tobias Burnus 2020-05-22 08:44:41 UTC
See also https://gcc.gnu.org/pipermail/gcc/2020-April/thread.html#402 (for details/current status, ask those involved).
Comment 5 pipcet 2020-07-29 23:16:14 UTC
I'm interested in working on this.

There's some initial code at https://github.com/gcc-mirror/gcc/compare/master...pipcet:avr-ccmode

I've followed the instructions at https://gcc.gnu.org/wiki/CC0Transition . I believe AVR is an architecture which fits case #2 best: reload requires arithmetic insns which clobber condition codes.

I decided to add explicit CC clobbers to the patterns for most insns rather than relying on a post-reload splitter adding the CC clobbers, mostly because that seemed simpler.

I've used a single REG_CC register in an 8-bit CCmode, representing all bits of SREG except for the interrupt flag. (Once things are up and running, I plan to investigate whether it's worth it to treat the carry flag and the transfer bit separately).

The current state is that most code, particularly the gcc.c-torture/compile/ collection, appears to compile, but I haven't run the execution tests to figure out what's working and what isn't.
Comment 6 pipcet 2020-08-04 16:54:20 UTC
I've just pushed here

https://github.com/gcc-mirror/gcc/compare/master...pipcet:avr-ccmode-20200804?expand=1

the current state of my work as a series of git commits, sorted roughly from large, mechanical, important changes to small, controversial, cosmetic ones.

I'm facing some problems:

1. It's hard to test. The test suite compiles okay, and I've tricked simulavr into executing some test cases, but it's not as easy as simply running the test suite, unless I'm missing something.

2. The assembler code often changes more than I thought it would. This makes diffing it somewhat tedious.

3. Some peepholes need careful scrutiny. These are things like:

(define_peephole ; "*cpse.eq"
  [(set (cc0)
        (compare (match_operand:ALL1 1 "register_operand" "r,r")
                 (match_operand:ALL1 2 "reg_or_0_operand" "r,Y00")))
   (set (pc)
        (if_then_else (eq (cc0)
                          (const_int 0))
                      (label_ref (match_operand 0 "" ""))
                      (pc)))]
  "jump_over_one_insn_p (insn, operands[0])"
  "@
	cpse %1,%2
	cpse %1,__zero_reg__")

This replaces a flag-setting instruction plus a conditional branch with a non-flag-setting conditional skip. Modifying only the obvious bits, this would result in broken code which relied on the state of the CC flags after the branch insn.

My current idea is to add a peephole2 pattern which adds a clobber of the CC register to jump insns which don't need to preserve it, then require that extra clobber in the above peephole. Not perfect, but it should catch most cases.

However, I'm unsure whether the approach of defining

(define_peephole2
  [(set (pc) (if_then_else (match_operator 0 "ordered_comparison_operator"
					   [(reg:CC REG_CC) (const_int 0)])
			   (match_operand 1)
			   (match_operand 2)))]
  "peep2_reg_dead_p (1, gen_rtx_REG (CCmode, REG_CC))"
  [(parallel [(set (pc) (if_then_else (match_dup 0)
				      (match_dup 1)
				      (match_dup 2)))
	      (clobber (reg:CC REG_CC))])])

is safe: if I'm looking at things correctly, peep2_reg_dead_p checks whether the register is live in the instruction following the jump in the insn stream, not the insn that the jump potentially goes to.

The good news is that I believe I've worked around the actual code quality problems sufficiently for the patch set as it stands to be a good alternative to dropping the AVR port.

I'd be really grateful for advice on how to test and improve this. Is there a test suite somewhere that I've missed? Ideally, one that works with a free simulator?
Comment 7 John Paul Adrian Glaubitz 2020-08-06 22:40:43 UTC
> I'd be really grateful for advice on how to test and improve this. Is there a test suite somewhere that I've missed? Ideally, one that works with a free simulator?

Probably best to ask on the gcc-patches mailing list or one of the AVR forums (avrfreaks maybe).
Comment 8 Jonathan Wakely 2020-10-09 15:54:58 UTC
And please ping patches like https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552844.html if you don't get a review.
Comment 9 abebeos 2020-11-10 16:38:24 UTC
Looking into this since a few days. All looks that B.S. statements seem valid:

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

The bounty goal should be similar to "Convert m68k to not use cc0":

=> Convert avr to not use cc0 (thus it can be included to gcc11).

So, the requirements would be:

- must not use cc0
- keep generated code as much as possible identical (= avoid trouble and follow-up work)
- use of MODE_CC constructs is optional

-

P.S.: It looks like previous work on this from "pipcet" got stuck, possibly exactly due to the complexity that a larger one-chunk-change introduces, especially when the resulting generated code changes much:

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

So, if it's ok for the backers, reduce the scope of the bounty to "just get avr into gcc11 and keep generated code as much as possible unchanged".
Comment 10 John Paul Adrian Glaubitz 2020-11-10 16:45:53 UTC
(In reply to abebeos from comment #9)
> So, if it's ok for the backers, reduce the scope of the bounty to "just get
> avr into gcc11 and keep generated code as much as possible unchanged".

It would be gcc11 and beyond that, not just gcc11.

FWIW, I talked to multiple GCC developers and they confirmed that converting the target to MODE_CC should be possible.

The main problem is apparently that the target hasn't been properly worked on for a long time.

Also, be aware that there are others working on this such as:

> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551504.html

Good luck!
Comment 11 abebeos 2020-11-11 13:57:32 UTC
(In reply to John Paul Adrian Glaubitz from comment #10)
[...]
> The main problem is apparently that the target hasn't been properly worked
> on for a long time.
[...]

Yes, this seems to result in this barrier:

=> missing stable development environment for the work on the avr backend itself (build/test/simulate).

So this issue here splits into 3 major steps:

A) create a stable dev environment fro work on the avr backend
B) remove deprecated cc0 from avr backend (gcc11 requirement, main issue&bounty), without necessarily using MODE_CC (similar to m68k)
C) (optional) convert code to MODE_CC

Seeing that the microchip custom version uses 5.x gcc and with different dependencies than the original code, step A could already become a multi month effort.

If anyone knows a "stable starting point" (for developing on the avr backend), please point to it (ideally a public repo containing all).
Comment 12 Georg-Johann Lay 2020-11-14 20:23:55 UTC
Simulator: avrtest core simulator hosted on SourceForge as part of WinAVR.

Libc: avr-libc trunk hosted on nongnu.org. There are several patches not yet integrated: recent xtiny devices, fixes in libm to adjust to the recent double64 additions, and extensions for the build environment to handle the new avr-gcc configure options for double multilib layout. Patches are pending for some time; you'll have to resolve conflicts.

Binutils is vanilla from sourceware.org.
Comment 13 Georg-Johann Lay 2020-11-15 13:27:01 UTC
FYI, avrtest is here: https://sourceforge.net/p/winavr/code/HEAD/tree/trunk/avrtest/
Comment 14 abebeos 2020-11-15 14:13:30 UTC
(In reply to Georg-Johann Lay from comment #12)
> [...]you'll have to resolve conflicts.

(In reply to Georg-Johann Lay from comment #13)
> FYI, avrtest is here:
> https://sourceforge.net/p/winavr/code/HEAD/tree/trunk/avrtest/

Thanks a lot. 

I tested a dozen repos / scripts  with avr-gcc tool integration (which include the tools/libs you mention, including avrtest and others), but always... conflicts, even in the 5.x line.

Looks better today, though, after days of trouble, I'll invest two more days to create a minimal setup, based on the xp gained.

Assuming that gcc does no automated regression tests currently for the avr target?
Comment 15 Georg-Johann Lay 2020-11-15 17:39:54 UTC
I built the tools by hand so I knew what I had...

Dunno about gcc/buildbot policies concerning avr. As avr as a 3ary target, that BE's quality is of no consideration when releasing the compiler. Again, I added/ran tests by myself when working on the BE. However, test coverage is low, and there are no performance tests. And there is no performance test suite I know of that would work reasonably for AVR, or one that has been designed for AVR/avr-gcc .

And be warned that the avr BE has many kludges, work-arounds and hacks. Some are historical, but most of them work around shortcomings and flaws in the middle-ends (nobody will fix middle-end issues that hamper a 3ary target).
Comment 16 abebeos 2020-11-18 20:08:30 UTC
I've updated the bounty, and you can follow the work here:

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

Whenever something relevant happens, I'll report it here.
Comment 17 abebeos 2020-11-29 00:10:50 UTC
Things look well, me being on 2 parallel solution paths:

a) using https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c6 as a foundation.

b) focusing more on a from-scratch work (cc0 elimination based on m68k solution).

I case of a), what would be the (legal) process to contribute a patch (which is based on code NOT YET contributed to the gcc project)? My understanding is that the original author can e.g. place the code into the public-domain, see: 

https://gcc.gnu.org/contribute.html#legal

so I can modify and contribute it later using the standard procedures (copyright assignment or again, placing the modified/extended code it into public domain).


I'd like to avoid investing more time into a) and falling then into kind of a copyright trap.
Comment 18 pipcet 2020-11-29 09:18:50 UTC
Sorry for only getting back to this now.

I release all code on this branch into the public domain, if it helps at all. I'm happy to add whatever legal attribution is needed for that.

I'm willing to help where I can, but please understand I've had to abandon this due to an unfortunate combination of family and health issues. I'm sorry about that.
Comment 19 abebeos 2020-11-29 10:54:29 UTC
pipcet, thank you for your quick response (both here and within email).

I think all here will agree that there's no need to apologize, as family/health should always come first.

As for your work, if all goes fine, then I'll have validated your patch tomorrow, so "The Last 2%" of the work can start. One or two more days and I can make my local dev-system reproducible, so anyone can jump in to run the tests and try to spot things.

I believe that it should be you (pipcet) that sends the final patch in (even if I do modifications), but if you cannot do it, then "placing you initial patch under public domain" should enable me to send a modified version in.

Now, going on, trying to keep the self-declared deadline (5th Dec. 2020).
Comment 20 abebeos 2020-11-30 13:48:42 UTC
Testsuite comparison on local dev system looks quite good:

https://github.com/abebeos/avr-gnu/issues/1
Comment 21 Senthil Kumar Selvaraj 2020-11-30 13:54:37 UTC
FWIW, I was working on this as well some time in August, and had a semi working implementation going. Pip's implementation generated better code on the few benchmark workloads I compared, so I shelved my work (https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed)

I don't have the spare time now to start full fledged work on this, but I can help with any issues you run into.
Comment 22 John Paul Adrian Glaubitz 2020-11-30 13:57:58 UTC
(In reply to abebeos from comment #20)
> Testsuite comparison on local dev system looks quite good:
> 
> https://github.com/abebeos/avr-gnu/issues/1

Just as a heads-up: Please keep in mind that submitting patches requires a proper attribution and copyright assignment, see:

> https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html
Comment 23 abebeos 2020-11-30 14:14:14 UTC
(In reply to Senthil Kumar Selvaraj from comment #21)
> (https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed)

I can still do a test-run, to see if it produces less fails than pip's one. Though it seems pip's work "last 2%" should be manageable. But in any case, having a 2nd solution-path (based on your work) is nice, as I really want to avoid to start from scratch (after those weeks of mostly integration work).

> I don't have the spare time now to start full fledged work on this, but I
> can help with any issues you run into.

Very nice, I can isolate the errors like:

=> "sorry, unimplemented: '-fzero-call-used-regs' not supported on this target"

so you folks can take a look with minimum effort. I'll file issues within the github repo when I cannot solve something myself.
Comment 24 Richard Biener 2020-11-30 14:15:05 UTC
Amending / adjusting https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc
(the only place that somewhat "documents" how to setup AVR testing) is appreciated.
Comment 25 abebeos 2020-11-30 14:47:35 UTC
(In reply to John Paul Adrian Glaubitz from comment #22)
[...]
> > https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html

FSF has a fascinating way to make trivial things complicated. Largest-Scale companies do such kind of legal stuff with one-click.

In any way, thank you for pointing to the official legal doc (I was looking for in #comment17)
Comment 26 abebeos 2020-11-30 16:29:25 UTC
(In reply to Richard Biener from comment #24)
> Amending / adjusting
> https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc
> (the only place that somewhat "documents" how to setup AVR testing) is
> appreciated.

You'll find some instructions in https://github.com/abebeos/avr-gnu (should be within the next days).
Comment 27 abebeos 2020-11-30 23:25:50 UTC
The "contrib/compare_tests" created a wrong delta.

"contrib/dg-cmp-results.sh seems to produce a more concise delta, and it shows that...

==> ...we are down to essentially 6 issues:

PASS->FAIL: c-c++-common/zero-scratch-regs-10.c  -Wc++-compat  (test for excess errors)
[...] (similar failure category)
NA->FAIL: gcc.dg/pr83480.c (internal compiler error)
PASS->FAIL: gcc.dg/pr83480.c (test for excess errors)
FAIL->PASS: gcc.dg/tree-ssa/pr92085-2.c (test for excess errors)
PASS->FAIL: gcc.target/avr/pr88253.c scan-assembler lds r\\d+,121
NA->FAIL: gcc.target/avr/torture/builtins-2-flash.c   -O1  (internal compiler error)
[...] (similar failure category)

If i did not something very wrong with my testing, this means that those failures should be nearly non-relevant (>100K tests pass).

I'll file tomorrow the remaining 5 issues with error-info here:

https://github.com/abebeos/avr-gnu/issues
Comment 28 abebeos 2020-12-01 19:10:44 UTC
(In reply to Senthil Kumar Selvaraj from comment #21)
[...]
> I don't have the spare time now to start full fledged work on this, but I
> can help with any issues you run into.

Just a questions re your version, see https://github.com/saaadhu/gcc-avr-cc0/issues/1.

As for my current main tests, there are 4 issues: https://github.com/abebeos/avr-gnu/issues
Comment 29 abebeos 2020-12-02 13:03:42 UTC
(In reply to abebeos from comment #23)
> (In reply to Senthil Kumar Selvaraj from comment #21)
> > (https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed)
> 
> I can still do a test-run, to see if it produces less fails
[...]

Test-Delta of your non-cc0 avr-backend is 0

> > I don't have the spare time now to start full fledged work on this, but I
> > can help with any issues you run into.

My understanding is that you have already contributor status here, so could you make the patch available to the project?

I will today focus on publishing my test-setup, so that my test-results can be peer-reviewed. Should be available within 12 hours, max 36.

If I did nothing wrong, then this means that your patch could go in. An alternative would be to iron-out the last issues from pipcet's version (possibly by using the constructs from your work).
Comment 30 Jonathan Wakely 2020-12-02 13:22:40 UTC
(In reply to abebeos from comment #29)
> My understanding is that you have already contributor status here, so could
> you make the patch available to the project?

I don't think that's true, is it? I think Senthil Kumar needs to complete the paperwork with the FSF for the patches to be "available to the project". Tht can be done by assigning copyright to the FSF or completing a disclaimer to place the work in the public domain.
Comment 31 John Paul Adrian Glaubitz 2020-12-02 13:24:36 UTC
(In reply to Jonathan Wakely from comment #30)
> I don't think that's true, is it? I think Senthil Kumar needs to complete
> the paperwork with the FSF for the patches to be "available to the project".
> Tht can be done by assigning copyright to the FSF or completing a disclaimer
> to place the work in the public domain.

The question will also be who will get to claim the bounty? If everyone contributes something, it will be more difficult to determine who gets what.
Comment 32 abebeos 2020-12-02 13:56:18 UTC
(In reply to Jonathan Wakely from comment #30)
> (In reply to abebeos from comment #29)
> > My understanding is that you have already contributor status here, so could
> > you make the patch available to the project?
> 
> I don't think that's true, is it? I think Senthil Kumar
[...]

See:

https://gcc.gnu.org/git/?p=gcc.git;a=search;h=e7d55c6b81733335d81e35f7c0116bbdffccb682;s=Senthil+Kumar+Selvaraj;st=committer
Comment 33 abebeos 2020-12-02 14:04:49 UTC
(In reply to John Paul Adrian Glaubitz from comment #31)
[...]
> The question will also be who will get to claim the bounty? If everyone
> contributes something, it will be more difficult to determine who gets what.

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

It is essentially not one bounty, but 2 or even 3, that's why I asked for the increase of the bounty, see "Update" section:

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

But!!!

We're risking to interrupt my perfect flow with such stuff ("paperwork" "bounty" etc.). I need my flow for 2 more days minimum.
Comment 34 abebeos 2020-12-03 00:37:52 UTC
(In reply to abebeos from comment #29)
[...]
> I will today focus on publishing my test-setup, so that my test-results can
> be peer-reviewed. Should be available within 12 hours, max 36.
[...]
https://github.com/abebeos/avr-gnu - drafty, you should await the next version before trying. avrtest setup is missing.
Comment 35 abebeos 2020-12-04 01:19:47 UTC
(In reply to abebeos from comment #11)
> (In reply to John Paul Adrian Glaubitz from comment #10)
> [...]
> > The main problem is apparently that the target hasn't been properly worked
> > on for a long time.
> [...]
> 
> Yes, this seems to result in this barrier:
> 
> => missing stable development environment for the work on the avr backend
> itself (build/test/simulate).
> 
> So this issue here splits into 3 major steps:
> 
> A) create a stable dev environment fro work on the avr backend
[...]

See https://github.com/abebeos/avr-gnu, should work as described.

My tests show:

=> pipcet's aborted non-cc0 backend results in 4 issues.
=> saaadhu's "shelved" non-cc0 backend results in 0 issues.

Tests should be easily reproducible.

We can "talk business" now, i don't need to focus anymore.
Comment 36 abebeos 2020-12-04 19:31:19 UTC
Created attachment 49686 [details]
Patch by Senthil Kumar Selvaraj, non-cc0-avr-backend

this should(!) be the final patch, derived from:

https://github.com/saaadhu/gcc-avr-cc0/commit/53b9401f0afe1f8cd679b982ecca1d3332ea2c37

(change to gcc/emit-rtl.c stripped, as it's already in the gcc repo).
Comment 37 abebeos 2020-12-07 00:39:09 UTC
?
Comment 38 abebeos 2020-12-07 13:02:09 UTC
Can someone please ping gcc-patches (me having troubles setting up email alias on gmail, don't want to use my main email)
Comment 39 John Paul Adrian Glaubitz 2020-12-07 13:10:46 UTC
(In reply to abebeos from comment #38)
> Can someone please ping gcc-patches (me having troubles setting up email
> alias on gmail, don't want to use my main email)

I'm not sure what you are trying to achieve.

There are guidelines for submitting patches which include signing the FSF copyright assignment using your full name and a proper email address.

It's not possible to merge patches anonymously and it's also not possible to claim a bounty for the work contributed by a third party.

An example for the proper process for submission of such a patch can be found here:

> https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559698.html
Comment 40 abebeos 2020-12-07 13:34:21 UTC
(In reply to John Paul Adrian Glaubitz from comment #39)
> (In reply to abebeos from comment #38)
> > Can someone please ping gcc-patches (me having troubles setting up email
> > alias on gmail, don't want to use my main email)
> 
> I'm not sure what you are trying to achieve.

Naturally, at this point, that someone verifies my results (I made this as simple as a few cli commands). 
 
> There are guidelines for submitting patches which include signing the FSF
> copyright assignment using your full name and a proper email address.

No need for full-name in public (FSF accepts even pseudonyms), no need to sign anything just to get a technical feedback ("review"). We are now in "review" state.
 
> It's not possible to merge patches anonymously and it's also not possible to
> claim a bounty for the work contributed by a third party.

I spend nearly a full-(over)-time month to achieve a result, fighting through incomplete/inconsistent/missing documentation and "dark land", providing finally the necessary (mostly) integration work. If I reuse existing code instead of writing from scratch, well, I think that's the original authors decision how to handle this.

But please stop talking like I did nothing, that's simply rude.

> An example for the proper process for submission of such a patch can be
> found here:
> 
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559698.html

Too much talk for my taste. Test-suites talk better.

And if i need a lawyer to just be able to claim a bounty, well...

The thing is: can someone please verify the test-results?
Comment 41 abebeos 2020-12-09 13:42:50 UTC
[RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561427.html
Comment 42 abebeos 2020-12-10 14:38:50 UTC
from Dimitar Dimitrov dimitar@dinux.eu within
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561489.html

> 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).
>
> [1] https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-avr.sh
Comment 43 abebeos 2020-12-12 18:24:22 UTC
The patch is now (after further validation zero regressions within gcc/g++ testsuite in 2 different test-setups) "out there":

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

My understanding of the process tells me:

- the relevant maintainers decide about the patch.
- if merged, then this issue can be closed. then...
- the bounty backers (and only they) decide about the claims to the bounty.

https://github.com/bountysource/core/wiki/Frequently-Asked-Questions#how-are-claims-processed

38 backers - it looks quite impossible for one malicious claimant to cheat the system.
Comment 44 abebeos 2020-12-13 16:13:23 UTC
added Denis Chertykov <chertykov@gmail.com> (listed avr maintainer) to cc
Comment 45 abebeos 2020-12-13 22:06:33 UTC
(In reply to abebeos from comment #40)
> (In reply to John Paul Adrian Glaubitz from comment #39)
[...]
> I spend nearly a full-(over)-time month to achieve a result, fighting
> through incomplete/inconsistent/missing documentation and "dark land",
> providing finally the necessary (mostly) integration work. If I reuse
> existing code instead of writing from scratch, well, I think that's the
> original authors decision how to handle this.
> 
> But please stop talking like I did nothing, that's simply rude.
[...]

Folks!

Take a look at this message from John Paul Adrian Glaubitz:

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

Now, please tell me:

- Does my management/integration work on this issue exist?
- Do I exist?

Rhetorical questions, I'm out for now, see:

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

.
Comment 46 abebeos 2020-12-14 02:12:34 UTC
This addresses the Bounty-Backers:

https://github.com/abebeos/avr-gnu/blob/master/doc/README.md
Comment 48 Senthil Kumar Selvaraj 2021-02-06 15:21:54 UTC
Submitted https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563638.html, which addresses comments made when the work-in-progress version was submitted. There are no regression failures (save for some tests that fail because of code size increase) on atmega128, atxmega128a3, attiny40 and atmega8. 

Follow up patch https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563779.html improves code size regressions. More patches along the way - fixing some define_splits, and adding CC_CZN and CC_ZN modes, along with enabling the cmpelim pass.