From: Alexandre Oliva <oliva@adacore.com>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] strub: avoid lto inlining
Date: Thu, 14 Dec 2023 16:52:29 -0300 [thread overview]
Message-ID: <orsf4436ki.fsf@lxoliva.fsfla.org> (raw)
The strub builtins are not suited for cross-unit inlining, they should
only be inlined by the builtin expanders, if at all. While testing on
sparc64, it occurred to me that, if libgcc was built with LTO enabled,
lto1 might inline them, and that would likely break things. So, make
sure they're clearly marked as not inlinable.
Regstrapped on x86_64-linux-gnu, also testing on sparc-solaris2.11.3.
Ok to install?
for libgcc/ChangeLog
* strub.c (ATTRIBUTE_NOINLINE): New.
(ATTRIBUTE_STRUB_CALLABLE): Add it.
(__strub_dummy_force_no_leaf): Drop it.
---
libgcc/strub.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libgcc/strub.c b/libgcc/strub.c
index b0f990d9deebb..5062554d0e1e6 100644
--- a/libgcc/strub.c
+++ b/libgcc/strub.c
@@ -36,7 +36,12 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
# define TOPS <
#endif
-#define ATTRIBUTE_STRUB_CALLABLE __attribute__ ((__strub__ ("callable")))
+/* Make sure these builtins won't be inlined, even with LTO. */
+#define ATTRIBUTE_NOINLINE \
+ __attribute__ ((__noinline__, __noclone__))
+
+#define ATTRIBUTE_STRUB_CALLABLE \
+ __attribute__ ((__strub__ ("callable"))) ATTRIBUTE_NOINLINE
/* Enter a stack scrubbing context, initializing the watermark to the caller's
stack address. */
@@ -72,7 +77,6 @@ __strub_update (void **watermark)
/* Dummy function, called to force the caller to not be a leaf function, so
that it can't use the red zone. */
static void ATTRIBUTE_STRUB_CALLABLE
-__attribute__ ((__noinline__, __noipa__))
__strub_dummy_force_no_leaf (void)
{
}
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
next reply other threads:[~2023-12-14 19:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 19:52 Alexandre Oliva [this message]
2023-12-15 7:00 ` Richard Biener
2023-12-19 23:53 ` Alexandre Oliva
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=orsf4436ki.fsf@lxoliva.fsfla.org \
--to=oliva@adacore.com \
--cc=gcc-patches@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).