Re: [PATCH 2/2] libstdc++: use new built-in trait __is_pointer
Am Mo., 10. Juli 2023 um 07:24 Uhr schrieb Ken Matsui via Libstdc++
:
>
> This patch lets libstdc++ use new built-in trait __is_pointer.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_pointer): Use __is_pointer
> built-in trait.
> (is_pointer_v): Likewise.
>
> Signed-off-by: Ken Matsui
> ---
> libstdc++-v3/include/std/type_traits | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/include/std/type_traits
> b/libstdc++-v3/include/std/type_traits
> index 0e7a9c9c7f3..d83db98403b 100644
> --- a/libstdc++-v3/include/std/type_traits
> +++ b/libstdc++-v3/include/std/type_traits
> @@ -515,6 +515,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> struct is_array<_Tp[]>
> : public true_type { };
>
> + /// is_pointer
> +#if __has_builtin(__is_pointer)
> + template
> +struct is_pointer
> +: public __bool_constant<__is_pointer(_Tp)>
> +{ };
> +#else
>template
> struct __is_pointer_helper
> : public false_type { };
> @@ -523,11 +530,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> struct __is_pointer_helper<_Tp*>
> : public true_type { };
>
> - /// is_pointer
>template
> struct is_pointer
> : public __is_pointer_helper<__remove_cv_t<_Tp>>::type
> { };
> +#endif
>
>/// is_lvalue_reference
>template
> --
> 2.41.0
Shouldn't this adjust is_pointer_v as well?
Thanks,
- Daniel
Re: [committed] libstdc++: Fix constexpr functions in
Am Do., 30. März 2023 um 18:00 Uhr schrieb Jonathan Wakely via Libstdc++ : > [..] > > In fact, thinking about P2641 some more, I might revert this change. > Instead of adding an extra bool member to support constexpr, I think > I'll just remove the 'constexpr' keywords from basic_endpoint for now, > and implement it in terms of just inspecting the sa_family_t member of > the union members. And then later, once we have something like P2641, > we can re-add the constexpr keywords and use is_within_lifetime during > constant evaluation. That way we don't add a bool then need to take it > away again, changing the ABI each time. I was just going to make the same suggestion. - Daniel
Re: [committed] libstdc++: Add missing __cpp_lib_format macro to
Am Mi., 22. März 2023 um 18:53 Uhr schrieb Jonathan Wakely via Libstdc++ : > > Tested powerpc64le-linux, pushed to trunk. > > -- >8-- > > libstdc++-v3/ChangeLog: > > * include/std/version (__cpp_lib_format): Define. > * testsuite/std/format/functions/format.cc: Check it. > --- > libstdc++-v3/include/std/version | 1 + > .../testsuite/std/format/functions/format.cc | 15 +++ > 2 files changed, 16 insertions(+) > > diff --git a/libstdc++-v3/include/std/version > b/libstdc++-v3/include/std/version > index 25ebfc3e512..a19c39c6cdd 100644 > --- a/libstdc++-v3/include/std/version > +++ b/libstdc++-v3/include/std/version > @@ -277,6 +277,7 @@ > #define __cpp_lib_constexpr_utility 201811L > #define __cpp_lib_constexpr_vector 201907L > #define __cpp_lib_erase_if 202002L > +#define __cpp_lib_format 202106L Shouldn't the value be 202207L? (This of-course of your conforming completeness) Thanks, - Daniel
Re: [committed] libstdc++: Fix preprocessor condition for inline variables
Am Di., 14. März 2023 um 12:02 Uhr schrieb Jonathan Wakely : > > On Tue, 14 Mar 2023 at 10:51, Daniel Krügler wrote: >> >> Apologies for the late response: >> > > I only just committed the change, so it's not delayed :-) > > >> >> What about changing the test to check for __cpp_inline_variables or >> combining it with __cpp_variable_templates instead? >> > > We could do that, but it would complicate their use. > > Currently they're only used in C++17 code (chrono::floor etc.) and C++20 code > (chrono::hh_mm_ss etc. and chrono formatters). We know it's OK for C++17 and > C++20 code to use __is_duration_v and __is_time_point_v because they're > defined for C++17 and later. > > If we change them to be defined for __cpp_inline_variables && > __cpp_variable_templates then what changes? It should be safe to assume we > can still use them in C++17 and C++20 code, but could we also use them > elsewhere, e.g. in C++14 code such as chrono::literals? Maybe, but only if > __cpp_inline_variables is defined for C++14 mode, and if it's not, then we'd > need something like: > > #if __cplusplus >= 201402L > template > #if __cpp_inline_variables > enable_if_t<__is_duration_v<_Dur>, _Dur> > #else > enable_if_t<__is_duration<_Dur>::value, _Dur> > #endif > foo(const _Dur&); > #endif > > And this is not an improvement over simply: > > #if __cplusplus >= 201402L > template > enable_if_t<__is_duration<_Dur>::value, _Dur> > foo(const _Dur&); > #endif > > So I don't see why we would want to do it. I think it was a mistake for me to > ever make them depend on __cpp_variable_templates, instead of just depending > on C++17. I think it's better to fix that mistake. Sounds reasonable, thanks. - Daniel
Re: [committed] libstdc++: Fix preprocessor condition for inline variables
Am Di., 14. März 2023 um 11:32 Uhr schrieb Jonathan Wakely via Libstdc++ : > > Tested x86_64-linux. Pushed to trunk. > > -- >8 -- > > Although variable templates are valid in C++14, inline ones aren't. > These are only used in C++17 (or later) code, so they don't need to be > defined for C++14. > > libstdc++-v3/ChangeLog: > > * include/bits/chrono.h (__is_duration_v, __is_time_point_v): > Only define for C++17 and later. > --- > libstdc++-v3/include/bits/chrono.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libstdc++-v3/include/bits/chrono.h > b/libstdc++-v3/include/bits/chrono.h > index b2e4f4c33a8..fb99fe5eed7 100644 > --- a/libstdc++-v3/include/bits/chrono.h > +++ b/libstdc++-v3/include/bits/chrono.h > @@ -244,7 +244,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION >using __disable_if_is_duration > = typename enable_if::value, _Tp>::type; > > -#if __cpp_variable_templates > +#if __cplusplus >= 201703L > template >inline constexpr bool __is_duration_v = false; > template > -- > 2.39.2 Apologies for the late response: What about changing the test to check for __cpp_inline_variables or combining it with __cpp_variable_templates instead? Thanks, - Daniel
Re: [PATCH] libstdc++: Add Doxygen comment for string::resize_and_overwite
Am Do., 23. Feb. 2023 um 18:38 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> Reviews of the resize_and_overwite description welcome. I've tried to
> strike a balance between pedantic precision and user-friendliness.
>
> -- >8 --
>
> This is a complicated API that should be clearly documented.
>
> Also improve the comment on basic_ios::_M_setstate.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/basic_ios.h (basic_ios::_M_setstate): Add
> caveat to comment.
> * include/bits/basic_string.h (resize_and_overwrite): Add
> doxygen comment.
> ---
> libstdc++-v3/include/bits/basic_ios.h| 2 +-
> libstdc++-v3/include/bits/basic_string.h | 28
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/include/bits/basic_ios.h
> b/libstdc++-v3/include/bits/basic_ios.h
> index e0667b7d049..d0a4e7d3dfd 100644
> --- a/libstdc++-v3/include/bits/basic_ios.h
> +++ b/libstdc++-v3/include/bits/basic_ios.h
> @@ -159,7 +159,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>// Flip the internal state on for the proper state bits, then
>// rethrows the propagated exception if bit also set in
> - // exceptions().
> + // exceptions(). Must only be called within a catch handler.
>void
>_M_setstate(iostate __state)
>{
> diff --git a/libstdc++-v3/include/bits/basic_string.h
> b/libstdc++-v3/include/bits/basic_string.h
> index c81dc0d425a..1abac655fd1 100644
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -1117,6 +1117,34 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>
> #if __cplusplus > 202002L
> #define __cpp_lib_string_resize_and_overwrite 202110L
> + /** Resize the string and call a function to fill it.
> + *
> + * @param __n The maximum size requested.
> + * @param __op A callable object that writes characters to the string.
> + *
> + * This is a low-level function that is easy to misuse, be careful.
> + *
> + * Calling `str.resize_and_overwrite(n, op)` will reserve at least `n`
> + * characters in `str`, evaluate `n2 = std::move(op)(str.data(), n)`,
> + * and finally set the string length to `n2` (adding a null terminator
> + * at the end). The function object `op` is allowed to write to the
> + * extra capacity added by the initial reserve operation, which is not
> + * allowed if you just call `str.reserve(n)` yourself.
> + *
> + * This can be used to efficiently fill a `string` buffer without the
> + * overhead of zero-initializing characters that will be overwritten
> + * anyway.
> + *
> + * The callable `op` not access the string directly (only through the
Did you mean "The callable `op` must not access the string
directly" instead?
- Daniel
Re: [committed] libstdc++: Improve performance of chrono::utc_clock::now()
Am Do., 17. Nov. 2022 um 10:48 Uhr schrieb Jonathan Wakely :
>
>
>
> On Thu, 17 Nov 2022 at 09:47, Jonathan Wakely wrote:
>>
>>
>>
>> On Thu, 17 Nov 2022 at 09:25, Daniel Krügler
>> wrote:
>>>
>>> Am Do., 17. Nov. 2022 um 10:07 Uhr schrieb Jonathan Wakely
>>> :
>>> >
>>> >
>>> >
>>> > On Thu, 17 Nov 2022, 06:30 Daniel Krügler via Libstdc++,
>>> > wrote:
>>> >>
>>> >> Am Mi., 16. Nov. 2022 um 22:00 Uhr schrieb Jonathan Wakely via
>>> >> Libstdc++ :
>>> >> >
>>> >> > Tested x86_64-linux. Pushed to trunk.
>>> >> >
>>> >> > -- >8 --
>>> >> >
>>> >> > We can use an array instead of a std::vector, and we can avoid the
>>> >> > binary search for the common case of a time point after the most recent
>>> >> > leap second. On one system where I tested this, utc_clock::now() now
>>> >> > takes about 16ns instead of 31ns.
>>> >> >
>>> >> > libstdc++-v3/ChangeLog:
>>> >> >
>>> >> > * include/std/chrono (get_leap_second_info): Optimize.
>>> >> > ---
>>> >> > libstdc++-v3/include/std/chrono | 31 ---
>>> >> > 1 file changed, 24 insertions(+), 7 deletions(-)
>>> >> >
>>> >> > diff --git a/libstdc++-v3/include/std/chrono
>>> >> > b/libstdc++-v3/include/std/chrono
>>> >> > index 90b73f8198e..2468023f6c5 100644
>>> >> > --- a/libstdc++-v3/include/std/chrono
>>> >> > +++ b/libstdc++-v3/include/std/chrono
>>> >> > @@ -2747,9 +2747,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>> >> >{
>>> >> > if constexpr (is_same_v<_Duration, seconds>)
>>> >> > {
>>> >> > - // TODO move this function into the library and get leaps
>>> >> > from tzdb.
>>> >> > - vector __leaps
>>> >> > - {
>>> >> > + const seconds::rep __leaps[] {
>>> >> > 78796800, // 1 Jul 1972
>>> >> > 94694400, // 1 Jan 1973
>>> >> >126230400, // 1 Jan 1974
>>> >> > @@ -2778,12 +2776,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>> >> > 1435708800, // 1 Jul 2015
>>> >> > 1483228800, // 1 Jan 2017
>>> >> > };
>>> >> > + // The list above is known to be valid until 2023-06-28
>>> >> > 00:00:00 UTC
>>> >> > + const seconds::rep __expires = 1687910400;
>>> >> > + const seconds::rep __s = __ut.time_since_epoch().count();
>>> >> >
>>> >> > - auto __s = __ut.time_since_epoch().count();
>>> >> > - auto __pos = std::upper_bound(__leaps.begin(),
>>> >> > __leaps.end(), __s);
>>> >> > + const seconds::rep* __first = std::begin(__leaps);
>>> >> > + const seconds::rep* __last = std::end(__leaps);
>>> >> > +
>>> >> > + if (__s > __expires)
>>> >> > + {
>>> >> > + // TODO: use updated leap_seconds from tzdb
>>> >> > +#if 0
>>> >> > + auto __db = get_tzdb_list().begin();
>>> >> > + __first = __db->leap_seconds.data();
>>> >> > + __last = __first + __db->leap_seconds.size();
>>> >> > +#endif
>>> >> > + }
>>> >> > +
>>> >> > + // Don't bother searching the list if we're after the last
>>> >> > one.
>>> >> > + if (__s > __last[-1])
>>> >> > + return { false, seconds(__last - __first) };
>>> >> > +
>>> >> > + auto __pos = std::upper_bound(__first, __last, __s);
>>> >> > return {
>>> >> > - __pos != __leaps.begin() && __pos[-1] == __s,
>>> >> > - seconds{__pos - __leaps.begin()}
>>> >> > + __pos != begin(__leaps) && __pos[-1] == __s,
>>> >>
>>> >> The inconsistency between usage of std::begin versus begin here seems
>>> >> odd and I'm wondering why instead of "begin(__leaps)" the above
>>> >> introduced "__first" variable is not used instead.
>>> >
>>> >
>>> > Because this code is going to be changed again soon, this is a partial
>>> > merge from a local branch with the TODO fixed. Yes, it's inconsistent,
>>> > but it works correctly and it's not my priority right now :-)
>>>
>>> What about the suggestion to use the already existing "__first"
>>> variable instead of the begin call?
>>
>>
>> It's an array, the begin call is free.
>
> Do you really want me to stop working on the missing time zone support to
> test and commit that change?
I do not. I was reviewing and hoping to make a useful comment.
Thanks,
- Daniel
Re: [committed] libstdc++: Improve performance of chrono::utc_clock::now()
Am Do., 17. Nov. 2022 um 10:07 Uhr schrieb Jonathan Wakely
:
>
>
>
> On Thu, 17 Nov 2022, 06:30 Daniel Krügler via Libstdc++,
> wrote:
>>
>> Am Mi., 16. Nov. 2022 um 22:00 Uhr schrieb Jonathan Wakely via
>> Libstdc++ :
>> >
>> > Tested x86_64-linux. Pushed to trunk.
>> >
>> > -- >8 --
>> >
>> > We can use an array instead of a std::vector, and we can avoid the
>> > binary search for the common case of a time point after the most recent
>> > leap second. On one system where I tested this, utc_clock::now() now
>> > takes about 16ns instead of 31ns.
>> >
>> > libstdc++-v3/ChangeLog:
>> >
>> > * include/std/chrono (get_leap_second_info): Optimize.
>> > ---
>> > libstdc++-v3/include/std/chrono | 31 ---
>> > 1 file changed, 24 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/libstdc++-v3/include/std/chrono
>> > b/libstdc++-v3/include/std/chrono
>> > index 90b73f8198e..2468023f6c5 100644
>> > --- a/libstdc++-v3/include/std/chrono
>> > +++ b/libstdc++-v3/include/std/chrono
>> > @@ -2747,9 +2747,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> >{
>> > if constexpr (is_same_v<_Duration, seconds>)
>> > {
>> > - // TODO move this function into the library and get leaps from
>> > tzdb.
>> > - vector __leaps
>> > - {
>> > + const seconds::rep __leaps[] {
>> > 78796800, // 1 Jul 1972
>> > 94694400, // 1 Jan 1973
>> >126230400, // 1 Jan 1974
>> > @@ -2778,12 +2776,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> > 1435708800, // 1 Jul 2015
>> > 1483228800, // 1 Jan 2017
>> > };
>> > + // The list above is known to be valid until 2023-06-28
>> > 00:00:00 UTC
>> > + const seconds::rep __expires = 1687910400;
>> > + const seconds::rep __s = __ut.time_since_epoch().count();
>> >
>> > - auto __s = __ut.time_since_epoch().count();
>> > - auto __pos = std::upper_bound(__leaps.begin(), __leaps.end(),
>> > __s);
>> > + const seconds::rep* __first = std::begin(__leaps);
>> > + const seconds::rep* __last = std::end(__leaps);
>> > +
>> > + if (__s > __expires)
>> > + {
>> > + // TODO: use updated leap_seconds from tzdb
>> > +#if 0
>> > + auto __db = get_tzdb_list().begin();
>> > + __first = __db->leap_seconds.data();
>> > + __last = __first + __db->leap_seconds.size();
>> > +#endif
>> > + }
>> > +
>> > + // Don't bother searching the list if we're after the last one.
>> > + if (__s > __last[-1])
>> > + return { false, seconds(__last - __first) };
>> > +
>> > + auto __pos = std::upper_bound(__first, __last, __s);
>> > return {
>> > - __pos != __leaps.begin() && __pos[-1] == __s,
>> > - seconds{__pos - __leaps.begin()}
>> > + __pos != begin(__leaps) && __pos[-1] == __s,
>>
>> The inconsistency between usage of std::begin versus begin here seems
>> odd and I'm wondering why instead of "begin(__leaps)" the above
>> introduced "__first" variable is not used instead.
>
>
> Because this code is going to be changed again soon, this is a partial merge
> from a local branch with the TODO fixed. Yes, it's inconsistent, but it works
> correctly and it's not my priority right now :-)
What about the suggestion to use the already existing "__first"
variable instead of the begin call?
Thanks,
- Daniel
Re: [committed] libstdc++: Improve performance of chrono::utc_clock::now()
Am Mi., 16. Nov. 2022 um 22:00 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> Tested x86_64-linux. Pushed to trunk.
>
> -- >8 --
>
> We can use an array instead of a std::vector, and we can avoid the
> binary search for the common case of a time point after the most recent
> leap second. On one system where I tested this, utc_clock::now() now
> takes about 16ns instead of 31ns.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/chrono (get_leap_second_info): Optimize.
> ---
> libstdc++-v3/include/std/chrono | 31 ---
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
> index 90b73f8198e..2468023f6c5 100644
> --- a/libstdc++-v3/include/std/chrono
> +++ b/libstdc++-v3/include/std/chrono
> @@ -2747,9 +2747,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>{
> if constexpr (is_same_v<_Duration, seconds>)
> {
> - // TODO move this function into the library and get leaps from
> tzdb.
> - vector __leaps
> - {
> + const seconds::rep __leaps[] {
> 78796800, // 1 Jul 1972
> 94694400, // 1 Jan 1973
>126230400, // 1 Jan 1974
> @@ -2778,12 +2776,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> 1435708800, // 1 Jul 2015
> 1483228800, // 1 Jan 2017
> };
> + // The list above is known to be valid until 2023-06-28 00:00:00
> UTC
> + const seconds::rep __expires = 1687910400;
> + const seconds::rep __s = __ut.time_since_epoch().count();
>
> - auto __s = __ut.time_since_epoch().count();
> - auto __pos = std::upper_bound(__leaps.begin(), __leaps.end(),
> __s);
> + const seconds::rep* __first = std::begin(__leaps);
> + const seconds::rep* __last = std::end(__leaps);
> +
> + if (__s > __expires)
> + {
> + // TODO: use updated leap_seconds from tzdb
> +#if 0
> + auto __db = get_tzdb_list().begin();
> + __first = __db->leap_seconds.data();
> + __last = __first + __db->leap_seconds.size();
> +#endif
> + }
> +
> + // Don't bother searching the list if we're after the last one.
> + if (__s > __last[-1])
> + return { false, seconds(__last - __first) };
> +
> + auto __pos = std::upper_bound(__first, __last, __s);
> return {
> - __pos != __leaps.begin() && __pos[-1] == __s,
> - seconds{__pos - __leaps.begin()}
> + __pos != begin(__leaps) && __pos[-1] == __s,
The inconsistency between usage of std::begin versus begin here seems
odd and I'm wondering why instead of "begin(__leaps)" the above
introduced "__first" variable is not used instead.
- Daniel
Re: [PATCH 2/3] libstdc++: Implement ranges::iota from P2440R1
Am Mo., 14. Nov. 2022 um 11:09 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> On Mon, 14 Nov 2022 at 04:52, Patrick Palka via Libstdc++
> wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/ranges_algo.h (out_value_result): Define.
> > (iota_result): Define.
> > (__iota_fn, iota): Define.
> > * testsuite/25_algorithms/iota/1.cc: New test.
> > ---
> > libstdc++-v3/include/bits/ranges_algo.h | 48 +++
> > .../testsuite/25_algorithms/iota/1.cc | 29 +++
> > 2 files changed, 77 insertions(+)
> > create mode 100644 libstdc++-v3/testsuite/25_algorithms/iota/1.cc
> >
> > diff --git a/libstdc++-v3/include/bits/ranges_algo.h
> > b/libstdc++-v3/include/bits/ranges_algo.h
> > index da0ca981dc3..f003117c569 100644
> > --- a/libstdc++-v3/include/bits/ranges_algo.h
> > +++ b/libstdc++-v3/include/bits/ranges_algo.h
> > @@ -3517,6 +3517,54 @@ namespace ranges
> >};
> >
> >inline constexpr __contains_subrange_fn contains_subrange{};
> > +
> > + template
> > +struct out_value_result
> > +{
> > + [[no_unique_address]] _Out out;
> > + [[no_unique_address]] _Tp value;
> > +
> > + template
> > + requires convertible_to
> > + && convertible_to
> > + constexpr
> > + operator out_value_result<_Out2, _Tp2>() const &
> > + { return {out, value}; }
> > +
> > + template
> > + requires convertible_to<_Out, _Out2>
> > + && convertible_to<_Tp, _Tp2>
> > + constexpr
> > + operator out_value_result<_Out2, _Tp2>() &&
> > + { return {std::move(out), std::move(value)}; }
> > +};
> > +
> > + template
> > +using iota_result = out_value_result<_Out, _Tp>;
> > +
> > + struct __iota_fn
> > + {
> > +template _Sent,
> > weakly_incrementable _Tp>
> > + requires indirectly_writable<_Out, const _Tp&>
> > + constexpr iota_result<_Out, _Tp>
> > + operator()(_Out __first, _Sent __last, _Tp __value) const
> > + {
> > + while (__first != __last)
> > + {
> > + *__first = static_cast&>(__value);
>
> Is this any different to const_cast(__value) ?
I think it is. const_cast can potentially mean the removal
of volatile, so I would always look with suspicion on const_cast, while static_cast is clearer. Alternatively, as_const could be
used, which does add_const_t.
- Daniel
Re: [committed] libstdc++: Find make_error_code and make_error_condition via ADL only
Am Do., 8. Sept. 2022 um 20:30 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> Tested powerpc64le-linux, pushed to trunk.
>
> -- >8 --
>
> The new proposed resolution for LWG 3629 says that std::error_code and
> std::error_condition should only use ADL to find their customization
> points. This means we need to use a poison pill to prevent lookup from
> finding overloads in the enclosing namespaces.
>
> We can also remove the forward declarations of std::make_error_code and
> std::make_error_condition, because they aren't needed now. ADL can find
> them anyway (when std is an associated namespace), and unqualified name
> lookup will not (and should not) find them.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/system_error (__adl_only::make_error_code): Add
> deleted function.
> (__adl_only::make_error_condition): Likewise.
> (error_code::error_code(ErrorCodeEnum)): Add using-declaration
> for deleted function.
> (error_condition::error_condition(ErrorConditionEnum)):
> Likewise.
> * testsuite/19_diagnostics/error_code/cons/lwg3629.cc: New test.
> * testsuite/19_diagnostics/error_condition/cons/lwg3629.cc: New test.
> ---
[..]
> +// { dg-do compile { target c++11 } }
> +
> +// 3629. make_error_code and make_error_condition are customization points
> +// Verify that make_error_code is looked up using ADL only.
> +
> +namespace user
> +{
> + struct E1;
> +}
> +
> +// N.B. not in associated namespace of E1, and declared before
> .
> +user::E1 make_error_code(user::E1);
> +
> +#include // declares std::make_error_code(future_errc)
> +#include
> +
> +namespace user
> +{
> + struct E1
> + {
> +operator std::error_code() const;
> + };
> +
> + struct E2
> + {
> +operator std::future_errc() const;
> + };
> +
> + struct E3
> + {
> +operator std::errc() const;
> + };
> +}
> +
> +template<> struct std::is_error_code_enum : std::true_type { };
> +template<> struct std::is_error_code_enum : std::true_type { };
> +template<> struct std::is_error_code_enum : std::true_type { };
> +
> +// ::make_error_code(E1) should not be found by name lookup.
> +std::error_code e1( user::E1{} ); // { dg-error "here" }
> +
> +// std::make_error_code(errc) should not be found by name lookup.
> +std::error_code e2( user::E2{} ); // { dg-error "here" }
(1) Unless I'm misunderstanding something here, the comment above
doesn't match here, it should mention (std::)future_errc instead.
> +// std::make_error_code(future_errc) should not be found by name lookup.
> +std::error_code e3( user::E3{} ); // { dg-error "here" }
(2) Unless I'm misunderstanding something here, the comment above
doesn't match here, it should mention (std::)errc instead.
> +// { dg-error "use of deleted function" "" { target *-*-* } 0 }
> diff --git
> a/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/lwg3629.cc
> b/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/lwg3629.cc
> new file mode 100644
> index 000..e34b53de8a1
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/lwg3629.cc
> @@ -0,0 +1,48 @@
> +// { dg-do compile { target c++11 } }
> +
> +// 3629. make_error_code and make_error_condition are customization points
> +// Verify that make_error_condition is looked up using ADL only.
> +
> +namespace user
> +{
> + struct E1;
> +}
> +
> +// N.B. not in associated namespace of E1, and declared before
> .
> +user::E1 make_error_condition(user::E1);
> +
> +#include // declares std::make_error_condition(future_errc)
> +#include
> +
> +namespace user
> +{
> + struct E1
> + {
> +operator std::error_code() const;
> + };
> +
> + struct E2
> + {
> +operator std::future_errc() const;
> + };
> +
> + struct E3
> + {
> +operator std::errc() const;
> + };
> +}
> +
> +template<> struct std::is_error_condition_enum : std::true_type {
> };
> +template<> struct std::is_error_condition_enum : std::true_type {
> };
> +template<> struct std::is_error_condition_enum : std::true_type {
> };
> +
> +// ::make_error_condition(E1) should not be found by name lookup.
> +std::error_condition e1( user::E1{} ); // { dg-error "here" }
> +
> +// std::make_error_condition(errc) should not be found by name lookup.
> +std::error_condition e2( user::E2{} ); // { dg-error "here" }
Ditto here (1)
> +// std::make_error_condition(future_errc) should not be found by name lookup.
> +std::error_condition e3( user::E3{} ); // { dg-error "here" }
Ditto here (2)
> +// { dg-error "use of deleted function" "" { target *-*-* } 0 }
> --
> 2.37.3
- Daniel
Re: [PATCH][Hashtable 6/6] PR 68303 small size optimization
Am Di., 21. Dez. 2021 um 07:08 Uhr schrieb François Dumont via Libstdc++ : > > Hi > > Is there a chance for this patch to be integrated for next gcc > release ? > > François > No counterargument for the acceptance, but: Shouldn't __small_size_threshold() be a noexcept function? - Daniel
Re: [PATCH 1/5] libstdc++: Import the fast_float library
Am Di., 16. Nov. 2021 um 16:31 Uhr schrieb Patrick Palka via Libstdc++ : > [..] > -- >8 -- > > Subject: [PATCH 1/5] libstdc++: Import the fast_float library > [..] > +## Reference > + > +- Daniel Lemire, [Number Parsing at a Gigabyte per > Second](https://arxiv.org/abs/2101.11408), Software: Pratice and Experience > 51 (8), 2021. There is a typo in the title at the very end: s/Pratice/Practice (See https://arxiv.org/abs/2101.11408) - Daniel
Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange
Am Di., 2. Nov. 2021 um 02:26 Uhr schrieb Thomas Rodgers via Libstdc++ : > > This should address Jonathan's feedback and adds support for atomic_ref > I'm wondering why __clear_padding doesn't refer to the computed __ptr value in the case where __builtin_clear_padding is used? Thanks, - Daniel
Re: [committed] libstdc++: Support printing volatile pointers (P1147R1)
Am Di., 5. Okt. 2021 um 10:55 Uhr schrieb Jonathan Wakely via Libstdc++ : > > To avoid needing to export a new symbol from the library (for now) the > new member function uses __attribute__((always_inline)). > > libstdc++-v3/ChangeLog: > > * include/std/ostream (operator<<(const volatile void*)): > Add new overload, as per P1147R1. > * testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc: > New test. > > Tested powerpc64le-linux. Committed to trunk. I think the test is insufficient, because it will succeed on every library implementation regardless of the new feature. Without the new feature it will select the unexpected operator<<(bool) overload and just print "1". - Daniel
Re: [committed] libstdc++: Allow visiting inherited variants [PR 90943]
Am Fr., 1. Okt. 2021 um 21:57 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> Implement the changes from P2162R2 (as a DR for C++17).
>
> Signed-off-by: Jonathan Wakely
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/90943
> * include/std/variant (__cpp_lib_variant): Update value.
> (__detail::__variant::__as): New helpers implementing the
> as-variant exposition-only function templates.
> (visit, visit): Use __as to upcast the variant parameters.
> * include/std/version (__cpp_lib_variant): Update value.
> * testsuite/20_util/variant/visit_inherited.cc: New test.
>
> Tested powerpc64le-linux. Committed to trunk.
>
I'm wondering why the first __as overload is not noexcept as well (or
asking it the other way around: Why different exception-specifications
are used for the different overloads):
+ // The __as function templates implement the exposition-only "as-variant"
+
+ template
+constexpr std::variant<_Types...>&
+__as(std::variant<_Types...>& __v)
+{ return __v; }
- Daniel
Re: [PATCH 4/4] libstdc++: Add fallback 128-bit integer class type and use it
Am Do., 11. März 2021 um 18:17 Uhr schrieb Patrick Palka via Libstdc++
:
>
> This implements a minimal integer class type that emulates 128-bit
> unsigned arithmetic using a pair of 64-bit integers, which the
> floating-point std::to_chars implementation then uses as a drop-in
> replacement for unsigned __int128 on targets that lack the latter.
> This allows us to fully support formatting of large long double types
> on targets that lack __int128.
>
> Since Ryu performs 128-bit division/modulus only by 2, 5 and 10, the
> integer class type supports only these divisors rather than supporting
> general division/modulus.
>
> Tested on x86, x86_64, ppc64le, ppc64be and aarch64, with and without
> performing the equivalent of -U__SIZEOF_INT128__ in floating_to_chars.cc
> (so that we also test using the class type on targets when __int128 is
> available).
>
> libstdc++-v3/ChangeLog:
>
> * src/c++17/floating_to_chars.cc: Simplify the file as if
> __SIZEOF_INT128__ is always defined.
> [!defined __SIZEOF_INT128__]: Include "uint128_t.h". Define
> a to_chars overload for the uint128_t class type.
> * src/c++17/uint128_t.h: New file.
> * testsuite/20_util/to_chars/long_double.cc: No longer expect an
> execution FAIL on targets that have a large long double type
> but lack __int128.
> ---
> libstdc++-v3/src/c++17/floating_to_chars.cc | 58 ++--
> libstdc++-v3/src/c++17/uint128_t.h| 297 ++
> .../testsuite/20_util/to_chars/long_double.cc | 1 -
> 3 files changed, 332 insertions(+), 24 deletions(-)
> create mode 100644 libstdc++-v3/src/c++17/uint128_t.h
>
> diff --git a/libstdc++-v3/src/c++17/floating_to_chars.cc
> b/libstdc++-v3/src/c++17/floating_to_chars.cc
> index da3fbaa1ed1..86f4401e134 100644
> --- a/libstdc++-v3/src/c++17/floating_to_chars.cc
> +++ b/libstdc++-v3/src/c++17/floating_to_chars.cc
> @@ -64,25 +64,19 @@ extern "C" int __sprintfieee128(char*, const char*, ...);
>
> #if __LDBL_MANT_DIG__ == __DBL_MANT_DIG__
> # define LONG_DOUBLE_KIND LDK_BINARY64
> -#elif defined(__SIZEOF_INT128__)
> -// The Ryu routines need a 128-bit integer type in order to do shortest
> -// formatting of types larger than 64-bit double, so without __int128 we
> can't
> -// support any large long double format. This is the case for e.g. i386.
> -# if __LDBL_MANT_DIG__ == 64
> +#elif __LDBL_MANT_DIG__ == 64
> # define LONG_DOUBLE_KIND LDK_FLOAT80
> -# elif __LDBL_MANT_DIG__ == 113
> -# define LONG_DOUBLE_KIND LDK_BINARY128
> -# elif __LDBL_MANT_DIG__ == 106
> -# define LONG_DOUBLE_KIND LDK_IBM128
> -# endif
> -# if defined _GLIBCXX_USE_FLOAT128 && __FLT128_MANT_DIG__ == 113
> -// Define overloads of std::to_chars for __float128.
> -# define FLOAT128_TO_CHARS 1
> -# endif
> +#elif __LDBL_MANT_DIG__ == 113
> +# define LONG_DOUBLE_KIND LDK_BINARY128
> +#elif __LDBL_MANT_DIG__ == 106
> +# define LONG_DOUBLE_KIND LDK_IBM128
> +#else
> +# define LONG_DOUBLE_KIND LDK_UNSUPPORTED
> #endif
>
> -#if !defined(LONG_DOUBLE_KIND)
> -# define LONG_DOUBLE_KIND LDK_UNSUPPORTED
> +#if defined _GLIBCXX_USE_FLOAT128 && __FLT128_MANT_DIG__ == 113
> +// Define overloads of std::to_chars for __float128.
> +# define FLOAT128_TO_CHARS 1
> #endif
>
> // For now we only support __float128 when it's the powerpc64 __ieee128 type.
> @@ -100,6 +94,8 @@ namespace
> {
> #if defined __SIZEOF_INT128__
>using uint128_t = unsigned __int128;
> +#else
> +# include "uint128_t.h"
> #endif
>
>namespace ryu
> @@ -114,7 +110,6 @@ namespace
> #include "ryu/d2fixed.c"
> #include "ryu/f2s.c"
>
> -#ifdef __SIZEOF_INT128__
> namespace generic128
> {
>// Put the generic Ryu bits in their own namespace to avoid name
> conflicts.
> @@ -129,7 +124,6 @@ namespace
> int
> to_chars(const floating_decimal_128 v, char* const result)
> { return generic128::generic_to_chars(v, result); }
> -#endif
>} // namespace ryu
>
>// A traits class that contains pertinent information about the binary
> @@ -407,10 +401,8 @@ namespace
> return uint32_t{};
> else if constexpr (total_bits <= 64)
> return uint64_t{};
> -#ifdef __SIZEOF_INT128__
> else if constexpr (total_bits <= 128)
> return uint128_t{};
> -#endif
>};
>using uint_t = decltype(get_uint_t());
>uint_t value_bits = 0;
> @@ -503,7 +495,6 @@ namespace
> return ryu::floating_to_fd32(value);
>else if constexpr (std::is_same_v)
> return ryu::floating_to_fd64(value);
> -#ifdef __SIZEOF_INT128__
>else if constexpr (std::is_same_v
> || std::is_same_v)
> {
> @@ -519,7 +510,6 @@ namespace
> mantissa_bits, exponent_bits,
> !has_implicit_leading_bit);
> }
> -#endif
> }
>
>// This subroutine returns true if the shortest scientific form fd is a
>
Re: [PATCH] 2/2 Remove debug/array
Am Do., 3. Dez. 2020 um 18:10 Uhr schrieb Jonathan Wakely via Libstdc++ : > [..] > >>Ok to commit ? > > > >Yes, this is a nice simplification, thanks. > > This broke the C++11 constexpr support in std::array. Fixed with this > patch. Tested x86_64-linux, committed to trunk. Wouldn't a transformation into a comma expression, such as return __glibcxx_requires_subscript(__n), _AT_Type::_S_ref(_M_elems, __n); realize the same thing but would still keep the assertion-like thing? (Untested, just out of my head) - Daniel
Re: [committed] libstdc++: Fix std::gcd and std::lcm for unsigned integers [PR 92978]
Am Sa., 29. Aug. 2020 um 00:12 Uhr schrieb Jonathan Wakely via Libstdc++ : > > This fixes a bug with mixed signed and unsigned types, where converting > a negative value to the unsigned result type alters the value. The > solution is to obtain the absolute values of the arguments immediately > and to perform the actual GCD or LCM algorithm on two arguments of the > same type. > > In order to operate on the most negative number without overflow when > taking its absolute, use an unsigned type for the result of the abs > operation. For example, -INT_MIN will overflow, but -(unsigned)INT_MIN > is (unsigned)INT_MAX+1U which is the correct value. > > libstdc++-v3/ChangeLog: > > PR libstdc++/92978 > * include/std/numeric (__abs_integral): Replace with ... > (__detail::__absu): New function template that returns an > unsigned type, guaranteeing it can represent the most > negative signed value. > (__detail::__gcd, __detail::__lcm): Require arguments to > be unsigned and therefore already non-negative. > (gcd, lcm): Convert arguments to absolute value as unsigned > type before calling __detail::__gcd or __detail::__lcm. > * include/experimental/numeric (gcd, lcm): Likewise. > * testsuite/26_numerics/gcd/gcd_neg.cc: Adjust expected > errors. > * testsuite/26_numerics/lcm/lcm_neg.cc: Likewise. > * testsuite/26_numerics/gcd/92978.cc: New test. > * testsuite/26_numerics/lcm/92978.cc: New test. > * testsuite/experimental/numeric/92978.cc: New test. > > Tested powerpc64le-linux. Committed to trunk. Shouldn't the overload of __absu void __absu(bool) = delete; still also be a template or is just the diff presentation confusing me? Thanks, - Daniel
