public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
Date: Wed, 10 Apr 2024 13:24:09 +0000	[thread overview]
Message-ID: <bug-114664-4-be4K4oPouR@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-114664-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #10 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #7)
> Then that would seem to indicate that mentioning the frame pointer reg in
> the asm clobber list is an error
Yeah, I agree it's an error.  The PR says “ICE”, but is there an internal
error?  The “cannot be used in ‘asm’ here” is a normal user-facing error,
albeit with bad error recovery, leading us to report the same thing multiple
times.

> but how are users supposed to know whether
> -fno-omit-frame-pointer is in effect or not?  I've looked and there is no
> pre-defined macro a user could check.
That might be a useful thing to have, but if the programmer has no control over
the build flags (i.e. cannot require/force -fomit-frame-pointer) then I think
the asm has to take care to save and restore the frame pointer itself.

Dropping "31" from the asm means that the asm must preserve the register. 
Things will go badly if the asm doesn't do that.

  parent reply	other threads:[~2024-04-10 13:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-09 18:42 [Bug rtl-optimization/114664] New: " bergner at gcc dot gnu.org
2024-04-09 18:48 ` [Bug rtl-optimization/114664] " pinskia at gcc dot gnu.org
2024-04-09 19:00 ` bergner at gcc dot gnu.org
2024-04-09 19:01 ` pinskia at gcc dot gnu.org
2024-04-09 19:02 ` bergner at gcc dot gnu.org
2024-04-09 19:04 ` bergner at gcc dot gnu.org
2024-04-09 19:06 ` pinskia at gcc dot gnu.org
2024-04-09 19:21 ` pinskia at gcc dot gnu.org
2024-04-09 19:48 ` bergner at gcc dot gnu.org
2024-04-10  3:14 ` linkw at gcc dot gnu.org
2024-04-10 12:52 ` bergner at gcc dot gnu.org
2024-04-10 13:24 ` rsandifo at gcc dot gnu.org [this message]
2024-04-10 13:42 ` bergner at gcc dot gnu.org
2024-04-10 13:53 ` rsandifo at gcc dot gnu.org
2024-04-10 14:03 ` bergner at gcc dot gnu.org
2024-04-10 14:04 ` rsandifo at gcc dot gnu.org
2024-04-10 14:15 ` bergner at gcc dot gnu.org
2024-04-10 15:37 ` segher at gcc dot gnu.org

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-114664-4-be4K4oPouR@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).