[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|9.5 |9.0 Resolution|--- |FIXED --- Comment #13 from Richard Biener --- Fixed for GCC 9.
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 Richard Biener changed: What|Removed |Added Target Milestone|9.4 |9.5 --- Comment #12 from Richard Biener --- GCC 9.4 is being released, retargeting bugs to GCC 9.5.
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.3 |9.4 --- Comment #11 from Jakub Jelinek --- GCC 9.3.0 has been released, adjusting target milestone.
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.2 |9.3 --- Comment #10 from Jakub Jelinek --- GCC 9.2 has been released.
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #9 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 --- Comment #8 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #7) > Let's keep the PR open for the eventual removal of the remaining blockage > instruction for targets that emit unwind information in the epilogue. FTR, the following patch works OK on x86_64-linux-gnu (bootstrap + regression test of all default languages, obj-c++ and go): Index: function.c === --- function.c (revision 266278) +++ function.c (working copy) @@ -5447,13 +5447,6 @@ expand_function_end (void) if (naked_return_label) emit_label (naked_return_label); - /* @@@ This is a kludge. We want to ensure that instructions that - may trap are not moved into the epilogue by scheduling, because - we don't always emit unwind information for the epilogue. */ - if (cfun->can_throw_non_call_exceptions - && targetm_common.except_unwind_info (_options) != UI_SJLJ) -emit_insn (gen_blockage ()); - /* If stack protection is enabled for this function, check the guard. */ if (crtl->stack_protect_guard && targetm.stack_protect_runtime_enabled_p ()) stack_protect_epilogue ();
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 Uroš Bizjak changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #7 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #6) > Fixed for gcc-9.0, no plan to backport. Let's keep the PR open for the eventual removal of the remaining blockage instruction for targets that emit unwind information in the epilogue.
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #6 from Uroš Bizjak --- Fixed for gcc-9.0, no plan to backport.
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 --- Comment #5 from uros at gcc dot gnu.org --- Author: uros Date: Wed Nov 21 20:18:45 2018 New Revision: 266356 URL: https://gcc.gnu.org/viewcvs?rev=266356=gcc=rev Log: PR middle-end/88129 * function.c (expand_function_end): Do not emit extra blockage insn. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 --- Comment #4 from Eric Botcazou --- > Looking at the kludge, which say: > > /* @@@ This is a kludge. We want to ensure that instructions that > may trap are not moved into the epilogue by scheduling, because > we don't always emit unwind information for the epilogue. */ > > do we need the blockage at all for targets that emit unwind information in > the epilogue? Probably not indeed. The two-pronged goal should be: 1) remove or understand the first blockage 2) remove the blockage(s) for targets that emit unwind information in the epilogue.
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 --- Comment #3 from rguenther at suse dot de --- On Wed, 21 Nov 2018, ubizjak at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 > > Uroš Bizjak changed: > >What|Removed |Added > > CC||ebotcazou at gcc dot gnu.org > > --- Comment #2 from Uroš Bizjak --- > (In reply to Richard Biener from comment #1) > > So simply undo the DF merge error? > > Eric (CC'd) said elsewhere that the additional blockage might be needed for > DF. I'd doubt that, it does look like a simple merge oversight. I'd say remove it now, there's plenty of time to re-instantiate it if it breaks sth. On trunk only of course.
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 Uroš Bizjak changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Uroš Bizjak --- (In reply to Richard Biener from comment #1) > So simply undo the DF merge error? Eric (CC'd) said elsewhere that the additional blockage might be needed for DF.
[Bug middle-end/88129] Two blockage insns are emited in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-21 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- So simply undo the DF merge error?
