aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3/src
AgeCommit message (Collapse)AuthorFilesLines
2022-11-21build: re-configure 2 filesMartin Liska1-1/+0
libcpp/ChangeLog: * config.in: Re-configure. libstdc++-v3/ChangeLog: * src/experimental/Makefile.in: Re-configure.
2022-11-18libstdc++: add experimental Contracts supportJeff Chapman II5-3/+939
This patch adds the library support for the experimental C++ Contracts implementation. This now consists only of a default definition of the violation handler, which users can override through defining their own version. To avoid ABI stability problems with libstdc++.so this is added to a separate -lstdc++exp static library, which the driver knows to add when it sees -fcontracts. Co-authored-by: Andrew Marmaduke <amarmaduke@lock3software.com> Co-authored-by: Jason Merrill <jason@redhat.com> libstdc++-v3/ChangeLog: * acinclude.m4 (glibcxx_SUBDIRS): Add src/experimental. * include/Makefile.am (experimental_headers): Add contract. * include/Makefile.in: Regenerate. * src/Makefile.am (SUBDIRS): Add experimental. * src/Makefile.in: Regenerate. * configure: Regenerate. * src/experimental/contract.cc: New file. * src/experimental/Makefile.am: New file. * src/experimental/Makefile.in: New file. * include/experimental/contract: New file.
2022-11-16libstdc++: Fix stream initialization with static library [PR107701]Patrick Palka3-2/+3
When linking with a static library, the linker seems to discard a constituent .o object (including its global initializers) if nothing defined in the object is referenced by the program (unless e.g. --whole-archive is used). This behavior breaks iostream with static libstdc++.a (on systems that support init priorities) because we define the global initializer for the standard stream objects in a separate TU (ios_init.cc) from the stream object definitions (globals_io.cc). This patch fixes this by moving the stream initialization object into the same TU that defines the stream objects, so that any use of the streams prevents the linker from discarding this global initializer. PR libstdc++/107701 libstdc++-v3/ChangeLog: * include/std/iostream (__ioinit): Adjust comment. * src/c++98/globals_io.cc: Include "io_base_init.h" here instead of ... * src/c++98/ios_init.cc: ... here. * src/c++98/ios_base_init.h (__ioinit): More comments. * testsuite/17_intro/static.cc: dg-do run instead of just link.
2022-11-14libstdc++: Fix install-debug makefile targetBernhard Reutner-Fischer2-4/+4
This target should have been changed by r13-3918-gba7551485bc576 and now fails. libstdc++-v3/ChangeLog: * src/Makefile.am (install-debug): Remove use of $(debugdir). * src/Makefile.in: Regenerate.
2022-11-12libstdc++: Simplify build targets for debug libraryJonathan Wakely2-79/+56
This rewrites the stamp-debug and build-debug targets in src/Makefile so that each generated Makefile in the debug/$(SUBDIRS) directories is a make target, instead of being created by a loop in the stamp-debug recipe. The final adjustments to debug/Makefile are done as part of the stamp-debug target instead of the build-debug target. The advantage is that each $(SUBDIRS)/debug/Makefile now has the corresponding $(SUBDIRS)/Makefile as a prerequisite, so they will be regenerated if needed. Generating those can also be parallelized by make, although those steps are very fast so that doesn't really matter. This also removes the duplication in the stamp-debug recipe, which was using exactly the same sed command for debug/Makefile and each debug/$(SUBDIRS)/Makefile. That is done by adding "." to the list of subdirectories to process. The recipes can also be simplified to use separate shell commands per line, instead of using backslashes to join the whole recipe into a single shell command. Also replace 'echo `date` > stamp-xxx' with just 'date > stamp-xxx' which is equivalent but simpler. libstdc++-v3/ChangeLog: * src/Makefile.am: Simplify debug build targets. * src/Makefile.in: Regenerate.
2022-11-12libstdc++: Define INSTANTIATE_FACET_ACCESSORS macro in compat source [PR103755]Jonathan Wakely4-11/+22
compatibility-ldbl-alt128.cc re-includes locale-inst-numeric.h and locale-inst-monetary.h but wasn't defining the macros added in r13-3888-gb3ac43a3c05744. Put those macros in a new internal header that can be included everywhere they're used. libstdc++-v3/ChangeLog: PR libstdc++/103755 * src/c++11/locale-inst-monetary.h: Include new header. * src/c++11/locale-inst-numeric.h: Likewise. * src/c++11/locale-inst.cc: Likewise. (INSTANTIATE_USE_FACET, INSTANTIATE_FACET_ACCESSORS): Move macro definitions to ... * src/c++11/facet_inst_macros.h: New file.
2022-11-11libstdc++: Avoid redundant checks in std::use_facet [PR103755]Jonathan Wakely4-92/+37
We do not need to do bounds checks or a runtime dynamic_cast when using std::has_facet and std::use_facet to access the default facets that are guaranteed to be present in every std::locale object. We can just index straight into the array and use a static_cast for the conversion. This patch adds a new std::__try_use_facet function that is like std::use_facet but returns a pointer, so can be used to implement both std::has_facet and std::use_facet. We can then do the necessary metaprogramming to skip the redundant checks in std::__try_use_facet. To avoid having to export (or hide) instantiations of the new function from libstdc++.so the instantiations are given hidden visibility. This allows them to be used in the library, but user code will instantiate it again using the definition in the header. That would happen anyway, because there are no explicit instantiation declarations for any of std::has_facet, std::use_facet, or the new std::__try_use_facet. libstdc++-v3/ChangeLog: PR libstdc++/103755 * config/abi/pre/gnu.ver: Tighten patterns for facets in the base version. Add exports for __try_use_facet. * include/bits/basic_ios.tcc (basic_ios::_M_cache_locale): Use __try_use_facet instead of has_facet and use_facet. * include/bits/fstream.tcc (basic_filebuf::basic_filebuf()): Likewise. (basic_filebuf::imbue): Likewise. * include/bits/locale_classes.h (locale, locale::id) (locale::_Impl): Declare __try_use_facet as a friend. * include/bits/locale_classes.tcc (__try_use_facet): Define new function template with special cases for default facets. (has_facet, use_facet): Call __try_use_facet. * include/bits/locale_facets.tcc (__try_use_facet): Declare explicit instantiations. * include/bits/locale_facets_nonio.tcc (__try_use_facet): Likewise. * src/c++11/locale-inst-monetary.h (INSTANTIATE_FACET_ACCESSORS): Use new macro for facet accessor instantiations. * src/c++11/locale-inst-numeric.h (INSTANTIATE_FACET_ACCESSORS): Likewise. * src/c++11/locale-inst.cc (INSTANTIATE_USE_FACET): Define new macro for instantiating __try_use_facet and use_facet. (INSTANTIATE_FACET_ACCESSORS): Define new macro for also defining has_facet. * src/c++98/compatibility-ldbl.cc (__try_use_facet): Instantiate. * testsuite/22_locale/ctype/is/string/89728_neg.cc: Adjust expected errors.
2022-11-08libstdc++: Fix syntax error in old-glibc case in floating_from_chars.cc ↵Joseph Myers1-1/+1
[PR107562] PR libstdc++/107562 * src/c++17/floating_from_chars.cc (from_chars_impl): Fix syntax error.
2022-11-08libstdc++: Fix up libstdc++ build against glibc 2.25 or older [PR107562]Jakub Jelinek2-2/+4
On Mon, Nov 07, 2022 at 05:48:42PM +0000, Jonathan Wakely wrote: > On Mon, 7 Nov 2022 at 16:11, Joseph Myers <joseph@codesourcery.com> wrote: > > > > On Wed, 2 Nov 2022, Jakub Jelinek via Gcc-patches wrote: > > > > > APIs. So that one can build gcc against older glibc and then compile > > > user programs on newer glibc, the patch uses weak references unless > > > gcc is compiled against glibc 2.26+. strfromf128 unfortunately can't > > > > This support for older glibc doesn't actually seem to be working, on an > > older system with glibc 2.19 I'm seeing > > > > /scratch/jmyers/fsf/gcc-mainline/libstdc++-v3/src/c++17/floating_to_chars.cc:52:3: error: expected initializer before '__asm' > > 52 | __asm ("strfromf128"); > > | ^~~~~ > > > > and a series of subsequent errors. > > This seems to "fix" it (not sure if it's right though): > > #ifndef _GLIBCXX_HAVE_FLOAT128_MATH > extern "C" _Float128 __strtof128(const char*, char**) > __attribute__((__weak__)); > #endif > extern "C" _Float128 __strtof128(const char*, char**) > __asm ("strtof128"); It is, but floating_from_chars.cc has the same problem, and I think we can avoid the duplication, like this: 2022-11-08 Jakub Jelinek <jakub@redhat.com> PR libstdc++/107562 * src/c++17/floating_from_chars.cc (__strtof128): Put __asm before __attribute__. * src/c++17/floating_to_chars.cc (__strfromf128): Likewise.
2022-11-07libstdc++: Update from latest fast_float [PR107468]Jakub Jelinek4-99/+169
The following patch updates from fast_float trunk. That way it grabs two of the 4 LOCAL_PATCHES, some smaller tweaks, to_extended cleanups and most importantly fix for the incorrect rounding case, PR107468 aka https://github.com/fastfloat/fast_float/issues/149 Using std::fegetround showed in benchmarks too slow, so instead of doing that the patch limits the fast path where it uses floating point multiplication rather than integral to cases where we can prove there will be no rounding (the multiplication will be exact, not just that the two multiplication or division operation arguments are exactly representable). 2022-11-07 Jakub Jelinek <jakub@redhat.com> PR libstdc++/107468 * src/c++17/fast_float/MERGE: Adjust for merge from upstream. * src/c++17/fast_float/LOCAL_PATCHES: Remove commits that were upstreamed. * src/c++17/fast_float/README.md: Merge from fast_float 662497742fea7055f0e0ee27e5a7ddc382c2c38e commit. * src/c++17/fast_float/fast_float.h: Likewise. * testsuite/20_util/from_chars/pr107468.cc: New test.
2022-11-07libstdc++: Add _Float128 to_chars/from_chars support for x86, ia64 and ↵Jakub Jelinek2-9/+89
ppc64le with glibc The following patch adds std::{to,from}_chars support for std::float128_t on glibc 2.26+ for {i?86,x86_64,ia64,powerpc64le}-linux. When long double is already IEEE quad, previous changes already handle it by using long double overloads in _Float128 overloads. The powerpc64le case (with explicit or implicit -mabi=ibmlongdouble) is handled by using the __float128/__ieee128 entrypoints which are already in the library and used for -mabi=ieeelongdouble. For i?86, x86_64 and ia64 this patch adds new library entrypoints, mostly by enabling the code that was already there for powerpc64le-linux. Those use __float128 or __ieee128, the patch uses _Float128 for the exported overloads and internally as template parameter. While powerpc64le-linux uses __sprintfieee128 and __strtoieee128, for _Float128 the patch uses the glibc 2.26 strfromf128 and strtof128 APIs. So that one can build gcc against older glibc and then compile user programs on newer glibc, the patch uses weak references unless gcc is compiled against glibc 2.26+. strfromf128 unfortunately can't handle %.0Lf and %.*Le, %.*Lf, %.*Lg format strings sprintf/__sprintfieee128 use, we need to remove the L from those and replace * with actually directly printing the precision into the format string (i.e. it can handle %.0f and %.27f (floating point type is implied from the function name)). Unlike the std::{,b}float16_t support, this one actually exports APIs with std::float128_t aka _Float128 in the mangled name, because no standard format is superset of it. On the other side, e.g. on i?86/x86_64 it doesn't have restrictions like for _Float16/__bf16 which ISAs need to be enabled in order to use it. The denorm_min case in the testcase is temporarily commented out because of the ERANGE subnormal issue Patrick posted patch for. 2022-11-07 Jakub Jelinek <jakub@redhat.com> * include/std/charconv (from_chars, to_chars): Add _Float128 overfloads if _GLIBCXX_HAVE_FLOAT128_MATH is defined. * config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Export _ZSt8to_charsPcS_DF128_, _ZSt8to_charsPcS_DF128_St12chars_format, _ZSt8to_charsPcS_DF128_St12chars_formati and _ZSt10from_charsPKcS0_RDF128_St12chars_format. * src/c++17/floating_from_chars.cc (USE_STRTOF128_FOR_FROM_CHARS): Define if needed. (__strtof128): Declare. (from_chars_impl): Handle _Float128. (from_chars): New _Float128 overload if USE_STRTOF128_FOR_FROM_CHARS is define. * src/c++17/floating_to_chars.cc (__strfromf128): Declare. (FLOAT128_TO_CHARS): Define even when _Float128 is supported and wider than long double. (F128_type): Use _Float128 for that case. (floating_type_traits): Specialize for F128_type rather than __float128. (sprintf_ld): Add length argument. Handle _Float128. (__floating_to_chars_shortest, __floating_to_chars_precision): Pass length to sprintf_ld. (to_chars): Add _Float128 overloads for the F128_type being _Float128 cases. * testsuite/20_util/to_chars/float128_c++23.cc: New test.
2022-11-06libstdc++: Move stream initialization into compiled library [PR44952]Patrick Palka2-0/+14
This patch moves the static object for constructing the standard streams out from <iostream> and into the compiled library on systems that support init priorities. This'll mean <iostream> no longer introduces a separate global constructor in each TU that includes it. We can do this only if the init_priority attribute is supported because we need a way to ensure the stream initialization runs first before any user global initializer, particularly when linking with a static libstdc++.a. PR libstdc++/44952 PR libstdc++/39796 PR libstdc++/98108 libstdc++-v3/ChangeLog: * include/std/iostream (__ioinit): No longer define here if the init_priority attribute is usable. * src/c++98/ios_init.cc (__ioinit): Define here instead if init_priority is usable, via ... * src/c++98/ios_base_init.h: ... this new file.
2022-11-02libstdc++: Remove more redundant union membersJonathan Wakely2-2/+0
We don't need these 'unused' members because they're never used, and a union with a single variant member is fine. libstdc++-v3/ChangeLog: * libsupc++/eh_globals.cc (constant_init::unused): Remove. * src/c++11/system_error.cc (constant_init::unused): Remove. * src/c++17/memory_resource.cc (constant_init::unused): Remove.
2022-11-02libstdc++: Improve ERANGE behavior for fallback FP std::from_charsPatrick Palka1-1/+6
The fallback implementation of floating-point std::from_chars (used for formats other than binary32/64) just calls the C library's strtod family of functions. In case of overflow, the behavior of these functions is rigidly specified: If the correct value overflows and default rounding is in effect, plus or minus HUGE_VAL, HUGE_VALF, or HUGE_VALL is returned (according to the return type and sign of the value), and the value of the macro ERANGE is stored in errno. But in case of underflow, implementations are given more leeway: If the result underflows the functions return a value whose magnitude is no greater than the smallest normalized positive number in the return type; whether errno acquires the value ERANGE is implementation-defined. Thus the fallback implementation can (and does) portably detect overflow, but it can't portably detect underflow. However, glibc (and presumably other high-quality C library implementations) will reliably set errno to ERANGE in case of underflow as well, and it'll also return the nearest denormal number to the correct value (zero in case of true underflow), which allows callers to succesfully parse denormal numbers. So since we can't be perfect here, this patch takes the best effort approach of assuming a high quality C library implementation with respect to this underflow behavior, and refines our implementation to try to distiguish between a denormal result and true underflow by inspecting strtod's return value. libstdc++-v3/ChangeLog: * src/c++17/floating_from_chars.cc (from_chars_impl): In the ERANGE case, distinguish between a denormal result and true underflow by checking if the return value is 0.
2022-11-02libstdc++: Shortest denormal hex std::to_charsJakub Jelinek1-4/+17
On Fri, Oct 28, 2022 at 12:52:44PM -0400, Patrick Palka wrote: > > The following patch on top of > > https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html > > adds std::{,b}float16_t support for std::to_chars. > > When precision is specified (or for std::bfloat16_t for hex mode even if not), > > I believe we can just use the std::to_chars float (when float is mode > > compatible with std::float32_t) overloads, both formats are proper subsets > > of std::float32_t. > > Unfortunately when precision is not specified and we are supposed to emit > > shortest string, the std::{,b}float16_t strings are usually much shorter. > > E.g. 1.e7p-14f16 shortest fixed representation is > > 0.0001161 and shortest scientific representation is > > 1.161e-04 while 1.e7p-14f32 (same number promoted to std::float32_t) > > 0.00011610985 and > > 1.1610985e-04. > > Similarly for 1.38p-112bf16, > > 0.000000000000000000000000000000000235 > > 2.35e-34 vs. 1.38p-112f32 > > 0.00000000000000000000000000000000023472271 > > 2.3472271e-34 > > For std::float16_t there are differences even in the shortest hex, say: > > 0.01p-14 vs. 1p-22 > > but only for denormal std::float16_t values (where all std::float16_t > > denormals converted to std::float32_t are normal), __FLT16_MIN__ and > > everything larger in absolute value than that is the same. Unless > > that is a bug and we should try to discover shorter representations > > even for denormals... > > IIRC for hex formatting of denormals I opted to be consistent with how > glibc printf formats them, instead of outputting the truly shortest > form. > > I wouldn't be against using the float32 overloads even for shortest hex > formatting of float16. The output is shorter but equivalent so it > shouldn't cause any problems. The following patch changes the behavior of the shortest hex denormals, such that they are printed like normals (so for has_implicit_leading_bit with 1p-149 instead of 0.000002p-126 etc., otherwise (Intel extended) with the leading digit before dot being [89abcdef]). I think for all the supported format it is never longer, it can be equal length e.g. for 0.fffffep-126 vs. 1.fffffcp-127 but fortunately no largest subnormal in any format has the unbiased exponent like -9, -99, -999, -9999 because then it would be longer and often it is shorter, sometimes much shorter. For the cases with precision it keeps the handling as is. While for !has_implicit_leading_bit we for normals or with this patch even denormals have really shortest representation, for other formats we sometimes do not, but this patch doesn't deal with that (we always use 1.NNN while we could use 1.NNN up to f.NNN and by that shortening by the last hexit if the last hexit doesn't have least significant bit set and unbiased exponent is not -9, -99, -999 or -9999. 2022-11-02 Jakub Jelinek <jakub@redhat.com> * src/c++17/floating_to_chars.cc (__floating_to_chars_hex): Drop const from unbiased_exponent. Canonicalize denormals such that they have the leading bit set by shifting effective mantissa up and decreasing unbiased_exponent. (__floating_to_chars_shortest): Don't instantiate __floating_to_chars_hex for float16_t either and use float instead. * testsuite/20_util/to_chars/float.cc (float_to_chars_test_cases): Adjust testcases for shortest hex denormals. * testsuite/20_util/to_chars/double.cc (double_to_chars_test_cases): Likewise.
2022-11-01libstdc++: std::from_chars std::{,b}float16_t supportJakub Jelinek1-29/+371
The following patch adds std::from_chars support, similarly to the previous std::to_chars patch through APIs that use float instead of the 16-bit floating point formats as container. The patch uses the fast_float library and doesn't need any changes to it, like the previous patch it introduces wrapper classes around float that represent the float holding float16_t or bfloat16_t value, and specializes binary_format etc. from fast_float for these classes. The new test verifies exhaustively to_chars and from_chars afterward results in the original value (except for nans) in all the fmt cases. 2022-11-01 Jakub Jelinek <jakub@redhat.com> * include/std/charconv (__from_chars_float16_t, __from_chars_bfloat16_t): Declare. (from_chars): Add _Float16 and __gnu_cxx::__bfloat16_t overloads. * config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Export _ZSt22__from_chars_float16_tPKcS0_RfSt12chars_format and _ZSt23__from_chars_bfloat16_tPKcS0_RfSt12chars_format. * src/c++17/floating_from_chars.cc (fast_float::floating_type_float16_t, fast_float::floating_type_bfloat16_t): New classes. (fast_float::binary_format<floating_type_float16_t>, fast_float::binary_format<floating_type_bfloat16_t>): New specializations. (fast_float::to_float<floating_type_float16_t>, fast_float::to_float<floating_type_bfloat16_t>, fast_float::to_extended<floating_type_float16_t>, fast_float::to_extended<floating_type_bfloat16_t>): Likewise. (fast_float::from_chars_16): New template function. (__floating_from_chars_hex): Allow instantiation with fast_float::floating_type_{,b}float16_t. (from_chars): Formatting fixes for float/double/long double overloads. (__from_chars_float16_t, __from_chars_bfloat16_t): New functions. * testsuite/20_util/to_chars/float16_c++23.cc: New test.
2022-11-01libstdc++: std::to_chars std::{,b}float16_t supportJakub Jelinek1-2/+162
The following patch on top of https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html adds std::{,b}float16_t support for std::to_chars. When precision is specified (or for std::bfloat16_t for hex mode even if not), I believe we can just use the std::to_chars float (when float is mode compatible with std::float32_t) overloads, both formats are proper subsets of std::float32_t. Unfortunately when precision is not specified and we are supposed to emit shortest string, the std::{,b}float16_t strings are usually much shorter. E.g. 1.e7p-14f16 shortest fixed representation is 0.0001161 and shortest scientific representation is 1.161e-04 while 1.e7p-14f32 (same number promoted to std::float32_t) 0.00011610985 and 1.1610985e-04. Similarly for 1.38p-112bf16, 0.000000000000000000000000000000000235 2.35e-34 vs. 1.38p-112f32 0.00000000000000000000000000000000023472271 2.3472271e-34 For std::float16_t there are differences even in the shortest hex, say: 0.01p-14 vs. 1p-22 but only for denormal std::float16_t values (where all std::float16_t denormals converted to std::float32_t are normal), __FLT16_MIN__ and everything larger in absolute value than that is the same. Unless that is a bug and we should try to discover shorter representations even for denormals... std::bfloat16_t has the same exponent range as std::float32_t, so all std::bfloat16_t denormals are also std::float32_t denormals and thus the shortest hex representations are the same. As documented, ryu can handle arbitrary IEEE like floating point formats (probably not wider than IEEE quad) using the generic_128 handling, but ryu is hidden in libstdc++.so. As only few architectures support std::float16_t right now and some of them have special ISA requirements for those (e.g. on i?86 one needs -msse2) and std::bfloat16_t is right now supported only on x86 (again with -msse2), perhaps with aarch64/arm coming next if ARM is interested, but I think it is possible that more will be added later, instead of exporting APIs from the library to handle directly the std::{,b}float16_t overloads this patch instead exports functions which take a float which is a superset of those and expects the inline overloads to promote the 16-bit formats to 32-bit, then inside of the library it ensures they are printed right. With the added [[gnu::cold]] attribute because I think most users will primarily use these formats as storage formats and perform arithmetics in the excess precision for them and print also as std::float32_t the added support doesn't seem to be too large, on x86_64: readelf -Ws libstdc++.so.6.0.31 | grep float16_t 912: 00000000000ae824 950 FUNC GLOBAL DEFAULT 13 _ZSt21__to_chars_bfloat16_tPcS_fSt12chars_format@@GLIBCXX_3.4.31 5767: 00000000000ae4a1 899 FUNC GLOBAL DEFAULT 13 _ZSt20__to_chars_float16_tPcS_fSt12chars_format@@GLIBCXX_3.4.31 842: 000000000016d430 106 FUNC LOCAL DEFAULT 13 _ZN12_GLOBAL__N_113get_ieee_reprINS_23floating_type_float16_tEEENS_6ieee_tIT_EES3_ 865: 0000000000170980 1613 FUNC LOCAL DEFAULT 13 +_ZSt23__floating_to_chars_hexIN12_GLOBAL__N_123floating_type_float16_tEESt15to_chars_resultPcS3_T_St8optionalIiE.constprop.0.isra.0 7205: 00000000000ae824 950 FUNC GLOBAL DEFAULT 13 _ZSt21__to_chars_bfloat16_tPcS_fSt12chars_format 7985: 00000000000ae4a1 899 FUNC GLOBAL DEFAULT 13 _ZSt20__to_chars_float16_tPcS_fSt12chars_format so 3568 code bytes together or so. Tested with the attached test (which doesn't prove the shortest representation, just prints std::{,b}float16_t and std::float32_t shortest strings side by side, then tries to verify it can be emitted even into the exact sized range and can't be into range one smaller than that and tries to read what is printed back using from_chars float32_t overload (so there could be double rounding, but apparently there is none for the shortest strings). The only differences printed are for NaNs, where sNaNs are canonicalized to canonical qNaNs and as to_chars doesn't print NaN mantissa, even qNaNs other than the canonical one are read back just as the canonical NaN. Also attaching what Patrick wrote to generate the pow10_adjustment_tab, for std::float16_t only 1.0, 10.0, 100.0, 1000.0 and 10000.0 are powers of 10 in the range because __FLT16_MAX__ is 65504.0, and all of the above are exactly representable in std::float16_t, so we want to use 0 in pow10_adjustment_tab. 2022-11-01 Jakub Jelinek <jakub@redhat.com> * include/std/charconv (__to_chars_float16_t, __to_chars_bfloat16_t): Declare. (to_chars): Add _Float16 and __gnu_cxx::__bfloat16_t overloads. * config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Export _ZSt20__to_chars_float16_tPcS_fSt12chars_format and _ZSt21__to_chars_bfloat16_tPcS_fSt12chars_format. * src/c++17/floating_to_chars.cc (floating_type_float16_t, floating_type_bfloat16_t): New types. (floating_type_traits<floating_type_float16_t>, floating_type_traits<floating_type_bfloat16_t>, get_ieee_repr<floating_type_float16_t>, get_ieee_repr<floating_type_bfloat16_t>, __handle_special_value<floating_type_float16_t>, __handle_special_value<floating_type_bfloat16_t>): New specializations. (floating_to_shortest_scientific): Handle floating_type_float16_t and floating_type_bfloat16_t like IEEE quad. (__floating_to_chars_shortest): For floating_type_bfloat16_t call __floating_to_chars_hex<float> rather than __floating_to_chars_hex<floating_type_bfloat16_t> to avoid instantiating the latter. (__to_chars_float16_t, __to_chars_bfloat16_t): New functions.
2022-10-29libstdc++: Don't use gstdint.h anymoreArsen Arsenović8-11/+4
libstdc++-v3/ChangeLog: * configure.ac: Stop generating gstdint.h. * src/c++11/compatibility-atomic-c++0x.cc: Stop using gstdint.h. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * doc/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * src/c++11/Makefile.in: Regenerate. * src/c++17/Makefile.in: Regenerate. * src/c++20/Makefile.in: Regenerate. * src/c++98/Makefile.in: Regenerate. * src/filesystem/Makefile.in: Regenerate. * src/libbacktrace/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate.
2022-10-19libstdc++/thread: Implement `_GLIBCXX_NPROCS` for WindowsLIU Hao1-0/+9
This makes `std::thread::hardware_concurrency()` return the number of logical processors, instead of zero. libstdc++-v3/ChangeLog: * src/c++11/thread.cc (get_nprocs): Add new implementation for native Windows targets
2022-10-15libstdc++: Fix -Wunused-function warning in src/c++11/debug.ccJonathan Wakely1-8/+8
The only remaining use of print_raw is conditionally compiled, so when libstdc++ i built without debug backtrace support, there's an unused warning function for it. Move it inside the conditional block. libstdc++-v3/ChangeLog: * src/c++11/debug.cc (print_raw): Move inside #if block.
2022-10-14libstdc++: Simplify print_raw function for debug assertionsJonathan Wakely1-13/+8
Replace two uses of print_raw where it's clearer to just use fprintf directly. Then the only remaining use of print_raw is as the print_func argument of pretty_print. When called by pretty_print the count is either a positive integer or -1, so we can simplify print_raw itself. Remove the default argument, because it's never used. Remove the check for nbc == 0, which never happens (but would be harmless if it did). Replace the conditional expression with a single call to fprintf, using INT_MAX as the maximum length. libstdc++-v3/ChangeLog: * src/c++11/debug.cc (print_raw): Simplify. (print_word): Print indentation by calling fprintf directly. (_Error_formatter::_M_error): Print unindented string by calling fprintf directly.
2022-10-11libstdc++: Allow emergency EH alloc pool size to be tuned [PR68606]Jonathan Wakely7-0/+7
Implement a long-standing request to support tuning the size of the emergency buffer for allocating exceptions after malloc fails, or to disable that buffer entirely. It's now possible to disable the dynamic allocation of the buffer and use a fixed-size static buffer, via --enable-libstdcxx-static-eh-pool. This is a built-time choice that is baked into libstdc++ and so affects all code linked against that build of libstdc++. The size of the pool can be set by --with-libstdcxx-eh-pool-obj-count=N which is measured in units of sizeof(void*) not bytes. A given exception type such as std::system_error depends on the target, so giving a size in bytes wouldn't be portable across 16/32/64-bit targets. When libstdc++ is configured to use a dynamic buffer, the size of that buffer can now be tuned at runtime by setting the GLIBCXX_TUNABLES environment variable (c.f. PR libstdc++/88264). The number of exceptions to reserve space for is controlled by the "glibcxx.eh_pool.obj_count" and "glibcxx.eh_pool.obj_size" tunables. The pool will be sized to be able to allocate obj_count exceptions of size obj_size*sizeof(void*) and obj_count "dependent" exceptions rethrown by std::rethrow_exception. With the ability to tune the buffer size, we can reduce the default pool size on 32-bit and 16-bit targets. Most users never need to throw 1kB exceptions in parallel from hundreds of threads after malloc is OOM. The users who do need that can use the tunables to select larger sizes. The old defaults can be chosen at runtime by setting GLIBCXX_TUNABLES to: 64-bit: glibcxx.eh_pool.obj_count=64:glibcxx.eh_pool.obj_size=112 32-bit: glibcxx.eh_pool.obj_count=32:glibcxx.eh_pool.obj_size=104 Or approximated by configuring with: 64-bit: --with-libstdcxx-eh-pool-obj-count=252 32-bit: --with-libstdcxx-eh-pool-obj-count=94 libstdc++-v3/ChangeLog: PR libstdc++/68606 * Makefile.in: Regenerate. * acinclude.m4 (GLIBCXX_EMERGENCY_EH_ALLOC): New macro. * configure: Regenerate. * configure.ac: Use GLIBCXX_EMERGENCY_EH_ALLOC. * crossconfig.m4: Check for secure_getenv. * doc/Makefile.in: Regenerate. * doc/xml/manual/configure.xml: Document new configure options. * doc/xml/manual/evolution.xml: Document addition of tunables. * doc/xml/manual/using_exceptions.xml: Document emergency buffer and tunables. * doc/html/*: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.am: Use EH_POOL_FLAGS. * libsupc++/Makefile.in: Regenerate. * libsupc++/eh_alloc.cc (EMERGENCY_OBJ_SIZE): Define in units of sizeof(void*) not including the ABI's exception header. (EMERGENCY_OBJ_COUNT): Define as target-independent calculation based on word size. (MAX_OBJ_COUNT): Define macro for upper limit on pool size. (pool) [_GLIBCXX_EH_POOL_STATIC]: Use fixed-size buffer. (pool::buffer_size_in_bytes): New static member function. (pool::pool): Parse GLIBCXX_TUNABLES environment variable to set pool size at runtime. (pool::in_pool): Use std::less<void*> for total order. (__freeres) [_GLIBCXX_EH_POOL_STATIC]: Do nothing. (__cxa_free_exception, __cxa_free_dependent_exception): Add [[unlikely]] attributes. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * src/c++11/Makefile.in: Regenerate. * src/c++17/Makefile.in: Regenerate. * src/c++20/Makefile.in: Regenerate. * src/c++98/Makefile.in: Regenerate. * src/filesystem/Makefile.in: Regenerate. * src/libbacktrace/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate.
2022-08-31libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demandFrançois Dumont4-9/+80
Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace generation on _GLIBCXX_DEBUG assertions. Prerequisite is to have configure the lib with: --enable-libstdcxx-backtrace=yes libstdc++-v3/ChangeLog: * include/debug/formatter.h [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_state): Declare. [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_create_state): Declare. [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_callback): Define. [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_error_callback): Define. [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_func): Define. [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full): Declare. [_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_state): New. [_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_full): New. * src/c++11/debug.cc [_GLIBCXX_HAVE_STACKTRACE](print_backtrace): New. (_Error_formatter::_M_error()): Adapt. * src/libbacktrace/Makefile.am: Add backtrace.c. * src/libbacktrace/Makefile.in: Regenerate. * src/libbacktrace/backtrace-rename.h (backtrace_full): New. * testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc: New test. * doc/xml/manual/debug_mode.xml: Document _GLIBCXX_DEBUG_BACKTRACE. * doc/xml/manual/using.xml: Likewise.
2022-08-08libstdc++: [_GLIBCXX_DEBUG] Do not consider detached iterators as ↵François Dumont1-2/+5
value-initialized An attach iterator has its _M_version set to something != 0, the container version. This value shall be preserved when detaching it so that the iterator does not look like a value-initialized one. libstdc++-v3/ChangeLog: * include/debug/formatter.h (__singular_value_init): New _Iterator_state enum entry. (_Parameter<>(const _Safe_iterator<>&, const char*, _Is_iterator)): Check if iterator parameter is value-initialized. (_Parameter<>(const _Safe_local_iterator<>&, const char*, _Is_iterator)): Likewise. * include/debug/safe_iterator.h (_Safe_iterator<>::_M_value_initialized()): New. Adapt checks. * include/debug/safe_local_iterator.h (_Safe_local_iterator<>::_M_value_initialized()): New. Adapt checks. * src/c++11/debug.cc (_Safe_iterator_base::_M_reset): Do not reset _M_version. (print_field(PrintContext&, const _Parameter&, const char*)): Adapt state_names. * testsuite/23_containers/deque/debug/iterator1_neg.cc: New test. * testsuite/23_containers/deque/debug/iterator2_neg.cc: New test. * testsuite/23_containers/forward_list/debug/iterator1_neg.cc: New test. * testsuite/23_containers/forward_list/debug/iterator2_neg.cc: New test. * testsuite/23_containers/forward_list/debug/iterator3_neg.cc: New test.
2022-06-30libstdc++: Improve exceptions thrown from fs::temp_directory_pathJonathan Wakely2-23/+42
Currently the throwing overload of fs::temp_directory_path() will discard the path that was obtained from the environment. When it fails because the path doesn't resolve to a directory you get an unhelpful error like: filesystem error: temp_directory_path: Not a directory It would be better to also print the path in that case, e.g. filesystem error: temp_directory_path: Not a directory [/home/bob/tmp] libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::temp_directory_path()): Include path in exception. (fs::temp_directory_path(error_code&)): Rearrange to more closely match the structure of the first overload. * src/filesystem/ops.cc (fs::temp_directory_path): Likewise. * testsuite/27_io/filesystem/operations/temp_directory_path.cc: Check that exception contains the path. * testsuite/experimental/filesystem/operations/temp_directory_path.cc: Likewise.
2022-06-30libstdc++: Fix experimental::filesystem::status on Windows [PR88881]Jonathan Wakely1-2/+54
Although the Filesystem TS isn't properly supported on Windows (unlike the C++17 Filesystem lib), most tests do pass. Two of the failures are due to PR 88881 which was only fixed for std::filesystem not the TS. This applies the fix to the TS implementation too. libstdc++-v3/ChangeLog: PR libstdc++/88881 * src/filesystem/ops.cc (has_trailing_slash): New helper function. (fs::status): Strip trailing slashes. (fs::symlink_status): Likewise. * testsuite/experimental/filesystem/operations/temp_directory_path.cc: Clean the environment before each test and use TMP instead of TMPDIR so the test passes on Windows.
2022-06-28libstdc++: Fix filesystem build for WindowsJonathan Wakely1-5/+9
I only half remembered to use char_type instead of char for filesystem paths, so that it works with wchar_t on Windows. This fixes the bootstrap failure. libstdc++-v3/ChangeLog: * src/filesystem/dir-common.h (_Dir_base::_At_path): Use char_type consistently for paths.
2022-06-28libstdc++: Improve directory iterator abstractions for openatJonathan Wakely3-43/+73
Currently the _Dir::open_subdir function decides whether to construct a _Dir_base with just a pathname, or a file descriptor and pathname. But that means it is tiughtly coupled to the implementation of _Dir_base::openat, which is what actually decides whether to use a file descriptor or not. If the derived class passes a file descriptor and filename, but the base class expects a full path and ignores the file descriptor, then recursive_directory_iterator cannot recurse. This change introduces a new type that provides the union of all the information available to the derived class (the full pathname, as well as a file descriptor for a directory and another pathname relative to that directory). This allows the derived class to be agnostic to how the base class will use that information. libstdc++-v3/ChangeLog: * src/c++17/fs_dir.cc (_Dir::dir_and_pathname):: Replace with current() returning _At_path. (_Dir::_Dir, _Dir::open_subdir, _Dir::do_unlink): Adjust. * src/filesystem/dir-common.h (_Dir_base::_At_path): New class. (_Dir_base::_Dir_Base, _Dir_base::openat): Use _At_path. * src/filesystem/dir.cc (_Dir::dir_and_pathname): Replace with current() returning _At_path. (_Dir::_Dir, _Dir::open_subdir): Adjust.
2022-06-28libstdc++: Do not optimize away storing pathname if it's neededJonathan Wakely1-1/+1
libstdc++-v3/ChangeLog: * src/c++17/fs_dir.cc (_Dir::_Dir) [!_GLIBCXX_HAVE_OPENAT]: Always store pathname if we don't have openat or unlinkat, because the full path is needed to open sub-directories and remove entries.
2022-06-27libstdc++: check for openat with dirfd in std::filesystemAlexandre Oliva1-1/+1
In the recent patch to check for openat, I missed an occurrence of dirfd in std::filesystem. for libstdc++-v3/ChangeLog * src/c++17/fs_dir.cc (dir_and_pathname): Use dirfd if _GLIBCXX_HAVE_OPENAT.
2022-06-23libstdc++: check for openatAlexandre Oliva2-2/+2
rtems6.0 has fdopendir, and fcntl.h defines AT_FDCWD and declares openat, but there's no openat in libc. Adjust dir-common.h to not assume ::openat just because of AT_FDCWD. for libstdc++-v3/ChangeLog * acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for openat. * configure, config.h.in: Rebuilt. * src/filesystem/dir-common.h (openat): Use ::openat if _GLIBCXX_HAVE_OPENAT. * src/filesystem/dir.cc (dir_and_pathname): Use dirfd if _GLIBCXX_HAVE_OPENAT.
2022-05-26libstdc++: Move std::iostream_category() definition to new fileJonathan Wakely4-50/+90
This fixes a missing symbol when the dual ABI is disabled, e.g. for the versioned namespace build. libstdc++-v3/ChangeLog: * src/c++11/Makefile.am: Add new source file. * src/c++11/Makefile.in: Regenerate. * src/c++11/cxx11-ios_failure.cc (iostream_category): Move to ... * src/c++11/ios_errcat.cc: New file. * testsuite/27_io/ios_base/failure/error_code.cc: Check that std::iostream_category() is defined and used for std::io_errc.
2022-05-19libstdc++: Avoid including <cstdint> for std::char_traitsJonathan Wakely2-0/+6
We should prefer the __UINT_LEAST16_TYPE__ and __UINT_LEAST32_TYPE__ macros, if available, so that we don't need all of <cstdint> in every header that uses std::char_traits. libstdc++-v3/ChangeLog: * include/bits/char_traits.h: Only include <cstdint> when necessary. * include/std/stacktrace: Use __UINTPTR_TYPE__ instead of uintptr_t. * src/c++11/cow-stdexcept.cc: Include <stdint.h>. * src/c++17/floating_to_chars.cc: Likewise. * testsuite/20_util/assume_aligned/1.cc: Include <cstdint>. * testsuite/20_util/assume_aligned/3.cc: Likewise. * testsuite/20_util/shared_ptr/creation/array.cc: Likewise.
2022-05-17libstdc++: Relax memory ordering for default memory resource objectJonathan Wakely1-6/+6
Currently pmr::set_default_resource and pmr::get_default_resource both use sequentially consistent memory ordering. This is overkill. The standard only requires that a call to set_default_resource synchronizes with subsequent calls to set_default_resource and get_default_resource. Using acquire-release for the setter and acquire for the getter is sufficient to meet the requirement. Reviewed-by: Thomas Rodgers <trodgers@redhat.com> libstdc++-v3/ChangeLog: * src/c++17/memory_resource.cc (set_default_resource): Use memory_order_acq_rel. (get_default_resource): Use memory_order_acquire.
2022-05-17libstdc++: Stop defining C++0x compat symbols for versioned namespaceJonathan Wakely8-22/+54
The src/c++11/compatibility*-c++0x.cc files define symbols that need to be exported for ancient versions of libstdc++.so.6 due to changes between C++0x and the final C++11 standard. Those symbols are not needed in the libstdc++.so.8 library, and we can skip building them entirely. This also fixes the build failure I introduced last week when making the versioned namespace config not use the _V2 namespace for compat symbols. libstdc++-v3/ChangeLog: * src/Makefile.am [ENABLE_SYMVERS_GNU_NAMESPACE] (cxx11_sources): Do not build the compatibility*-c++0x.cc objects. * src/Makefile.in: Regenerate. * src/c++11/compatibility-c++0x.cc [_GLIBCXX_INLINE_VERSION]: Refuse to build for the versioned namespace. * src/c++11/compatibility-chrono.cc: Likewise. * src/c++11/compatibility-condvar.cc: Likewise. * src/c++11/compatibility-thread-c++0x.cc: Likewise. * src/c++11/chrono.cc (system_clock, steady_clock): Use macros to define in inline namespace _V2, matching the declarations in <system_error>. * src/c++11/system_error.cc (system_category, generic_category): Likewise.
2022-05-13libstdc++: Make std::thread::_State privateJonathan Wakely1-0/+1
* include/bits/std_thread.h (thread::_State, thread::_State_ptr): Declare as private unless _GLIBCXX_THREAD_IMPL is defined. * src/c++11/thread.cc (_GLIBCXX_THREAD_IMPL): Define.
2022-05-02libstdc++: Don't use std::tolower in <charconv> [PR103911]Patrick Palka1-6/+5
As with std::isdigit in r12-6281-gc83ecfbe74a5cf, we shouldn't be using std::tolower in <charconv> either. PR libstdc++/103911 libstdc++-v3/ChangeLog: * src/c++17/floating_from_chars.cc (find_end_of_float): Accept two delimeters for the exponent part in the form of a possibly NULL string of length two. Don't use std::tolower. (pattern): Adjust calls to find_end_of_float accordingly.
2022-05-02libstdc++: case-sensitivity in hexfloat std::from_chars [PR105441]Patrick Palka1-1/+1
The hexfloat parser for binary32/64 added in r12-6645-gcc3bf3404e4b1c overlooked that the exponent part can also begin with an uppercase 'P'. PR libstdc++/105441 libstdc++-v3/ChangeLog: * src/c++17/floating_from_chars.cc (__floating_from_chars_hex): Also accept 'P' as the start of the exponent. * testsuite/20_util/from_chars/7.cc: Add corresponding testcase.
2022-04-29libstdc++: Add missing exports for ppc64le --with-long-double-format=ibm ↵Jonathan Wakely1-0/+36
[PR105417] The --with-long-double-abi=ibm build is missing some exports that are present in the --with-long-double-abi=ieee build. Those symbols never should have been exported at all, but now that they have been, they should be exported consistently by both ibm and ieee. This simply defines them as aliases for equivalent symbols that are already present. The abi-tag on num_get::_M_extract_int isn't really needed, because it only uses a std::string as a local variable, not in the return type or function parameters, so it's safe to define the _M_extract_int[abi:cxx11] symbols as aliases for the corresponding function without the abi-tag. This causes some new symbols to be added to the GLIBCXX_3.4.29 version for the ibm long double build mode, but there is no advantage to adding them to 3.4.30 for that build. That would just create more inconsistencies. libstdc++-v3/ChangeLog: PR libstdc++/105417 * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Regenerate. * src/c++11/compatibility-ldbl-alt128.cc [_GLIBCXX_USE_DUAL_ABI]: Define __gnu_ieee128::num_get<C>::_M_extract_int[abi:cxx11]<I> symbols as aliases for corresponding symbols without abi-tag.
2022-04-28libstdc++: Fix error reporting in filesystem::copy [PR99290]Jonathan Wakely2-4/+12
The recursive calls to filesystem::copy should stop if any of them reports an error. libstdc++-v3/ChangeLog: PR libstdc++/99290 * src/c++17/fs_ops.cc (fs::copy): Pass error_code to directory_iterator constructor, and check on each iteration. * src/filesystem/ops.cc (fs::copy): Likewise. * testsuite/27_io/filesystem/operations/copy.cc: Check for errors during recursion. * testsuite/experimental/filesystem/operations/copy.cc: Likewise.
2022-04-21libstdc++: Avoid ASCII assumptions in floating_from_chars.ccPatrick Palka1-8/+25
In starts_with_ci and in __floating_from_chars_hex's inf/nan handling, we were assuming that the letters are contiguous and that 'A' + 32 == 'a' which is true for ASCII but not for other character encodings. This patch fixes starts_with_ci by using a constexpr lookup table that maps uppercase letters to lowercase, and fixes __floating_from_chars_hex by using __from_chars_alnum_to_val. libstdc++-v3/ChangeLog: * include/std/charconv (__from_chars_alnum_to_val_table): Simplify initialization of __lower/__upper_letters. (__from_chars_alnum_to_val): Default the template parameter to false. * src/c++17/floating_from_chars.cc (starts_with_ci): Don't assume the uppercase and lowercase letters are contiguous. (__floating_from_chars_hex): Likewise.
2022-04-21libstdc++: Remove bogus assertion in std::from_chars [PR105324]Jonathan Wakely1-1/+0
I'm not sure what I was thinking when I added this assertion, maybe it was supposed to be alignment == 1 (which is what the pmr::string actually uses). The simplest fix is to just remove the assertion. The assertion is no longer enabled by default on trunk, but it's still there for the --enablke-libstdcxx-debug build, and is still wrong. The fix is needed on the gcc-11 branch. libstdc++-v3/ChangeLog: PR libstdc++/105324 * src/c++17/floating_from_chars.cc (buffer_resource::do_allocate): Remove assertion. * testsuite/20_util/from_chars/pr105324.cc: New test.
2022-04-20libstdc++: Use LTLIBICONV when linking libstdc++.so [PR93602]Jonathan Wakely2-2/+6
This fixes missing libiconv symbols when libstdc++ is built on a system that has libiconv installed. If the libiconv headers are found then libstdc++ depends on libiconv_open etc instead of libc's iconv_open. But without this fix libstdc++ is not linked to the libiconv library that provides the definitions of those symbols. As discussed in PR 93602 this changed means that libstdc++.so.6 might have an rpath pointing to the location of the libiconv.so library. If that is not desired, then GCC must be configured to link to a static libiconv.a instead, using either --with-libiconv-type=static or an in-tree build of libiconv. libstdc++-v3/ChangeLog: PR libstdc++/93602 * doc/xml/manual/prerequisites.xml: Document libiconv workarounds. * doc/html/manual/setup.html: Regenerate. * src/Makefile.am (CXXLINK): Add $(LTLIBICONV). * src/Makefile.in: Regenerate.
2022-04-19libstdc++: Stop defining _GLIBCXX_ASSERTIONS in floating_to_chars.ccPatrick Palka1-3/+6
Assertions were originally enabled in the compiled-in floating-point std::to_chars implementation to help shake out any bugs, but they apparently impose a significant performance penalty, most notably for the hex formatting which is around 25% slower with assertions enabled. This seems too high a cost for unconditionally enabling them. The newly added calls to __builtin_unreachable work around the compiler no longer knowing that the set of valid values of 'fmt' is limited (which was previously upheld by an assert). libstdc++-v3/ChangeLog: * src/c++17/floating_to_chars.cc (_GLIBCXX_ASSERTIONS): Don't define. (__floating_to_chars_shortest): Add __builtin_unreachable calls to squelch false-positive -Wmaybe-uninitialized and -Wreturn-type warnings. (__floating_to_chars_precision): Likewise.
2022-04-15libstdc++: Optimize integer std::from_charsPatrick Palka1-16/+2
This applies the following optimizations to the integer std::from_chars implementation: 1. Use a lookup table for converting an alphanumeric digit to its base-36 value instead of using a range test (for 0-9) and switch (for a-z and A-Z). The table is constructed using a C++14 constexpr function which doesn't assume a particular character encoding or __CHAR_BIT__ value. This new conversion function __from_chars_alnum_to_val is templated on whether we care only about the decimal digits, in which case we can perform the conversion with a single subtraction since the digit characters are guaranteed to be contiguous (unlike the letters). 2. Generalize __from_chars_binary to handle all power-of-two bases. This function (now named __from_chars_pow2_base) is also templated on whether we care only about the decimal digits for the benefit of faster digit conversion for base 2, 4 and 8. 3. In __from_chars_digit, use static_cast<unsigned char>(__c - '0') < __base instead of '0' <= __c && __c <= ('0' + (__base - 1)). as the digit recognition test (exhaustively verified that the two tests are equivalent). 4. In __from_chars_alnum, use a nested loop to consume the rest of the digits in the overflow case (mirroring __from_chars_digit) so that the main loop doesn't have to maintain the overflow flag __valid. At this point, __from_chars_digit is nearly identical to __from_chars_alnum, so this patch merges the two functions by removing the former and templatizing the latter according to whether we care only about the decimal digits. Finally, 5. In __from_chars_alnum, maintain a lower bound on the number of unused bits in the result and use it to omit the overflow check when it's safe to do so. In passing, this patch replaces the non-portable function ascii_to_hexit used by __floating_from_chars_hex with the new conversion function. Some runtime measurements for a simple 15-line benchmark that roundtrips printing/parsing 200 million integers via std::to/from_chars (average of 5 runs): Base Before After (seconds, lower is better) 2 9.37 9.37 3 15.79 12.13 8 4.15 3.67 10 4.90 3.86 11 6.84 5.03 16 4.14 2.93 32 3.85 2.39 36 5.22 3.26 libstdc++-v3/ChangeLog: * include/std/charconv (__from_chars_alnum_to_val_table): Define. (__from_chars_alnum_to_val): Define. (__from_chars_binary): Rename to ... (__from_chars_pow2_base): ... this. Generalize to handle any power-of-two base using __from_chars_alnum_to_val. (__from_chars_digit): Optimize digit recognition to a single test instead of two tests. Use [[__unlikely___]] attribute. (__from_chars_alpha_to_num): Remove. (__from_chars_alnum): Use __from_chars_alnum_to_val. Use a nested loop for the overflow case. Maintain a lower bound on the number of available bits in the result and use it to omit the overflow check. (from_chars): Adjust appropriately. * src/c++17/floating_from_chars.cc (ascii_to_hexit): Remove. (__floating_from_chars_hex): Use __from_chars_alnum_to_val to recognize a hex digit instead.
2022-04-01libstdc++: Implement std::unreachable() for C++23 (P0627R6)Jonathan Wakely1-2/+5
This defines std::unreachable as an assertion for debug mode, a trap when _GLIBCXX_ASSERTIONS is defined, and __builtin_unreachable() otherwise. The reason for only using __builtin_trap() in the second case is to avoid the overhead of setting up a call to __glibcxx_assert_fail that should never happen. UBsan can detect if __builtin_unreachable() is executed, so if a feature test macro for that sanitizer is added, we could change just use __builtin_unreachable() when the sanitizer is enabled. While thinking about what the debug assertion failure should print, I noticed that the __glibcxx_assert_fail function doesn't check for null pointers. This adds a check so we don't try to print them if null. libstdc++-v3/ChangeLog: * include/std/utility (unreachable): Define for C++23. * include/std/version (__cpp_lib_unreachable): Define. * src/c++11/debug.cc (__glibcxx_assert_fail): Check for valid arguments. Handle only the function being given. * testsuite/20_util/unreachable/1.cc: New test. * testsuite/20_util/unreachable/version.cc: New test.
2022-03-18libstdc++: Reduce header dependencies from PSTL headers [PR92546]Jonathan Wakely1-0/+1
This avoids including the whole of <functional> in <algorithm>, as the <pstl/glue_algorithm_defs.h> header only actually needs std::pair. This also avoids including <iterator> in <pstl/utils.h>, which only needs <type_traits>, std::bad_alloc, and std::terminate (which can be repalced with std::__terminate). This matters less, because <pstl/utils.h> is only included by the <pstl/*_impl.h> headers and they all use <iterator> anyway, and are only included by <execution>. libstdc++-v3/ChangeLog: PR libstdc++/92546 * include/pstl/glue_algorithm_defs.h: Replace <functional> with <bits/stl_pair.h>. * include/pstl/utils.h: Replace <iterator> with <type_traits>. (__pstl::__internal::__except_handler): Use std::__terminate instead of std::terminate. * src/c++17/fs_path.cc: Include <array>. * testsuite/25_algorithms/adjacent_find/constexpr.cc: Include <functional>. * testsuite/25_algorithms/binary_search/constexpr.cc: Likewise. * testsuite/25_algorithms/clamp/constrained.cc: Likewise. * testsuite/25_algorithms/equal/constrained.cc: Likewise. * testsuite/25_algorithms/for_each/constrained.cc: Likewise. * testsuite/25_algorithms/includes/constrained.cc: Likewise. * testsuite/25_algorithms/is_heap/constexpr.cc: Likewise. * testsuite/25_algorithms/is_heap_until/constexpr.cc: Likewise. * testsuite/25_algorithms/is_permutation/constrained.cc: Include <iterator>. * testsuite/25_algorithms/is_sorted/constexpr.cc: Include <functional>. * testsuite/25_algorithms/is_sorted_until/constexpr.cc: Likewise. * testsuite/25_algorithms/lexicographical_compare/constexpr.cc: Likewise. * testsuite/25_algorithms/lexicographical_compare/constrained.cc: Likewise. * testsuite/25_algorithms/lexicographical_compare_three_way/1.cc: Include <array>. * testsuite/25_algorithms/lower_bound/constexpr.cc: Include <functional>. * testsuite/25_algorithms/max/constrained.cc: Likewise. * testsuite/25_algorithms/max_element/constrained.cc: Likewise. * testsuite/25_algorithms/min/constrained.cc: Likewise. * testsuite/25_algorithms/min_element/constrained.cc: Likewise. * testsuite/25_algorithms/minmax_element/constrained.cc: Likewise. * testsuite/25_algorithms/mismatch/constexpr.cc: Likewise. * testsuite/25_algorithms/move/93872.cc: Likewise. * testsuite/25_algorithms/move_backward/93872.cc: Include <iterator>. * testsuite/25_algorithms/nth_element/constexpr.cc: Include <functional>. * testsuite/25_algorithms/partial_sort/constexpr.cc: Likewise. * testsuite/25_algorithms/partial_sort_copy/constexpr.cc: Likewise. * testsuite/25_algorithms/search/constexpr.cc: Likewise. * testsuite/25_algorithms/search_n/constrained.cc: Likewise. * testsuite/25_algorithms/set_difference/constexpr.cc: Likewise. * testsuite/25_algorithms/set_difference/constrained.cc: Likewise. * testsuite/25_algorithms/set_intersection/constexpr.cc: Likewise. * testsuite/25_algorithms/set_intersection/constrained.cc: Likewise. * testsuite/25_algorithms/set_symmetric_difference/constexpr.cc: Likewise. * testsuite/25_algorithms/set_union/constexpr.cc: Likewise. * testsuite/25_algorithms/set_union/constrained.cc: Likewise. * testsuite/25_algorithms/sort/constexpr.cc: Likewise. * testsuite/25_algorithms/sort_heap/constexpr.cc: Likewise. * testsuite/25_algorithms/transform/constrained.cc: Likewise. * testsuite/25_algorithms/unique/constexpr.cc: Likewise. * testsuite/25_algorithms/unique/constrained.cc: Likewise. * testsuite/25_algorithms/unique_copy/constexpr.cc: Likewise. * testsuite/25_algorithms/upper_bound/constexpr.cc: Likewise. * testsuite/std/ranges/adaptors/elements.cc: Include <vector>. * testsuite/std/ranges/adaptors/lazy_split.cc: Likewise. * testsuite/std/ranges/adaptors/split.cc: Likewise.
2022-03-16libstdc++: Ensure that std::from_chars is declared when supportedJonathan Wakely1-81/+39
This adjusts the declarations in <charconv> to match when the definition is present. This solves the issue that std::from_chars is present on Solaris 11.3 (using fast_float) but was not declared in the header (because the declarations were guarded by _GLIBCXX_HAVE_USELOCALE). Additionally, do not define __cpp_lib_to_chars unless both from_chars and to_chars are supported (which is only true for IEEE float and double). We might still provide from_chars (via strtold) but if to_chars isn't provided, we shouldn't define the feature test macro. Finally, this simplifies some of the preprocessor checks in the bodies of std::from_chars in src/c++17/floating_from_chars.cc and hoists the repeated code for the strtod version into a new function template. N.B. the long double overload of std::from_chars will always be defined if the float and double overloads are defined. We can always use one of strtold or fast_float's binary64 routines (although the latter might produce errors for some long double values if they are not representable as binary64). libstdc++-v3/ChangeLog: * include/std/charconv (__cpp_lib_to_chars): Only define when both from_chars and to_chars are supported for floating-point types. (from_chars, to_chars): Adjust preprocessor conditions guarding declarations. * include/std/version (__cpp_lib_to_chars): Adjust condition to match <charconv> definition. * src/c++17/floating_from_chars.cc (from_chars_strtod): New function template. (from_chars): Simplify preprocessor checks and use from_chars_strtod when appropriate.
2022-03-14libstdc++: Fix reading UTF-8 characters for 16-bit targets [PR104875]Jonathan Wakely1-7/+7
The current code in read_utf8_code_point assumes that integer promotion will create a 32-bit int, but that's not true for 16-bit targets like msp430 and avr. This changes the intermediate variables used for each octet from unsigned char to char32_t, so that (c << N) works correctly when N > 8. libstdc++-v3/ChangeLog: PR libstdc++/104875 * src/c++11/codecvt.cc (read_utf8_code_point): Use char32_t to hold octets that will be left-shifted.
2022-03-10libstdc++: Do not use fast_float for 16-bit size_t [PR104870]Jonathan Wakely1-1/+2
The preprocessor condition for using fast_float should match the one in the header, and require at least 32-bit size_t. libstdc++-v3/ChangeLog: PR libstdc++/104870 * src/c++17/floating_from_chars.cc: Check __SIZE_WIDTH__ >= 32 before using fast_float.
generated by cgit v1.1 at 2025-07-14 06:46:59 +0000