This patch updates the Solaris baselines for the GLIBCXX_3.4.33 version
added in GCC 14.0.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each), together with the GLIBCXX_3.4.32 update, on both gcc-14 branch
and trunk.
2024-04-28 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.
This patch updates the Solaris baselines for the GLIBCXX_3.4.32 version
added in GCC 13.2.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each) on the gcc-13 branch and (together with the GLIBCXX_3.4.33 update)
on both gcc-14 branch and trunk.
2024-04-28 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.
(cherry picked from commit 3e1ca512848994950cc0641986b6ec337df5765f)
While the previous patch was regeneration from 13.2 release (with hand
edits for arches I don't have libraries for but which are still well
maintained), thius one is regeneration from the trunk (this time for
hand edits everywhere for the PR114692
https://gcc.gnu.org/pipermail/libstdc++/2024-April/058570.html
patch; plus again hand edits for arches I don't have libraries for).
2024-04-11 Jakub Jelinek <jakub@redhat.com>
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
I added this new symbol in the wrong version. GLIBCXX_3.4.32 was
already used for the GCC 13.2.0 release, so the new symbol should have
been in a new GLIBCXX_3.4.33 version.
Additionally, the pattern doesn't need to use [cw] because we only ever
use __basic_file<char>, even for std::basic_filebuf<wchar_t>.
libstdc++-v3/ChangeLog:
PR libstdc++/114692
* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Move new exports for
__basic_file::native_handle to ...
(GLIBCXX_3.4.33): ... here. Adjust to not match wchar_t
specialization, which isn't used.
* testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.33 and update
latest version check.
The following patch regenerates the ABI files for 13 branch (I've only changed
the Linux files which were updated in r13-7289, all but m68k, riscv64 and
powerpc64 are from actual Fedora 39 gcc builds, the rest hand edited).
We've added one symbol very early in the 13.2 cycle, but then added 2
further ones very soon afterwards, quite a long time before 13.2 release
and haven't regenerated. The patch applies cleanly to trunk as well.
2024-04-11 Jakub Jelinek <jakub@redhat.com>
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
a platform that lacks __cxa_thread_atexit_impl, even if the program is
built and run using that toolchain on a (later) platform that offers
__cxa_thread_atexit_impl.
This patch adds runtime testing for __cxa_thread_atexit_impl on select
platforms (GNU variants, for starters) that support weak symbols.
for libstdc++-v3/ChangeLog
PR libstdc++/112858
* config/os/gnu-linux/os_defines.h
(_GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL): Define.
* libsupc++/atexit_thread.cc [__GXX_WEAK__ &&
_GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL]
(__cxa_thread_atexit): Add dynamic detection of
__cxa_thread_atexit_impl.
The new __basic_file::native_handle() function can be added for C++11
and above, because the names "native_handle" and "native_handle_type"
are already reserved since C++11. Exporting those symbols from the
shared library does no harm, even if the feature gets dropped before the
C++23 standard is final.
The new member functions of std::fstream etc. are only declared for
C++26 and so are not instantiated in src/c++11/fstream-inst.cc. Declare
them with the always_inline attribute so that no symbol definitions are
needed in the library (we can change this later when C++26 support is
less experimental).
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_CHECK_FILEBUF_NATIVE_HANDLES): New
macro.
* config.h.in: Regenerate.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Export new
basic_filebuf members.
* config/io/basic_file_stdio.cc (__basic_file::native_handle):
Define new function.
* config/io/basic_file_stdio.h (__basic_file::native_handle):
Declare new function.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_CHECK_FILEBUF_NATIVE_HANDLES.
* include/bits/version.def (fstream_native_handles): New macro.
* include/bits/version.h: Regenerate.
* include/std/fstream (basic_filebuf::native_handle)
(basic_fstream::native_handle, basic_ifstream::native_handle)
(basic_ofstream::native_handle): New functions.
* src/c++11/Makefile.am: Move compilation of basic_file.cc,
locale_init.cc and localename.cc to here.
* src/c++11/Makefile.in: Regenerate.
* src/c++98/locale_init.cc: Moved to...
* src/c++11/locale_init.cc: ...here.
* src/c++98/localename.cc: Moved to...
* src/c++11/localename.cc: ...here.
* src/c++98/Makefile.am: Remove basic_file.cc, locale_init.cc
and localename.cc from here.
* src/c++98/Makefile.in: Regenerate.
* testsuite/27_io/basic_filebuf/native_handle/version.cc: New test.
* testsuite/27_io/basic_fstream/native_handle/char/1.cc: New test.
* testsuite/27_io/basic_fstream/native_handle/wchar_t/1.cc: New test.
* testsuite/27_io/basic_ifstream/native_handle/char/1.cc: New test.
* testsuite/27_io/basic_ifstream/native_handle/wchar_t/1.cc: New test.
* testsuite/27_io/basic_ofstream/native_handle/char/1.cc: New test.
* testsuite/27_io/basic_ofstream/native_handle/wchar_t/1.cc: New test.
For LoongArch, the toplevel library build is always aliased to
one of the multilib variants. This patch installs it with the
actual MULTISUBDIR (instead of ".") so that the headers can be
reached by the compiler.
This patch is an update of
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629435.html
libstdc++-v3/ChangeLog:
* configure.host: Register t-loongarch in tmake_file.
* config/cpu/loongarch/t-loongarch: New file. Manually refresh
MULTISUBDIR with $(shell $(CXX) --print-multi-directory).
For targets where double and long double have the same representation we
can reuse the same __convert_to_v code for both types. This will
slightly reduce the size of the compiled code in the library.
libstdc++-v3/ChangeLog:
* config/locale/generic/c_locale.cc (__convert_to_v): Reuse
double overload for long double if possible.
Instead of using fopen64, lseek64, and fstat64 we can just include
<bits/largefile-config.h> which defines _FILE_OFFSET_BITS=64 (and
similar target-specific macros). Then we can just use fopen, lseek and
fstat as normal, and they'll be the LFS versions if supported by the
target.
libstdc++-v3/ChangeLog:
* config/io/basic_file_stdio.cc: Define LFS macros.
(__basic_file<char>::open): Use fopen unconditionally.
(get_file_offset): Use lseek unconditionally.
(__basic_file<char>::seekoff): Likewise.
(__basic_file<char>::showmanyc): Use fstat unconditionally.
When configured with --enable-cstdio=stdio_pure we need to consistently
use fseek and not mix seeks on the file descriptor with reads and writes
on the FILE stream.
There are also a number of bugs related to error handling and return
values, because fread and fwrite return 0 on error, not -1, and fseek
returns 0 on success, not the file offset.
libstdc++-v3/ChangeLog:
PR libstdc++/110574
* acinclude.m4 (GLIBCXX_CHECK_LFS): Check for fseeko and ftello
and define _GLIBCXX_USE_FSEEKO_FTELLO.
* config.h.in: Regenerate.
* configure: Regenerate.
* config/io/basic_file_stdio.cc (xwrite) [_GLIBCXX_USE_STDIO_PURE]:
Check for fwrite error correctly.
(__basic_file<char>::xsgetn) [_GLIBCXX_USE_STDIO_PURE]: Check for
fread error correctly.
(get_file_offset): New function.
(__basic_file<char>::seekoff) [_GLIBCXX_USE_STDIO_PURE]: Use
fseeko if available. Use get_file_offset instead of return value
of fseek.
(__basic_file<char>::showmanyc): Use get_file_offset.
The first parameter of fwrite should be the const char* __s which want
write to FILE *__file, rather than the FILE *__file write to the FILE
*__file.
libstdc++-v3/ChangeLog:
* config/io/basic_file_stdio.cc (xwrite) [USE_STDIO_PURE]: Fix
first argument.
[except.handle]/7 says that when we enter std::terminate due to a throw,
that is considered an active handler. We already implemented that properly
for the case of not finding a handler (__cxa_throw calls __cxa_begin_catch
before std::terminate) and the case of finding a callsite with no landing
pad (the personality function calls __cxa_call_terminate which calls
__cxa_begin_catch), but for the case of a throw in a try/catch in a noexcept
function, we were emitting a cleanup that calls std::terminate directly
without ever calling __cxa_begin_catch to handle the exception.
A straightforward way to fix this seems to be calling __cxa_call_terminate
instead. However, that requires exporting it from libstdc++, which we have
not previously done. Despite the name, it isn't actually part of the ABI
standard. Nor is __cxa_call_unexpected, as far as I can tell, but that one
is also used by clang. For this case they use __clang_call_terminate; it
seems reasonable to me for us to stick with __cxa_call_terminate.
I also change __cxa_call_terminate to take void* for simplicity in the front
end (and consistency with __cxa_call_unexpected) but that isn't necessary if
it's undesirable for some reason.
This patch does not fix the issue that representing the noexcept as a
cleanup is wrong, and confuses the handler search; since it looks like a
cleanup in the EH tables, the unwinder keeps looking until it finds the
catch in main(), which it should never have gotten to. Without the
try/catch in main, the unwinder would reach the end of the stack and say no
handler was found. The noexcept is a handler, and should be treated as one,
as it is when the landing pad is omitted.
The best fix for that issue seems to me to be to represent an
ERT_MUST_NOT_THROW after an ERT_TRY in an action list as though it were an
ERT_ALLOWED_EXCEPTIONS (since indeed it is an exception-specification). The
actual code generation shouldn't need to change (apart from the change made
by this patch), only the action table entry.
PR c++/97720
gcc/cp/ChangeLog:
* cp-tree.h (enum cp_tree_index): Add CPTI_CALL_TERMINATE_FN.
(call_terminate_fn): New macro.
* cp-gimplify.cc (gimplify_must_not_throw_expr): Use it.
* except.cc (init_exception_processing): Set it.
(cp_protect_cleanup_actions): Return it.
gcc/ChangeLog:
* tree-eh.cc (lower_resx): Pass the exception pointer to the
failure_decl.
* except.h: Tweak comment.
libstdc++-v3/ChangeLog:
* libsupc++/eh_call.cc (__cxa_call_terminate): Take void*.
* config/abi/pre/gnu.ver: Add it.
gcc/testsuite/ChangeLog:
* g++.dg/eh/terminate2.C: New test.
P1463R1 made it ill-formed for allocator-aware containers (including
std::basic_string) to use an allocator that has a different value_type
from the container itself. We already enforce that for other containers
(since r8-4828-g866e4d3853ccc0), but not for std::basic_string. We
traditionally accepted it as an extension and rebound the allocator, so
this change only adds the enforcement for C++20 and later.
Similarly, P1148R0 made it ill-formed for strings and streams to use a
traits type that has an incorrect char_type. We already enforce that for
std::basic_string_view, so we just need to add it to std::basic_ios and
std::basic_string.
The assertion for the allocator's value_type caused some testsuite
regressions:
FAIL: 21_strings/basic_string/cons/char/deduction.cc (test for excess errors)
FAIL: 21_strings/basic_string/cons/wchar_t/deduction.cc (test for excess errors)
FAIL: 21_strings/basic_string/requirements/explicit_instantiation/debug.cc (test for excess errors)
FAIL: 21_strings/basic_string/requirements/explicit_instantiation/int.cc (test for excess errors)
The last two are testing the traditional extension that rebinds the
allocator, so need to be disabled for C++20.
The first two are similar to LWG 3076 where an incorrect constructor is
considered for CTAD. In this case, determining that it's not viable
requires instantiating std::basic_string<Iter, char_traits<Iter>, Alloc>
which then fails the new assertion, because Alloc::value_type is not the
same as Iter. This is only a problem because the size_type parameter of
the non-viable constructor is an alias for
_Alloc_traits_impl<A>::size_type which is a nested type, and so the
enclosing basic_string specialization needs to be instantiated. If we
remove the _Alloc_traits_impl wrapper that was added in
r12-5413-g2d76292bd6719d, then the definition of size_type no longer
depends on basic_string, and we don't instantiate an invalid
specialization and don't fail the assertion. The work done by
_Alloc_traits_impl::allocate can be done in a _S_allocate function
instead, which is probably more efficient to compile anyway.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver: Export basic_string::_S_allocate.
* include/bits/basic_ios.h: Add static assertion checking
traits_type::value_type.
* include/bits/basic_string.h: Likewise. Do not rebind
allocator, and add static assertion checking its value_type.
(basic_string::_Alloc_traits_impl): Remove class template.
(basic_string::_S_allocate): New static member function.
(basic_string::assign): Use _S_allocate.
* include/bits/basic_string.tcc (basic_string::_M_create)
(basic_string::reserve, basic_string::_M_replace): Likewise.
* testsuite/21_strings/basic_string/requirements/explicit_instantiation/debug.cc:
Disable for C++20 and later.
* testsuite/21_strings/basic_string/requirements/explicit_instantiation/int.cc:
Likweise.
This is an ABI problem on powerpc64le-linux, introduced in 13.1.
When libstdc++ is configured against old glibc, the
_ZSt10from_charsPKcS0_RDF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_St12chars_formati@@GLIBCXX_3.4.31
symbols are exported from the library, while when it is configured against
new enough glibc, those symbols aren't exported and we export instead
_ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128St12chars_formati@@GLIBCXX_IEEE128_3.4.29
together with various other @@GLIBCXX_IEEE128_3.4.{29,30,31} and
@@CXXABI_IEEE128_1.3.13 symbols. The idea was that those *IEEE128* symbol
versions (similarly to *LDBL* symbol versions) are optional (but if it
appears, all symbols from it up to the version of the library appears),
but the base appears always.
My _Float128 from_chars/to_chars changes unfortunately broke this.
I believe nothing really uses those symbols if libstdc++ has been
configured against old glibc, so if 13.1 wasn't already released, it might
be best to make sure they aren't exported on powerpc64le-linux.
But as they were exported, I think the best resolution for this ABI
difference is to add those 4 symbols as aliases to the
GLIBCXX_IEEE128_3.4.29 *u9__ieee128* symbols, which the following patch
does.
2023-05-03 Jakub Jelinek <jakub@redhat.com>
* src/c++17/floating_from_chars.cc
(_ZSt10from_charsPKcS0_RDF128_St12chars_format): New alias to
_ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format.
* src/c++17/floating_to_chars.cc (_ZSt8to_charsPcS_DF128_): New alias to
_ZSt8to_charsPcS_u9__ieee128.
(_ZSt8to_charsPcS_DF128_St12chars_format): New alias to
_ZSt8to_charsPcS_u9__ieee128St12chars_format.
(_ZSt8to_charsPcS_DF128_St12chars_formati): New alias to
_ZSt8to_charsPcS_u9__ieee128St12chars_formati.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Updated.
As discussed on IRC, my _Float128/_Float64x support changes broke
abi.exp testing on powerpc64-linux.
The
_ZTIDF128_@@CXXABI_1.3.14
_ZTIDF64x@@CXXABI_1.3.14
_ZTIPDF128_@@CXXABI_1.3.14
_ZTIPDF64x@@CXXABI_1.3.14
_ZTIPKDF128_@@CXXABI_1.3.14
_ZTIPKDF64x@@CXXABI_1.3.14
symbols only appear on powerpc64le-linux (both when building against
very old glibcs as well as contemporary glibcs), while they don't
appear on powerpc64-linux, because the latter never has _Float128 or
_Float64x support.
But we were using the same baseline_symbols.txt file for both
powerpc64-linux and powerpc64le-linux, even when it contained quite a lot
of stuff specific to the latter; but that was just the IEEE128 related
stuff that appears only when configured against not very old glibc.
The following patch keeps those exports as is and just splits the
config/abi/post/ files, copies the current one to powerpc64le-linux
unmodified and removes the above mentioned symbols plus all
GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbols
from the powerpc64-linux version.
2023-05-03 Jakub Jelinek <jakub@redhat.com>
* configure.host (abi_baseline_pair): Use powerpc64le-linux-gnu
rather than powerpc64-linux-gnu for powerpc64le*-linux*.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Remove
_ZTI*DF128_, _ZTI*DF64x symbols and symbols in
GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbol
versions.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: New
file.
The following patch regenerates the ABI files (I've only changed the
Linux files which were updated recently (last month)).
2023-05-02 Jakub Jelinek <jakub@redhat.com>
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
GCC used to emit an instance of an empty ios_base::Init class in
every TU which included <iostream> to ensure it is std::cout etc.
is initialized, but thanks to Patrick work on some targets (which have
init_priority attribute support) it is now initialized only inside of
libstdc++.so.6/libstdc++.a.
This causes a problem if people do something that has never been supported,
try to run GCC 13 compiled C++ code against GCC 12 or earlier
libstdc++.so.6 - std::cout etc. are then never initialized because code
including <iostream> expects the library to initialize it and the library
expects code including <iostream> to do that.
The following patch is second attempt to make this work cheaply as the
earlier attempt of aliasing the std::cout etc. symbols with another symbol
version didn't work out due to copy relocation breaking the aliases appart.
The patch forces just a _ZSt21ios_base_library_initv undefined symbol
into all *.o files which include <iostream> and while there is no runtime
relocation against that, it seems to enforce the right version of
libstdc++.so.6. /home/jakub/src/gcc/obj08i/usr/local/ is the install
directory of trunk patched with this patch, /home/jakub/src/gcc/obj06/
is builddir of trunk without this patch, system g++ is GCC 12.1.1.
$ cat /tmp/hw.C
#include <iostream>
int
main ()
{
std::cout << "Hello, world!" << std::endl;
}
$ cd /home/jakub/src/gcc/obj08i/usr/local/bin
$ ./g++ -o /tmp/hw /tmp/hw.C
$ readelf -Wa /tmp/hw 2>/dev/null | grep initv
4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZSt21ios_base_library_initv@GLIBCXX_3.4.32 (4)
71: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZSt21ios_base_library_initv@GLIBCXX_3.4.32
$ /tmp/hw
/tmp/hw: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/hw)
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ /tmp/hw
/tmp/hw: /home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/hw)
$ g++ -o /tmp/hw /tmp/hw.C
$ /tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ /tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw
Hello, world!
On sparc-sun-solaris2.11 one I've actually checked a version which had
defined(_GLIBCXX_SYMVER_SUN) next to defined(_GLIBCXX_SYMVER_GNU), but
init_priority attribute doesn't seem to be supported there and so I couldn't
actually test how this works there. Using gas and Sun ld, Rainer, does one
need to use gas + gld for init_priority or something else?
2023-04-28 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/108969
* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Export
_ZSt21ios_base_library_initv.
* testsuite/util/testsuite_abi.cc (check_version): Add GLIBCXX_3.4.32
symver and make it the latestp.
* src/c++98/ios_init.cc (ios_base_library_init): New alias.
* acinclude.m4 (libtool_VERSION): Change to 6:32:0.
* include/std/iostream: If init_priority attribute is supported
and _GLIBCXX_SYMVER_GNU, force undefined _ZSt21ios_base_library_initv
symbol into the object.
* configure: Regenerated.
The linker script is preprocessed with $(top_builddir)/config.h not the
include/$target/bits/c++config.h version, which means that configure
macros do not have the _GLIBCXX_ prefix yet.
The _GLIBCXX_SYMVER_GNU and _GLIBCXX_SHARED checks are redundant,
because the gnu.ver file is only used for _GLIBCXX_SYMVER_GNU and the
linker script is only used for the shared library. Remove those.
libstdc++-v3/ChangeLog:
PR libstdc++/108969
* config/abi/pre/gnu.ver: Fix preprocessor condition.
Since GCC 13 the global iostream objects are only initialized once in
libstdc++, and not by a std::ios::Init object in every translation unit
that includes <iostream>. To avoid using uninitialized streams defined
in an older libstdc++.so, translation units using the global iostreams
should depend on the GLIBCXX_3.4.31 symver.
Define std::cin as std::__io::cin and then export it as
std::cin@@GLIBCXX_3.4.31 so that references to std::cin bind to the new
symver. Also export it as @GLIBCXX_3.4 for backwards compatibility
libstdc++-v3/ChangeLog:
PR libstdc++/108969
* src/Makefile.am: Move globals_io.cc to here.
* src/Makefile.in: Regenerate.
* src/c++98/Makefile.am: Remove globals_io.cc from here.
* src/c++98/Makefile.in: Regenerate.
* src/c++98/globals_io.cc [_GLIBCXX_SYMVER_GNU] (cin): Adjust
symbol name and then export with GLIBCXX_3.4.31 symver.
(cout, cerr, clog, wcin, wcout, wcerr, wclog): Likewise.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt:
Regenerate.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/pre/gnu.ver: Add iostream objects to new symver.
On Tue, Mar 07, 2023 at 05:50:39PM +0000, Jonathan Wakely via Gcc-patches wrote:
> I guess you want to regenerate the powerpc64 ones now. The others are
> all OK for trunk.
So the following patch updates powerpc64 which has been excluded from
the last patch (the difference between the older and current patch is
-+FUNC:_ZSt15__try_use_facetINSt19__gnu_cxx11_ieee1289money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEEEEPKT_RKSt6locale@@GLIBCXX_3.4.31
-+FUNC:_ZSt15__try_use_facetINSt19__gnu_cxx11_ieee1289money_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEEEEPKT_RKSt6locale@@GLIBCXX_3.4.31
-+FUNC:_ZSt15__try_use_facetINSt19__gnu_cxx11_ieee1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEEEEPKT_RKSt6locale@@GLIBCXX_3.4.31
-+FUNC:_ZSt15__try_use_facetINSt19__gnu_cxx11_ieee1289money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEEEEPKT_RKSt6locale@@GLIBCXX_3.4.31
++FUNC:_ZSt15__try_use_facetINSt19__gnu_cxx11_ieee1289money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEEEEPKT_RKSt6locale@@GLIBCXX_IEEE128_3.4.31
++FUNC:_ZSt15__try_use_facetINSt19__gnu_cxx11_ieee1289money_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEEEEPKT_RKSt6locale@@GLIBCXX_IEEE128_3.4.31
++FUNC:_ZSt15__try_use_facetINSt19__gnu_cxx11_ieee1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEEEEPKT_RKSt6locale@@GLIBCXX_IEEE128_3.4.31
++FUNC:_ZSt15__try_use_facetINSt19__gnu_cxx11_ieee1289money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEEEEPKT_RKSt6locale@@GLIBCXX_IEEE128_3.4.31
which is I think exactly what we want) and also updates aarch64 for the
bfloat16_t tinfo symbols.
2023-03-13 Jakub Jelinek <jakub@redhat.com>
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
x86_64/i686 has for a few months working std::bfloat16_t support, __bf16
there is no longer a storage only type, but can be used for arithmetics
and is supported in libgcc and libstdc++.
The following patch adds similar support for AArch64.
Unlike the x86 changes, this one keeps the old __bf16 mangling of
u6__bf16 rather than DF16b (so an exception from Itanium ABI), but
otherwise __bf16 and decltype (0.0bf16) are the same type and both
in C++ act as extended floating-point type.
2023-03-13 Jakub Jelinek <jakub@redhat.com>
gcc/
* config/aarch64/aarch64.h (aarch64_bf16_type_node): Remove.
(aarch64_bf16_ptr_type_node): Adjust comment.
* config/aarch64/aarch64.cc (aarch64_gimplify_va_arg_expr): Use
bfloat16_type_node rather than aarch64_bf16_type_node.
(aarch64_libgcc_floating_mode_supported_p,
aarch64_scalar_mode_supported_p): Also support BFmode.
(aarch64_invalid_conversion, aarch64_invalid_unary_op): Remove.
(aarch64_invalid_binary_op): Remove BFmode related rejections.
(TARGET_INVALID_CONVERSION, TARGET_INVALID_UNARY_OP): Don't redefine.
* config/aarch64/aarch64-builtins.cc (aarch64_bf16_type_node): Remove.
(aarch64_int_or_fp_type): Use bfloat16_type_node rather than
aarch64_bf16_type_node.
(aarch64_init_simd_builtin_types): Likewise.
(aarch64_init_bf16_types): Likewise. Don't create bfloat16_type_node,
which is created in tree.cc already.
* config/aarch64/aarch64-sve-builtins.def (svbfloat16_t): Likewise.
gcc/testsuite/
* gcc.target/aarch64/sve/acle/general-c/ternary_bfloat16_opt_n_1.c:
Don't expect one __bf16 related error.
* gcc.target/aarch64/bfloat16_vector_typecheck_1.c: Adjust or remove
dg-error directives for __bf16 being an extended arithmetic type.
* gcc.target/aarch64/bfloat16_vector_typecheck_2.c: Likewise.
* gcc.target/aarch64/bfloat16_scalar_typecheck.c: Likewise.
* g++.target/aarch64/bfloat_cpp_typecheck.C: Don't expect two __bf16
related errors.
libgcc/
* config/aarch64/t-softfp (softfp_extensions): Add bfsf.
(softfp_truncations): Add tfbf dfbf sfbf hfbf.
(softfp_extras): Add floatdibf floatundibf floattibf floatuntibf.
* config/aarch64/libgcc-softfp.ver (GCC_13.0.0): Export
__extendbfsf2 and __trunc{s,d,t,h}fbf2.
* config/aarch64/sfp-machine.h (_FP_NANFRAC_B, _FP_NANSIGN_B): Define.
* soft-fp/floatundibf.c: New file.
* soft-fp/floatdibf.c: New file.
libstdc++-v3/
* config/abi/pre/gnu.ver (CXXABI_1.3.14): Also export __bf16 tinfos
if it isn't mangled as DF16b but u6__bf16.
This updates baseline_symbols.txt for the Fedora 39 arches.
Most of the added symbols are added to all 5 files, exceptions are
DF16_ rtti stuff (only added on x86 and aarch64 which supports those),
DF16b rtti stuff (only x86 right now), _M_replace_cold (m vs. j
differences), DF128_ charconv (only x86), GLIBCXX_LDBL_3.4.31
symver (s390x), _M_get_sys_info/_M_get_local_info (l vs. x).
I was using
grep ^+ | sed 's/OBJECT:[0-9]*:/OBJECT:/' | sort | uniq -c | sort -n | less
on the patch to analyze.
powerpc64le-linux not included because I'll need to regenerate it.
2023-03-07 Jakub Jelinek <jakub@redhat.com>
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
libstdc++-v3/ChangeLog:
PR libstdc++/108882
* config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Adjust patterns to
not match symbols in namespace std::__gnu_cxx11_ieee128.
* config/os/gnu-linux/ldbl-ieee128-extra.ver: Add patterns for
std::__gnu_cxx11_ieee128::money_{get,put}.
This is notably needed because in glibc 2.34, the move of pthread functions
into libc.so happened for Linux only, not GNU/Hurd.
The pthread_self() function can also always be used fine as it is on
GNU/Hurd.
libstdc++-v3/ChangeLog:
* config/os/gnu-linux/os_defines.h [!__linux__]
(_GLIBCXX_NATIVE_THREAD_ID, _GLIBCXX_GTHREAD_USE_WEAK): Do not define.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
With -fkeep-inline-functions there are linker errors when including
<filesystem>. This happens because there are some filesystem::path
constructors defined inline which call non-exported functions defined in
the library. That's usually not a problem, because those constructors
are only called by code that's also inside the library. But when the
header is compiled with -fkeep-inline-functions those inline functions
are emitted even though they aren't called. That then creates an
undefined reference to the other library internsl. The fix is to just
move the private constructors into the library where they are called.
That way they are never even seen by users, and so not compiled even if
-fkeep-inline-functions is used.
On trunk there is a second problem, which is that the new equality
operators for comparing directory iterators with default_sentinel use
the shared_ptr::operator bool() conversion operator. The shared_ptr
specializations used by directory iterators are explicitly instantiated
in the library, but the bool conversion operators are not exported. This
causes linker errors at -O0 or with -fkeep-inline-functions. That just
requires the conversion operators to be exported.
libstdc++-v3/ChangeLog:
PR libstdc++/108636
* config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Export shared_ptr
conversion operators for directory iterator comparisons with
std::default_sentinel_t.
* include/bits/fs_path.h (path::path(string_view, _Type))
(path::_Cmpt::_Cmpt(string_view, _Type, size_t)): Move inline
definitions to ...
* src/c++17/fs_path.cc: ... here.
* testsuite/27_io/filesystem/path/108636.cc: New test.
The abr-libc <errno.h> does not define EOVERFLOW, which means that
std::errc::value_too_large is not defined, and so <charconv> cannot be
compiled. Define value_too_large for avr with a value that does not
clash with any that is defined in <errno.h>. This is a kluge to fix
bootstrap for avr; it can be removed after PR libstdc++/104883 is
resolved.
The avr-libc <errno.h> fails to meet the C and POSIX requirements that
each error macro has a distinct integral value, and is usable in #if
directives. Add a special case for avr to system_error.cc so that only
the valid errors are recognized. Also disable the errno checks in
std::filesystem::remove_all that assume a meaningful value for errno.
On avr-libc <unistd.h> exists but does not define the POSIX functions
needed by std::filesystem, so _GLIBCXX_HAVE_UNISTD_H is not sufficient
to check for basic POSIX APIs. Check !defined __AVR__ as well as
_GLIBCXX_HAVE_UNISTD_H before using those functions. This is a kluge and
we should really have a specific macro that says the required functions
are available.
libstdc++-v3/ChangeLog:
* config/os/generic/error_constants.h (errc::value_too_large)
[__AVR__]: Define.
* src/c++11/system_error.cc
(system_category::default_error_condition) [__AVR__]: Only match
recognize values equal to EDOM, ERANGE, ENOSYS and EINTR.
* src/c++17/fs_ops.cc (fs::current_path) [__AVR__]: Do not check
for ENOENT etc. in switch.
(fs::remove_all) [__AVR__]: Likewise.
* src/filesystem/ops-common.h [__AVR__]: Do not use POSIX open,
close etc.
GCC 13 has a new implementation of gthr-win32.h which supports C++11
mutexes, threads etc. but this causes an unintended ABI break. The
__gthread_mutex_t type is always used in std::basic_filebuf even in
C++98, so independent of whether C++11 sync primitives work or not.
Because that type changed for the win32 thread model, we have a layout
change in std::basic_filebuf. The member is completely unused, it just
gets passed to the std::__basic_file constructor and ignored. So we
don't need that mutex to actually work, we just need its layout to not
change.
Introduce a new __gthr_win32_legacy_mutex_t struct in gthr-win32.h with
the old layout, and conditionally use that in std::basic_filebuf.
PR libstdc++/108331
libgcc/ChangeLog:
* config/i386/gthr-win32.h (__gthr_win32_legacy_mutex_t): New
struct matching the previous __gthread_mutex_t struct.
(__GTHREAD_LEGACY_MUTEX_T): Define.
libstdc++-v3/ChangeLog:
* config/io/c_io_stdio.h (__c_lock): Define as a typedef for
__GTHREAD_LEGACY_MUTEX_T if defined.
The new symbols need to be exported, as well as some of the
std::locale::facet::id globals, which are not new but were presumably
not needed by any inline functions before now.
libstdc++-v3/ChangeLog:
PR libstdc++/108327
* config/os/gnu-linux/ldbl-extra.ver (GLIBCXX_LDBL_3.4.31):
Export __try_use_facet specializations for facets in namespace
__gnu_cxx_ldbl128.
* config/os/gnu-linux/ldbl-ieee128-extra.ver
(GLIBCXX_IEEE128_3.4.31): Likewise for facets in namespace
__gnu_cxx_ieee128.
* testsuite/util/testsuite_abi.cc: Add to lists of known and
latest versions.
