On 5/19/23 02:49, Georg-Johann Lay wrote:
Subject:
Re: [patch,avr] Fix PR109650 wrong code
From:
Georg-Johann Lay
Date:
5/19/23, 02:49
To:
gcc-patches@gcc.gnu.org
CC:
Jeff Law , Denis Chertykov ,
Senthil Kumar Selvaraj
...Ok, and now with the patch attached...
Here is a revised
Ping #2 for:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618976.html
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20230519/9536bf8c/attachment-0001.bin
Ping #1:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620098.html
Johann
Am 19.05.23 um 10:49 schrieb Georg-Johann Lay:
Ping #1 for:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618976.html
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20230519/9536bf8c/attachment-0001.bin
Johann
Am 19.05.23 um 10:49 schrieb Georg-Johann Lay:
Here is a revised version of the patch. The difference to the
previou
...Ok, and now with the patch attached...
Here is a revised version of the patch. The difference to the
previous one is that it adds some combine patterns for *cbranch
insns that were lost in the PR92729 transition. The post-reload
part of the patterns were still there. The new patterns are
sl
Here is a revised version of the patch. The difference to the
previous one is that it adds some combine patterns for *cbranch
insns that were lost in the PR92729 transition. The post-reload
part of the patterns were still there. The new patterns are
slightly more general in that they also handl
This patch fixes a wrong-code bug in the wake of PR92729, the transition
that turned the AVR backend from cc0 to CCmode. In cc0, the insn that
uses cc0 like a conditional branch always follows the cc0 setter, which
is no more the case with CCmode where set and use of REG_CC might be in
different
