[Bug libstdc++/111138] views::zip_transform is underconstrained for empty range pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38
--- Comment #2 from Tomasz Kamiński ---
The issue is caused by the fact that we do not check `move_constructible &&
regular_invocable` (required by [range.zip.transform] p2.1.1) for
`sizeof...(_Ts) == 0` case.
```
struct _ZipTransform
{
template
requires (sizeof...(_Ts) == 0) || __detail::__can_zip_transform_view<_Fp,
_Ts...>
constexpr auto
operator() [[nodiscard]] (_Fp&& __f, _Ts&&... __ts) const
...
};
```
[Bug libstdc++/111138] views::zip_transform is underconstrained for empty range pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38 Tomasz Kamiński changed: What|Removed |Added Severity|normal |minor
[Bug libstdc++/111138] views::zip_transform is underconstrained for empty range pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38
Tomasz Kamiński changed:
What|Removed |Added
Last reconfirmed||2025-03-07
Keywords||rejects-valid
Known to fail||13.1.0
Target Milestone|--- |15.0
Status|UNCONFIRMED |NEW
CC||tkaminsk at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Tomasz Kamiński ---
The example that would better illustrate the issue with this not being an
substitution error:
```
#include
template
concept Test = requires() {
std::views::zip_transform(T(0));
};
static_assert(!Test);
```
See: https://godbolt.org/z/xrWaMdP8b
[Bug libstdc++/108053] std::visit_format_arg should hide __int128 and other extensions behind a handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108053 Tomasz Kamiński changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Tomasz Kamiński --- Fixed in v15.
[Bug libstdc++/119246] Result basic_format_arg::check_dynamic_spec is incorrect for extended floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119246 --- Comment #1 from Tomasz Kamiński --- As described in PR108053, this problem is caused by normalization of this floating point types to standard floating point type, where they have same representation. We lost the information about the source type in such cases. To resolve the issue, we want to store the 16, 32, 64 in their respective types directly in the basic_format_arg union. We can do that as we have already reserved enum values for such types (_Arg_f16, ...). In the case of the 128 bit floating point type, most platforms already define multiple 128bits integer types: * __float128 and _Float128 for x86_64 * __iee128, __ibm128 and _Float128 for PowerPC As for IBM we need to store both __iee128 and __ibm128 in handle, as either of them can be long double, we need additional enum value for such type. For x86_64 we should use it to store __float128. This will consistently store _Float128 into the handle on all platforms. The impact on additional indirection should not be that visible when formatting 128bit integer.
[Bug libstdc++/119246] New: Result basic_format_arg::check_dynamic_spec is incorrect for extended floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119246
Bug ID: 119246
Summary: Result basic_format_arg::check_dynamic_spec is
incorrect for extended floating point types
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tkaminsk at gcc dot gnu.org
Target Milestone: ---
Currently for parse_con `ctx.check_dynamic_spec(n)` returns true,
if the argument at the position n have std::bfloat16_t, std::float16_t
(_Float16), std::float32_t (_Float32).
Similary `ctx.check_dynamic_spec(n)` returns true for the
std::float64_t (_Float64).
Code example (https://godbolt.org/z/Enc5WzaKn):
```
#include
template
struct Tester {};
template
struct std::formatter, char> {
constexpr format_parse_context::iterator parse(format_parse_context& ctx)
const {
ctx.check_dynamic_spec(pos);
return ctx.begin();
}
template
Out format(Tester, basic_format_context& ctx) const {
return ctx.out();
}
};
static_assert(std::formattable, char>);
int main() {
(void)std::format("{}{}", Tester<1, float>{}, _Float16{});
(void)std::format("{}{}", Tester<1, double>{}, _Float64{});
//std::format("{}{}", Tester<1, int>{}, _Float16{});
}
```
[Bug libstdc++/108053] std::visit_format_arg should hide __int128 and other extensions behind a handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108053 Tomasz Kamiński changed: What|Removed |Added CC||tkaminsk at gcc dot gnu.org Last reconfirmed|2023-08-08 00:00:00 | --- Comment #4 from Tomasz Kamiński --- The normalization of extended floating point early, has user visible impact on the results for `check_dynamic_spec()`. This problem is separated to PR119246.
[Bug libstdc++/119246] Result basic_format_arg::check_dynamic_spec is incorrect for extended floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119246 Tomasz Kamiński changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-03-12 Status|UNCONFIRMED |NEW
[Bug libstdc++/119121] New: subrange conversion to tuple-like does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119121
Bug ID: 119121
Summary: subrange conversion to tuple-like does not work
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tkaminsk at gcc dot gnu.org
Target Milestone: ---
The following code does not compile:
```
#include
#include
int main() {
std::ranges::subrange s1, s2;
std::pair p = s1;
}
```
https://godbolt.org/z/a7nhP94Tz
This produces error:
: In function 'int main()':
:6:31: error: conversion from 'std::ranges::subrange' to
non-scalar type 'std::pair' requested
6 | std::pair p = s1;
[Bug libstdc++/119121] [14/15 Regression] subrange conversion to tuple-like does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119121 Tomasz Kamiński changed: What|Removed |Added Known to work||13.3.0 Keywords||rejects-valid Known to fail||14.1.0, 15.0 Target Milestone|--- |14.3 Summary|subrange conversion to |[14/15 Regression] subrange |tuple-like does not work|conversion to tuple-like ||does not work
[Bug libstdc++/119121] [14/15 Regression] subrange conversion to tuple-like does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119121 --- Comment #1 from Tomasz Kamiński --- Introduced in g:65b4cba9d6a9ffe9b4d4bdff90727a7064cc0e3b The `is_reference_v<_Vp>` should use `_Tp` instead. ``` template concept __pair_like_convertible_from - = !range<_Tp> && __pair_like<_Tp> + = !range<_Tp> && !is_reference_v<_Vp> && __pair_like<_Tp> && constructible_from<_Tp, _Up, _Vp> && __convertible_to_non_slicing<_Up, tuple_element_t<0, _Tp>> && convertible_to<_Vp, tuple_element_t<1, _Tp>>; ``` This check was previously part of `__pair_like` concept.
[Bug libstdc++/119121] subrange conversion to tuple-like does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119121 Tomasz Kamiński changed: What|Removed |Added Last reconfirmed||2025-03-05 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |tkaminsk at gcc dot gnu.org
[Bug libstdc++/119121] [14 Regression] subrange conversion to pair-like does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119121 --- Comment #2 from Tomasz Kamiński --- Committed to master as r15-7830-g95b2f8d8fb3131
[Bug libstdc++/119246] Result basic_format_arg::check_dynamic_spec is incorrect for extended floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119246 --- Comment #2 from Tomasz Kamiński --- We should also see if we can format `_Float128` and `__float128` by casting to either of them. Similary how we handle `_Float32` and other type now.
[Bug libstdc++/88322] Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322 Bug 88322 depends on bug 108053, which changed state. Bug 108053 Summary: std::visit_format_arg should hide __int128 and other extensions behind a handle https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108053 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/108053] std::visit_format_arg should hide __int128 and other extensions behind a handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108053 Tomasz Kamiński changed: What|Removed |Added Target Milestone|--- |15.0
[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 --- Comment #16 from Tomasz Kamiński --- The changes are also required for .
[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #4 from Tomasz Kamiński --- If want to support user-defined containers, I think we should check if iterator_traits::iterator category exists, before calling insert(Iterator, Iterator) overload. This will prevent hard-errors from older code, that do not handle C++20 iterators. In case where they are supported, users can add insert_range overload.
[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #9 from Tomasz Kamiński --- > Hum, meeting Cpp17LegacyIterator requirements does not mean it is a C++17 > input iterator, only iterator_traits::iterator_category represents its > category, so __cpp17_input_iterator should not be used here. There are more things that insert(pos, it, it) could rely on from the old iterator model, including the iterator being copyable (not only sentinel) or *it++ being well-formed. Checking __cpp17_input_iterator establish that all of above is true. And for that types of iterators iterator_traits::iterator_category will generated correctly.
[Bug libstdc++/119358] _M_rehash_insert of unordered multiset/maps misses casting of difference_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119358 Tomasz Kamiński changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-03-18 Known to fail||15.0 Assignee|unassigned at gcc dot gnu.org |tkaminsk at gcc dot gnu.org Status|UNCONFIRMED |NEW
[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 --- Comment #15 from Tomasz Kamiński --- The still remains to be implemented.
[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #19 from Tomasz Kamiński --- Updated resolution to use __has_input_iter_cat instead of __cpp17_input_iterator.
[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #17 from Tomasz Kamiński --- In the same file we have: __has_input_iter_cat.
[Bug libstdc++/119517] formatter for chrono types are underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119517 Tomasz Kamiński changed: What|Removed |Added Version|13.0|15.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||13.1.0 Keywords||accepts-invalid Last reconfirmed||2025-03-28 Assignee|unassigned at gcc dot gnu.org |tkaminsk at gcc dot gnu.org --- Comment #1 from Tomasz Kamiński --- We should adjust the signature of parse and format functions to accept basic_format_parse_context and basic_format_context respectively. Furthermore we should constrain CharT to char and wchar_t only, as for other formatters.
[Bug libstdc++/111138] views::zip_transform is underconstrained for empty range pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38 Tomasz Kamiński changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tomasz Kamiński --- Fixed on v15.
[Bug libstdc++/116958] std::views::transform loses track of the range size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116958 Bug 116958 depends on bug 111055, which changed state. Bug 111055 Summary: [C++23] Implement P1206R7, Conversions from ranges to containers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 Tomasz Kamiński changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #28 from Tomasz Kamiński --- The P1206R7 is now fully implemented in GCC 15.
[Bug libstdc++/111053] std::ranges::copy is missing important optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111053 Bug 111053 depends on bug 111055, which changed state. Bug 111055 Summary: [C++23] Implement P1206R7, Conversions from ranges to containers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 Bug 119415 depends on bug 111055, which changed state. Bug 111055 Summary: [C++23] Implement P1206R7, Conversions from ranges to containers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/106749] Implement C++23 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 Bug 106749 depends on bug 111055, which changed state. Bug 111055 Summary: [C++23] Implement P1206R7, Conversions from ranges to containers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 Tomasz Kamiński changed: What|Removed |Added Target Milestone|--- |15.0
[Bug libstdc++/119725] std/format/debug.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119725 Tomasz Kamiński changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-04-11 Ever confirmed|0 |1 --- Comment #1 from Tomasz Kamiński --- This is caused by us configuring little-endian UTF32 on big-endian machine. Should be reproductible on intel by using UTF-32BE.
[Bug libstdc++/119725] std/format/debug.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119725
--- Comment #2 from Tomasz Kamiński ---
I do not (yet) have access to solaris machine. Would it be possible for you to
verify that all tests passes with following adjustments:
diff --git a/libstdc++-v3/testsuite/std/format/debug.cc
b/libstdc++-v3/testsuite/std/format/debug.cc
index 07cd1e0e349..71bb7f4a0fe 100644
--- a/libstdc++-v3/testsuite/std/format/debug.cc
+++ b/libstdc++-v3/testsuite/std/format/debug.cc
@@ -1,4 +1,5 @@
-// { dg-options "-fexec-charset=UTF-8 -fwide-exec-charset=UTF-32LE
-DUNICODE_ENC" }
+// { dg-options "-fexec-charset=UTF-8 -fwide-exec-charset=UTF-32LE
-DUNICODE_ENC" { target le } }
+// { dg-options "-fexec-charset=UTF-8 -fwide-exec-charset=UTF-32BE
-DUNICODE_ENC" { target be } }
// { dg-do run { target c++23 } }
// { dg-add-options no_pch }
diff --git a/libstdc++-v3/testsuite/std/format/debug_nonunicode.cc
b/libstdc++-v3/testsuite/std/format/debug_nonunicode.cc
index 5c03171d71a..2ac7e757ea8 100644
--- a/libstdc++-v3/testsuite/std/format/debug_nonunicode.cc
+++ b/libstdc++-v3/testsuite/std/format/debug_nonunicode.cc
@@ -1,4 +1,4 @@
-// { dg-options "-fexec-charset=ISO8859-1 -fwide-exec-charset=UTF-32LE" }
+// { dg-options "-fexec-charset=ISO8859-1" }
// { dg-do run { target c++23 } }
// { dg-add-options no_pch }
[Bug libstdc++/119517] New: formatter for chrono types are underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119517 Bug ID: 119517 Summary: formatter for chrono types are underconstrained Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tkaminsk at gcc dot gnu.org Target Milestone: --- The parse and format methods on the formatters for chrono types, currently accept unconstrained types as template parameter. This in combination with lack of requirements on CharT, leads to situation when formattable is satisfied for std::chrono type Chrono and any type Any. As illustration following static assert passes: static_assert(std::formattable); static_assert(std::formattable); static_assert(std::formattable); static_assert(std::formattable); // https://godbolt.org/z/oYsY3EqrY The standard does not specify signatures for these functions, instead of specifies that enabled specialization for such types are provided. This implies that parse method needs to be valid basic_format_parse_context and format need to acccept basic_format_context for any Out.
[Bug libstdc++/119517] formatter for chrono types are underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119517 Tomasz Kamiński changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tomasz Kamiński --- Fixed in v15.
[Bug libstdc++/119593] Format width is not correctly handled for wide string/characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119593 Tomasz Kamiński changed: What|Removed |Added Summary|Format width is not |Format width is not |correctly handled for |correctly handled for wide |unicode characters |string/characters --- Comment #1 from Tomasz Kamiński --- The
[Bug libstdc++/119593] Format width is not correctly handled for wide string/characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119593 --- Comment #3 from Tomasz Kamiński --- Two separate problems compound in this case: * UTF-32LE, UTF-32BE used for wchar_t, are not recognized as unicode encoding * character with is always assumed to be 1
[Bug libstdc++/119593] Format width is not correctly handled for wide string/characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119593
--- Comment #2 from Tomasz Kamiński ---
The problem is not limited to wide characters, and also appears for wide
strings:
std::format(L"{:+<3}", L"\U0001f921"); // two '+' of paddings
// https://godbolt.org/z/o4s7qTEz9
[Bug libstdc++/119358] _M_rehash_insert of unordered multiset/maps misses casting of difference_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119358 Tomasz Kamiński changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tomasz Kamiński --- Fixed in v15. Thanks for report.
[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #12 from Tomasz Kamiński --- I have realized that with the resolution of the https://cplusplus.github.io/LWG/lwg-defects.html#3749, you can run into this problem by doing: auto r = std::views::iota(__int128(0)) | std::views::take(5) | std::views::common; s.insert_range(r); The GCC does not yet implement this issue (https://gcc.gnu.org/wiki/LibstdcxxTodo), but checking for iterator_traits::iterator_category being derived from input_iterator_tag as you suggested will avoid the issue.
[Bug libstdc++/119517] formatter for chrono types are underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119517 --- Comment #2 from Tomasz Kamiński --- Jonathan noted that zoned_time is specified in standard to accept unconstrained FormatContext in [time.format] p19 (https://eel.is/c++draft/time.format#19).
[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 Tomasz Kamiński changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkaminsk at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Tomasz Kamiński --- Fixed in v15.
[Bug libstdc++/119593] New: Format width is not correctly handled for unicode characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119593
Bug ID: 119593
Summary: Format width is not correctly handled for unicode
characters
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tkaminsk at gcc dot gnu.org
Target Milestone: ---
The following line, produce string with two '+' of padding.
std::format(L"{:+<3}", L'\U0001f921');
// https://godbolt.org/z/b9Mr73Pe5
However as the '\U0001f921' has estimated width 2, only one `+` should be
produced.
This only happens for wchar_t, as single char can represent code points in
ASCII range (<= 0x7f) that all have estimated width of 1.
[Bug libstdc++/119593] Format width is not correctly handled for wide string/characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119593 Tomasz Kamiński changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Version|15.0|14.2.1 --- Comment #6 from Tomasz Kamiński --- Pushed to v15 and backported to v14.
[Bug libstdc++/119840] FAIL: g++.old-deja/g++.robertl/eb73.C -std=gnu++26 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119840 Tomasz Kamiński changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-04-17 Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |tkaminsk at gcc dot gnu.org
[Bug libstdc++/119725] std/format/debug.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119725 Tomasz Kamiński changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkaminsk at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tomasz Kamiński --- Fixed by above commit.
[Bug libstdc++/119840] FAIL: g++.old-deja/g++.robertl/eb73.C -std=gnu++26 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119840 --- Comment #4 from Tomasz Kamiński --- I would like to get confirmation from John David Anglin, that warnings no longer appear on the target.
[Bug libstdc++/119754] std::uninitialized_value_construct does not begin lifetime of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
Tomasz Kamiński changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||tkaminsk at gcc dot gnu.org
Last reconfirmed||2025-04-15
--- Comment #2 from Tomasz Kamiński ---
The `clang` is right here, because allocator::allocate() is specified to
start lifetime of array, but not it's elements
https://eel.is/c++draft/memory#allocator.members-5:
> This function starts the lifetime of the array object, but not that of any of
> the array elements.
However, our implementation just call `::operator new`, that starts lifetime of
both array and it's elements:
```
[[nodiscard,__gnu__::__always_inline__]]
constexpr _Tp*
allocate(size_t __n)
{
if (std::__is_constant_evaluated())
{
if (__builtin_mul_overflow(__n, sizeof(_Tp), &__n))
std::__throw_bad_array_new_length();
return static_cast<_Tp*>(::operator new(__n));
}
return __allocator_base<_Tp>::allocate(__n, 0);
}
```
We could call ~_Tp() for each trivially destructible types, but this will not
help with implicit lifetime aggregates with non-trivial destructor (we cannot
call it).
[Bug libstdc++/119754] std::uninitialized_value_construct does not begin lifetime of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754 --- Comment #3 from Tomasz Kamiński --- Except that `::operator new` does not perform implicit object creation at compile time per https://eel.is/c++draft/intro.object#14: > Except during constant evaluation, any implicit or explicit invocation of a > function named operator new or operator new[] implicitly creates objects in > the returned region of storage and returns a pointer to a suitable created > object.
[Bug libstdc++/119918] New: formattable returns true for types other than char and wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119918 Bug ID: 119918 Summary: formattable returns true for types other than char and wchar_t Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tkaminsk at gcc dot gnu.org Target Milestone: --- We do not constrain the _CharT accepted by the formatter, and as consequence formattable is true for Any type: ``` static_assert(std::formattable); static_assert(std::formattable); ``` // https://godbolt.org/z/858W9vfdT The standard also does not limit acceptable charT, however it does not supporting formatting of pointers/integer (underlying type of native handle) for types other than char and wchar_t.
[Bug libstdc++/119918] formattable returns true for types other than char and wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119918 Tomasz Kamiński changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-04-24 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |tkaminsk at gcc dot gnu.org
[Bug libstdc++/119918] formattable returns true for types other than char and wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119918 --- Comment #1 from Tomasz Kamiński --- This is similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119517.
[Bug libstdc++/109162] C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162
--- Comment #22 from Tomasz Kamiński ---
> That is highly intentional to fix incorrect formatting when the container is
> a string. See https://cplusplus.github.io/LWG/issue3881
I am well aware of this quirk, but my implementation uses range_formatter
in this case, and also produce sequence of characters, instead of string
presentation.
See corresponding test case:
```
// Sequence output is always used
std::queue<_CharT, std::basic_string<_CharT>> qs(
std::from_range,
std::basic_string_view<_CharT>(WIDEN("321")));
res = std::format(WIDEN("{}"), qs);
VERIFY( res == WIDEN("['3', '2', '1']") );
```
So I still see no reason to using formatter> over range_formatter.
[Bug libstdc++/109162] C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 --- Comment #26 from Tomasz Kamiński --- The latest commit (optimization) is for GCC 16 only.
[Bug libstdc++/109162] C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 Tomasz Kamiński changed: What|Removed |Added CC||tkaminsk at gcc dot gnu.org --- Comment #19 from Tomasz Kamiński --- All papers are now fully implemented in for GCC 15.2 and GCC 16.0.
[Bug libstdc++/119918] formattable returns true for types other than char and wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119918 Tomasz Kamiński changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Known to fail||14.1.0, 15.0 Version|14.1.0 |16.0 --- Comment #3 from Tomasz Kamiński --- Fixed in v16.
[Bug libstdc++/109162] C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 --- Comment #24 from Tomasz Kamiński --- > Although it doesn't seem to be in the upcoming GCC-15 release. GCC 15.1 has everything expect formatters for adaptors. So ranges, debug presentation, pair, tuple and std::vector::reference will be in.
