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.
next prev 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: linkBe 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).