https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123326
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org,
| |redi at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah,
/home/kargl/gcc/obj/prev-x86_64-unknown-freebsd16.0/libstdc++-v3/src/.libs/libstdc++.a(format.o)
/home/kargl/gcc/obj/prev-x86_64-unknown-freebsd16.0/libstdc++-v3/src/.libs/libstdc++.a(new_op.o)
(std::bad_alloc::~bad_alloc())
shows the reason. format.cc is compiled with -std=gnu++26:
# This needs access to std::text_encoding and to the internals of std::locale.
format.lo: format.cc
$(LTCXXCOMPILE) -std=gnu++26 -fno-access-control -c $<
format.o: format.cc
$(CXXCOMPILE) -std=gnu++26 -fno-access-control -c $<
and so defines std::bad_alloc::~bad_alloc() too, not just
libstdc++.a(bad_alloc.o), so it is then a lottery which symbol comes first.
>From user POV it is quite undesirable to link something as large as format.o
(on x86_64-linux with size format.o
text data bss dec hex filename
15554 14416 8 29978 751a format.o
) just to get bad_alloc dtor.
So, this explains why my change sometimes makes the previous bug that using
<format> stuff in a program and linking with -static-libstdc++ doesn't work on
FreeBSD visible even when one actually doesn't use it.
That bug should be fixed some way in any case.
And the second question is whether we shouldn't add some attribute which will
modify the meaning of constexpr keyword (or implicit constexpr) that the
function actually has body only for constant evaluation purposes and nothing
else, for all other purposes it is not inline, can be a key method, and doesn't
have body defined. So, essentially the FE would clear the DECL_DECLARED_INLINE
flag and drop the function's body as soon as the body is saved for constexpr
inlining purposes.
Thoughts about this?
