public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <bug-110634-4-6Am4q6zgEL@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110634-4@http.gcc.gnu.org/bugzilla/>

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

Clément Léger <cleger at rivosinc dot com> changed:

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

--- Comment #5 from Clément Léger <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 needed
> 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.
> 
> 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 point 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 value
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 commit:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/e353f995d0645078e4ce5cb1acd355d37cb3e9c2

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.

      parent reply	other threads:[~2023-07-19 17:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 19:43 [Bug c/110634] New: " bjorn at kernel dot org
2023-07-11 19:47 ` [Bug target/110634] " pinskia at gcc dot gnu.org
2023-07-11 19:50 ` bjorn at kernel dot org
2023-07-11 19:52 ` pinskia at gcc dot gnu.org
2023-07-11 20:07 ` schwab@linux-m68k.org
2023-07-19 17:57 ` cleger at rivosinc dot com [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-110634-4-6Am4q6zgEL@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).