public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "wdijkstr at arm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/60580] aarch64 generates wrong code for __attribute__ ((optimize("no-omit-frame-pointer")))
Date: Thu, 20 Nov 2014 20:32:00 -0000	[thread overview]
Message-ID: <bug-60580-4-n3kk6utdUH@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-60580-4@http.gcc.gnu.org/bugzilla/>

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

Wilco <wdijkstr at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wdijkstr at arm dot com

--- Comment #8 from Wilco <wdijkstr at arm dot com> ---
(In reply to Jiong Wang from comment #7)
> I'd take this for long term, hopefully could find a acceptable solution.
> 
> X86 is default with -fomit-frame-pointer which makes the logic a little bit
> simpler, and thus X86 could survive in more normal case, but still fail in
> some corner cases.
> 
> the fundamental problem is aarch64 and also x86 want to implement a finer
> control of frame pointer which let leaf function be possible without setting
> up frame record even under -fno-omit-frame-pointer. While gcc generic code
> is not aware of that.

Besides the solutions we discussed on the list to fix the underlying issues in
the mid-end, a workaround may be possible in the backend. If we can guarantee a
callback is made to the backend at the end of compilation of each function,
then we can restore the original value of the omit-frame-pointer variable. This
means the options code will never see the fake value, and attributes will work
as expected.

In principle any callback would work as long as the frame pointer variable is
not used for that function again, and it happens before entering the options
code again.

Obviously this is a nasty hack, but at least it works.


      parent reply	other threads:[~2014-11-20 20:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19  8:37 [Bug target/60580] New: " chemobejk at gmail dot com
2014-03-19 12:41 ` [Bug target/60580] " jakub at gcc dot gnu.org
2014-03-20 23:55 ` ramana at gcc dot gnu.org
2014-03-27 10:20 ` mshawcroft at gcc dot gnu.org
2014-07-02 13:57 ` ktkachov at gcc dot gnu.org
2014-11-14 11:39 ` jiwang at gcc dot gnu.org
2014-11-14 11:40 ` [Bug middle-end/60580] " jiwang at gcc dot gnu.org
2014-11-20 20:32 ` wdijkstr at arm 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-60580-4-n3kk6utdUH@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).