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 C76913858C33; Wed, 19 Jul 2023 17:57:18 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C76913858C33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1689789438;
	bh=7IemldBkwmedc2/uR0yt2jMjPkIC/6xZjCkYUxVKiE8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=s2UlkCvdW0P6FbNEtfZQBk3kh0cct6ztnZ0wwgbwrsV6NblgS6+86/ZywC/ZxV20/
	 BpWLMcMkHnsCK4bdPYXyfET/VfVRFBQ91eXPRpI6y9UUzPbQASMbuHKL+kP3gtJXHi
	 +z8l9O0jQhO7SwMsEYdSt0o2XtA0naLlF3jdI+yo=
From: "cleger at rivosinc dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/110634] Incorrect RISC-V assembly with
 -fno-omit-frame-pointer
Date: Wed, 19 Jul 2023 17:57:18 +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: 12.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cleger at rivosinc dot com
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-110634-4-6Am4q6zgEL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110634-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110634-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=3D110634

Cl=C3=A9ment L=C3=A9ger <cleger at rivosinc dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cleger at rivosinc dot com

--- Comment #5 from Cl=C3=A9ment L=C3=A9ger <cleger at rivosinc dot com> ---
(In reply to Andrew Pinski from comment #1)
> I don't see where in any of the spec mentioned that storing of ra is need=
ed
> at all. That is it does not read ambigous to me at all. It just mentions =
for
> a frame pointer, the frame pointer needs to be saved and nothing about ra.
>=20
> This is totally different from the power ABI.

I also stumbled on this problem and looking at the spec, it seems specified
what needs to be stored in a frame record:

"A frame record consists of two XLEN values on the stack; the return address
and the link to the next frame record. The frame pointer register will poin=
t to
the innermost frame, thereby starting the linked list. By convention, the
lowest XLEN value shall point to the previous frame, while the next XLEN va=
lue
shall be the return address."

So storing ra is actually specified unless you refer to an older version of
this spec but this clarification was added in a (somehow) not so recent com=
mit:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/e353f995d064507=
8e4ce5cb1acd355d37cb3e9c2

Regarding frame pointer generation wrt to leaf functions, either GCC should=
 not
generate the frame record or generate a non bogus one. The current one is
unusable since it is malformed. But this behavior should probably depends on
-f(no)omit-frame-leaf-pointer.=