https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2025-03-07
Status|UNCONFIRMED |SUSPENDED
--- Comment #10 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
The patch for https://sourceware.org/bugzilla/show_bug.cgi?id=32704 is
upstream.
The fix is for Binutils v2.45.
With that in place, the code from PR118880 assembles to:
<__vector_7>:
8f 93 push r24
1f 92 push r1
80 e0 ldi r24, 0x00
18 2e mov r1, r24
<BODY>
1f 90 pop r1
8f 91 pop r24
18 95 reti
where it previously was:
<__vector_7>:
1f 92 push r1
1f b6 in r1, 0x3f ; 63
1f 92 push r1
11 24 eor r1, r1
8f 93 push r24
<BODY>
8f 91 pop r24
1f 90 pop r1
1f be out 0x3f, r1 ; 63
1f 90 pop r1
18 95 reti
That is, __gcc_isr will no more clobber SREG just for the purpose of setting
__zero_reg__ when the ISR body uses some upper register (R16...R31).
Notice that the test case for PR115817 still generates the same code since the
body doesn't use an upper register.
Reason is that it is not feasible to track __zero_reg__, __tmp_reg__ and SREG
usage in the compiler (PR20296), which is why pseudo insn __gcc_isr is there to
begin with.
You could hack around this by using a variable that holds 0x0 and hide that
value from the compiler, like shown in comment #9.
Hence except there will be a complete rewrite of the AVR backend, this issue
will persist.
