From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 68317386103C; Mon, 24 Jun 2024 03:46:15 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 68317386103C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1719200775;
	bh=BCTAneazlxnUXc7Y705osj9r5BDJaBfhXKfQcXzYcuI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ApXiDlqCe1t7BemLSpGvJsqthlabEZ1GkhixYdBFrZUeBKqshI7zn/4/Vjvmf/T30
	 yHHG3zUmbsp+pUEYeybZraVEccWCsSxVpvKTzw+W7nTfrQUHDqKnquXQaTEtGMfmLq
	 wzqY2R1IbOI93FLMVsxg1yfpc4LxZFvARK09M8RQ=
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/114846] powerpc: epilogue in _Unwind_RaiseException
 corrupts return value due to __builtin_eh_return
Date: Mon, 24 Jun 2024 03:46:14 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: linkw at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114846-4-9htD38KSxU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114846-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114846-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114846

--- 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.
>=20

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 fo=
r a
while.

> It would be good if the blockage / barrier would get some comment btw, sa=
ying
> 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 t=
he
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 =3D next_nonnote_nondebug_insn (x))
                && BARRIER_P (y)))
            fatal_insn ("return not followed by barrier", x);=20

, otherwise we will encounter an ICE. Adding blockage follows the existing
practice when calling rs6000_emit_epilogue to respect option -mno-sched-epi=
log
(put one scheduling boundary on the emitted insns from rs6000_emit_epilogue=
).=