On 2026-05-11 03:27, Bruno Haible wrote:
Paul Eggert wrote:
+ If GCC 12+ and -flto is not being used (in which case -DUSING_LTO
+ should also be used), simply use a pragma.
What does this comment mean? That the one who builds the package should
set CPPFLAGS="-DUSING_LTO" if -flto is not being used? (Or if -flto
_is_ being used?)
Sorry, that was a typo; the "not" was spurious. Fixed by the attached
patch (but see below).
Distros don't typically define this symbol. For instance, Fedora has a
'_lto_cflags' variable in their spec files that defaults to
"-flto=auto -ffat-lto-objects".
Oh, I forgot that -Wreturn-local-addr is the default. I thought it was
active only if --enable-gcc-warnings is used, something distros
typically don't do.
To some extent both the old code (based on __OPTIMIZE__) and the patch
(based on USING_LTO) are "sinful", as conditionally compiling code to do
X if optimization is enabled and Y otherwise is a recipe for trouble.
I suspect that's why GCC doesn't predefine a macro to tell you whether
-flto is in effect. That being said, after looking into this just now I
saw other projects using a similar idea, e.g., Linux uses CONFIG_LTO,
CONFIG_LTO_CLANG, CONFIG_LTO_CLANG_THIN internally, albeit for a
different reason, namely, to arrange for code to not be optimized away
merely because the link time optimizer can't see references to it.
I think it should be the
configure script, not the user, who defines such a symbol like USING_LTO.
So, have a --enable-gcc-warnings=lto flag, or something like that? That
would work, though I'm not sure it's worth the effort for this one false
positive. And I'm not sure whether we should have 'configure' try to
deduce this sort of thing automatically without a flag, as that sounds
fragile.
For now, I installed the attached, which gives up entirely on the idea
of doing this minor inlining option in GCC 10+. Although I don't like
this micro-deoptimization, dealing with a USING_LTO flag is quite a
configuration hassle, and we should probably defer it until we need it
more than just for this.
Thanks for pointing out the problem.
diff --git a/ChangeLog b/ChangeLog
index 46fc6d5766..8cbef68690 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2026-05-11 Paul Eggert <[email protected]>
+
+ careadlinkat: pacify GCC 12+ -Wreturn-local-addr more simply
+ * lib/careadlinkat.c (readlink_stk):
+ Now also noinline when _GL_GNUC_PREREQ (12, 1) && !USING_LTO.
+ The small inlining performance improvement for GCC 12+ was not worth
+ the hassle of documenting or autoconfiguring USING_LTO.
+ This change removes the need for USING_LTO.
+ Problem reported by Bruno Haible in:
+ https://lists.gnu.org/r/bug-gnulib/2026-05/msg00103.html
+
2026-05-10 Paul Eggert <[email protected]>
intprops: ignore -Wuseless-cast less often
diff --git a/lib/careadlinkat.c b/lib/careadlinkat.c
index d9c27ed4f0..c5e8addc66 100644
--- a/lib/careadlinkat.c
+++ b/lib/careadlinkat.c
@@ -42,21 +42,16 @@ enum { STACK_BUF_SIZE = 1024 };
/* Act like careadlinkat (see below), with an additional argument
STACK_BUF that can be used as temporary storage.
- Suppress -Wreturn-local-addr false alarms, as follows.
- If GCC 12+ and -flto is not being used (in which case -DUSING_LTO
- should also be used), simply use a pragma.
- Otherwise, in GCC 10+, do not inline this function
+ In GCC 10+, do not inline this function
to avoid creating a pointer to the stack that
-Wreturn-local-addr incorrectly complains about. See:
https://gcc.gnu.org/PR93644
Although the noinline attribute can hurt performance a bit, no better way
to pacify GCC is known; even an explicit #pragma does not pacify GCC
10 or 11, or GCC 12+ with -flto.
- When the GCC bug is fixed this workaround should be limited to the
+ If the GCC bug is fixed this workaround should be limited to the
broken GCC versions. */
-#if _GL_GNUC_PREREQ (12, 1) && !USING_LTO
-# pragma GCC diagnostic ignored "-Wreturn-local-addr"
-#elif _GL_GNUC_PREREQ (10, 1)
+#if _GL_GNUC_PREREQ (10, 1)
__attribute__ ((__noinline__))
#endif
static char *
