On Wed, Dec 31, 2025 at 11:26:48PM +0100, Florian Weimer wrote:
> * Jakub Jelinek:
>
> > +@cindex @code{constexpr_only} function attribute
> > +@item constexpr_only
> > +The @code{constexpr_only} attribute can be applied to a @code{constexpr}
> > function
> > +declaration. When the function is defined, the function body is only used
> > +for C++ constant evaluation purposes, otherwise the function definition is
> > +treated as a external declaration. If the function is called or has its
> > +address taken and such reference is not optimized away, external definition
> > +without the attribute still needs to be provided in some other translation
> > +units. When used on a @code{virtual constexpr} method, such a method can
> > be
> > +still a key method of the class. This attribute is intended mainly for
> > +functions which were intentionally defined out of line in libraries for
> > +optimization (e.g.@: because the function is very large), key method or ABI
> > +reasons but later on are required or desirable to be evaluable in constant
> > +expressions.
>
> Does this mean that no IPA is performed with the knowledge of the body?
Right (except when doing LTO compilation with the out of line definition in
the link). That is the intent, it preserves the previous behavior except
for being usable in constant expressions.
It is meant for changes like
https://gcc.gnu.org/r16-2183
https://gcc.gnu.org/r16-6038
where e.g. std::exception and tons of classes derived from it changed like
+#if __cplusplus >= 202400L
+ constexpr virtual ~exception() _GLIBCXX_TXN_SAFE_DYN noexcept {}
+#else
virtual ~exception() _GLIBCXX_TXN_SAFE_DYN _GLIBCXX_NOTHROW;
+#endif
and
+#if __cplusplus >= 202400L
+ constexpr virtual const char*
+ what() const _GLIBCXX_TXN_SAFE_DYN noexcept { return "std::exception"; }
+#else
virtual const char*
what() const _GLIBCXX_TXN_SAFE_DYN _GLIBCXX_NOTHROW;
+#endif
The intent was to have those out of line but C++26 comes with the
requirement that those need to be constexpr. The attribute allows them to
be constexpr for constant evaluation purposes and like before otherwise.
> ABI-wise, how does this interact with compilers that do not support
> the attribute if it is used in the intended way? Can the function
> still be made constexpr for those compilers?
It is an attribute, so one needs to assume there will be compilers which
will ignore the attribute. So, the two PRs I've mentioned need to be fixed
some other way anyway (though the FreeBSD one not for the problems it causes
during bootstrap sometimes, as libstdc++.a is I think always compiled by g++
and if it will handle the attribute, the problem is gone unless one actually
needs format.o content when linking libstdc++ statically).
Jakub
