[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #61 from abebeos at lazaridis dot com --- Now, the headline would be: "Physik FU-Berlin, Microchip, Google, RedHat, IBM and more to Support Abuse, Discrimination and even 'IT-fascism' via/on GCC/GNU/FSF Project-Resources". See, nobody cares, until a valid(!) headline gets some visibility. But for now I'll stop here, as I don't want to open/activate accounts in order to publish. And in the end, I would analyze GCC/GNU/FSF weaknesses and threads without getting payed. Just one last thing: John Paul Adrian Glaubitz, you have attacked my professional reputation in public, saying more or less that I claimed the bounty without having done any work for it. But the indisputable fact is that any person that declares "assessment, validation, integration and general reuse of existent results" as "copying" should simply stay away from OSS software. And persons which abuse their (position of) power to brute-force violate voting procedures (or to not intervene), are just some (more or less worse) form of IT-fascists. People like you should be kicked out immediately from OSS projects. Well, at least in a perfect world. Cu around, clowns.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #60 from abebeos at lazaridis dot com --- Notable sub-message: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570039.html And the final essence, from: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570044.html " GCC issue, GCC resources(!), GCC committers, GCC participants. Be aware that each and every person which noticed the non-attribution and the rigged vote, without intervening, does this: => Supporting IT-fascism, in the name of GCC/GNU. Including you - whoever you are. "
[Bug web/100480] Where to file complaints re project-maintainers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480 --- Comment #6 from abebeos at lazaridis dot com --- All good. Just be aware that the usual OSS "volunteer excuse" is a bit cheap in a project where names like Apple, Google, IBM, Redhat, ARM etc. appear. My understanding is that complaints need to be filed publicly on the high-volume list: https://gcc.gnu.org/pipermail/gcc/ which is the "contact" for the steering committee: https://gcc.gnu.org/steering.html
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #59 from abebeos at lazaridis dot com --- Oh my, what a mess: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569913.html
[Bug web/100480] Where to file complaints re project-maintainers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480 --- Comment #4 from abebeos at lazaridis dot com --- This is essentially a bug in gcc's component "web". The website should inform clearly who can one contact (either in public or in private) to make a formal complaint. This is rally nothing special in todays OSS landscape (usually you find the contact within the CONTRIBUTING document in root). I'm ok with sending a query to the list. (you can close the issue if you feel that the gcc project does not need to take any action re this issue)
[Bug web/100480] Where to file complaints re project-maintainers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480 abebeos at lazaridis dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from abebeos at lazaridis dot com --- You should not close issues that fast, especially not as "RESOLVED INVALID". One would possibly prefer to not use a public group for complaints, so, which email would this be? Additionally, this is a deficit (if not defect) of your website - other projects mention dedicated complaint emails & other channels clearly.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #58 from abebeos at lazaridis dot com --- Well, now I'm really really curious. Does the gcc project have at least some(!) liberal qualities, or will IT-fascism win? Follow-up: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
[Bug web/100480] New: Where to file complaints re project-maintainers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480 Bug ID: 100480 Summary: Where to file complaints re project-maintainers? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: abebeos at lazaridis dot com Target Milestone: --- I would like to file a formal complain re the behavior of gcc project-maintainers and possibly leadership. Could not find any info on the website. Where do I file such a complaint?
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #57 from abebeos at lazaridis dot com ---
Just fascinating!
Bountysource violated its own processes, and payed out the bounty without
waiting for the votes.
See, even without a dispute, there is a 2 week voting period ("The bounty will
be paid out if all backers accept your claim or if no backers reject your claim
by May 15, 2021 4:41 PM (GMT)")
But it looks like some "manual intervention" just skipped the process, without
waiting for the votes of the main backers:
Microchip $5,000
nseidle $500
per1234 $300
And i was mostly interested in what those 3 had to say.
GCC, Bountysource, just be aware that there is one word for this:
Cheating.
Please fix this, if its just one of the bountysource-bugs.
The voice of the major backers needs to count.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #56 from abebeos at lazaridis dot com --- Oh, Mr. Glaubitz, thank you for your opinion. It is you very personal choice to ignore "integration work" and label "reuse of existent results" as "copy". I assume this does not reflect on policies of your employer (physik.fu-berlin.de), because academia would not work without reuse & attribution. Lets see what other backers have to say, my efforts are clearly documented. Note to readers: Mr. Glaubitz is the same person which completely(!) ignored all my efforts subjecting this issue, e.g. talking like I do not exist (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c45). It is the same person who blocks(!) me on github projects, just for replying to users asking for info. He's a bit allergic to my individuality, I guess.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #54 from abebeos at lazaridis dot com --- Bounty Claim: Please not that "saaadhu"s patch was "shelved". I integrated a validation-setup and tested several existent solutions, and identified during the "reuse existent work" phase of my work "saaadhus" patch as the best one of two patches (pipcet beeing the other one): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35 saaadhu continued the work at some point. My overall effort is described in summary here: https://github.com/abebeos/avr-gnu/blob/master/doc/README.md The test-setup which led to the validation of saaadhu result is here: https://github.com/abebeos/avr-gnu Now, there is a strange tendency within this project to completely ignore my work on this issue/bounty and my person, see e.g. here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c45 Very sad, the very very basic rule of "correct attribution" (within OSS and academia) seems to be non-existent. Not to talk about the behavior agains "worker" (because I'm a simple worker in the context here, working to get some income). Additionally, saaadhu never replied to private email, even not to the last one: " Hi there! It looks like bountysource has no functionality to split bounties, so we would need to agree to a way of processing the split. Are you ok with splitting the bounty 50/50? One possible process: - We tell the backers that we agreed - I claim the bounty - I get the amount granted on bountysource (this can take up to 2 weeks, because of the veto period and the many backers), - I file a bounty with 50% of the amount (around $3000) which you can claim nearly immediately. This way we avoid the payout delays (sometimes a week or more until money arrives on paypal), and all backers can see within a day that we've done the split. Please let me know if you have another suggestion. " correction: around $3500 - The flow within this ticket here shows clearly that i contributed significantly(!) to the fulfillment of this bounty, having invested multiple weeks. Backers may choose to ignore that fact. Or the may not.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #52 from abebeos at lazaridis dot com --- All good, found it: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3ba781d3b5c8efadb60866c9743b657e8f0eb222
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #51 from abebeos at lazaridis dot com --- @Senthil, can you please provide the links to the commits? I was unable to locate them.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #50 from abebeos at lazaridis dot com --- Great! It looks that bountysource does not allow to split a bounty. Any suggestions on how to process this further?
[Bug testsuite/98574] New: Make gcc-jenkins an OSS Project
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98574 Bug ID: 98574 Summary: Make gcc-jenkins an OSS Project Product: gcc Version: unknown URL: http://gcc.gnu.org/jenkins Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: abebeos at lazaridis dot com CC: law at redhat dot com Target Milestone: --- STATUS It is currently not possible to contribute "The-OSS-Way" to: http://gcc.gnu.org/jenkins mainly because the sources are not available. (To clarify: this issue affects not the tool sources (jenkins), but all the gcc-project related scripts, configs etc.) Some relevant discussion within this thread: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562906.html EXPECTED * All relevant scripts, setups, configs etc. are within a git repo (or multiple, if one is not easily applicable). Developers can then contribute using the usual OSS-way (review existent stuff, add-modify via patches discussed on gcc-patches).
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #47 from abebeos at lazaridis dot com --- Relevant news: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562114.html
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #46 from abebeos at lazaridis dot com --- This addresses the Bounty-Backers: https://github.com/abebeos/avr-gnu/blob/master/doc/README.md
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #45 from abebeos at lazaridis dot com --- (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 .
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 abebeos at lazaridis dot com changed: What|Removed |Added CC||chertykov at gmail dot com --- Comment #44 from abebeos at lazaridis dot com --- added Denis Chertykov (listed avr maintainer) to cc
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #43 from abebeos at lazaridis dot com --- 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.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #42 from abebeos at lazaridis dot com --- from Dimitar Dimitrov dimi...@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
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #41 from abebeos at lazaridis dot com --- [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion) https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561427.html
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #40 from abebeos at lazaridis dot com ---
(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?
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #38 from abebeos at lazaridis dot com --- Can someone please ping gcc-patches (me having troubles setting up email alias on gmail, don't want to use my main email)
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #37 from abebeos at lazaridis dot com --- ?
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #36 from abebeos at lazaridis dot com --- Created attachment 49686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49686=edit 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).
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #35 from abebeos at lazaridis dot com --- (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.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #34 from abebeos at lazaridis dot com --- (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.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #33 from abebeos at lazaridis dot com ---
(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.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #32 from abebeos at lazaridis dot com --- (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=e7d55c6b8175d81e35f7c0116bbdffccb682;s=Senthil+Kumar+Selvaraj;st=committer
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #29 from abebeos at lazaridis dot com --- (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).
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #28 from abebeos at lazaridis dot com --- (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
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #27 from abebeos at lazaridis dot com --- 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
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #26 from abebeos at lazaridis dot com --- (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).
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #25 from abebeos at lazaridis dot com --- (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)
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #23 from abebeos at lazaridis dot com --- (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.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #20 from abebeos at lazaridis dot com --- Testsuite comparison on local dev system looks quite good: https://github.com/abebeos/avr-gnu/issues/1
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #19 from abebeos at lazaridis dot com --- 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).
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #17 from abebeos at lazaridis dot com --- 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.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #16 from abebeos at lazaridis dot com --- 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.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #14 from abebeos at lazaridis dot com --- (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?
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #11 from abebeos at lazaridis dot com --- (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), 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).
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 abebeos at lazaridis dot com changed: What|Removed |Added CC||abebeos at lazaridis dot com --- Comment #9 from abebeos at lazaridis dot com --- 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".
