https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #17 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #11)
> Have we done the backports so we can just mark this bug a FIXED? ...or do
> we still need to push the backports?
(In reply to Segher Boessenkool from comment #12)
> The backports have not been done yet.
>
Yeah, I just backported it to all active release branches, previously when I
wanted to backport them, I noticed release 12.4 is ongoing, so I held it for a
while.
> It would be good if the blockage / barrier would get some comment btw, saying
> what exactly it is intended to do! It is very much cargo-cult the way it is.
Good idea, sorry that didn't specify it originally, the reason why adding the
barrier is that: bb verifier requires returnjump_p should be followed by a
barrier:
if (JUMP_P (x)
&& returnjump_p (x) && ! condjump_p (x)
&& ! ((y = next_nonnote_nondebug_insn (x))
&& BARRIER_P (y)))
fatal_insn ("return not followed by barrier", x);
, otherwise we will encounter an ICE. Adding blockage follows the existing
practice when calling rs6000_emit_epilogue to respect option -mno-sched-epilog
(put one scheduling boundary on the emitted insns from rs6000_emit_epilogue).
