Re: [GOVERNANCE] Where to file complaints re project-maintainers?
abebeos via Gcc-patches schrieb: Again, just heavily fascinating to see how you ignore the overall essence of this, which is of course directly related to gcc. (bountysource is just a secondary disaster, it all starts here, at gcc. * You postet a patch to gcc-patches@. * You did not answer any questions re. that patch. * You did not address any of the issues of the patch, not even coding rules. * You wrote that you "not touch even whitespace". * And then you PLONK-ed. http://gcc.gnu.org/pipermail/gcc-patches/2020-December/561762.html * To concerns about future problems with the patch you basically replied "mess left behind by the patch is no issue, community folks will happily fix them." Thus, refusing to integrate that patch was 100% correct from the technical point. * You were told at several occasions by different people that substantial contributions > 10 LOC need a Copyright Assignment. * You were told that GCC mailing list policy is to use real name. You refused that, asserting "me don't need that". Thus, refusing to integrate that patch was 100% correct from the legal point. * Getting you $$$ by integrating a patch (of which you did not understand a single line), or being rude and calling people bullies, abusers and fascists will get you nowhere. You are spamming technical PRs and lists with your poisoned language, but you did not fool anyone. Thus, refusing to integrate that patch was 100% correct from the moral point. That bounty was awarded to 100% to Senthil, and 100% rightly so. From the technical view, from the legal view, from the moral view. He wrote 100% of the patch, he understands it, he knows how to address future issues. Johann
Re: [PATCH] avr: cc0 to mode_cc conversion
Segher Boessenkool schrieb: On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote: On Dec 17, 2020, at 6:21 AM, Segher Boessenkool wrote: On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via Gcc-patches wrote: The work on my github branch was not complete - I'd blindly followed whatever the CC0 Transition wiki mentioned (the first three steps of case #2), and fixed any regression fallout (for ATmega128). I intend to try out a define_subst/early clobber of reg_cc based approach (inspired by the cris port) and see if that can help avoid the proliferation of define_insn_and_splits. Will update how that works out. Yeah, case #2 does not necessarily give the best result, but it usually is the least work to do, so certainly a good choice under time pressure. I was under the impression from what I read in the blog a year or two ago (when I did the pdp11 ccmode work) that "case 2" is the better answer for machines in which pretty much every operation touches the condition codes. In other words, I understood that case 1 would for such machines not be the right answer -- it wasn't just that "case 2 is easier". Did I misunderstand? Is there a reason for machines such as pdp11, in which basically every operation that handles data, even a move instruction, touches CC, to use approach 1? No, you didn't misunderstand. I said "not necessarily" for a reason :-) If there are move insns that do *not* clobber CC, it can be different, but if even move instructions do, a case #2 conversion is a good choice. (This is all my opinion, but I think it is not controversial.) As far as I understand, targets that clobber condition code in mov or add3 must use approach #2. #1 is not a problem if the target still uses IRA (like avr does), but LRA cannot handle clobbers of the condition code (in terms or explicit clobbers). Hence, targets that clobber cc in mov or add3 must use #2 because IRA/reload will also be kicked out before very soon. Or am I missing something? Johann
Re: [Ping] AVR CC0 conversion
Senthil Kumar Selvaraj via Gcc-patches: John Paul Adrian Glaubitz writes: On 4/28/21 7:59 PM, Senthil Kumar Selvaraj wrote: https://gcc.gnu.org/git?p=gcc.git;a=commit;h=3ba781d3b5c8efadb60866c9743b657e8f0eb222 Awesome \o/. Should we wait for the second patch [1] to be merged as well before closing the PR? [2] I guess it depends on the scope of the PR? If it was about removing cc0, then this patch would do. If it was about getting the generated code also to be as close to what it was with cc0, then no, it cannot be closed. OTOH, while the second patch (adjusting peepholes) does help, there are other things in the pipeline - addition of new CC modes and enabling compare elimination, adjusting rtx costs etc. I will continue to work on them in my spare time and submit patches when ready. Hi Senthil, that's great to know. Many thanks for that work and your dedication! Johann Regards Senthil
