Re: [PATCH] libstdc++: Fix std::runtime_format deviations from the spec [PR113320]

[Daniel Krügler]

Am Do., 11. Jan. 2024 um 21:23 Uhr schrieb Jonathan Wakely :
>
> Tested x86_64-linux. Does this look better now?

Yes, thank you.

- Daniel

Re: [committed 2/2] libstdc++: Implement P2918R0 "Runtime format strings II" for C++26

[Daniel Krügler]

Am Mo., 8. Jan. 2024 um 03:25 Uhr schrieb Jonathan Wakely :
>
> Tested x86_64-linux and aarch64-linux. Pushed to trunk.
>
> -- >8 --
>
> This adds std::runtime_format for C++26. These new overloaded functions
> enhance the std::format API so that it isn't necessary to use the less
> ergonomic std::vformat and std::make_format_args (which are meant to be
> implementation details). This was approved in Kona 2023 for C++26.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/format (__format::_Runtime_format_string): Define
> new class template.
> (basic_format_string): Add non-consteval constructor for runtime
> format strings.
> (runtime_format): Define new function for C++26.
> * testsuite/std/format/runtime_format.cc: New test.
> ---
>  libstdc++-v3/include/std/format   | 22 +++
>  .../testsuite/std/format/runtime_format.cc| 37 +++
>  2 files changed, 59 insertions(+)
>  create mode 100644 libstdc++-v3/testsuite/std/format/runtime_format.cc
>
> diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
> index 160efa5155c..b3b5a0bbdbc 100644
> --- a/libstdc++-v3/include/std/format
> +++ b/libstdc++-v3/include/std/format
> @@ -81,6 +81,9 @@ namespace __format
>
>template
>  using __format_context = basic_format_context<_Sink_iter<_CharT>, 
> _CharT>;
> +
> +  template
> +struct _Runtime_format_string { basic_string_view<_CharT> _M_str; };
>  } // namespace __format
>  /// @endcond
>
> @@ -115,6 +118,11 @@ namespace __format
> consteval
> basic_format_string(const _Tp& __s);
>
> +  [[__gnu__::__always_inline__]]
> +  basic_format_string(__format::_Runtime_format_string<_CharT>&& __s)
> +  : _M_str(__s._M_str)
> +  { }
> +

My understanding is that this constructor should be noexcept according to N4971.

>[[__gnu__::__always_inline__]]
>constexpr basic_string_view<_CharT>
>get() const noexcept
> @@ -133,6 +141,20 @@ namespace __format
>= basic_format_string...>;
>  #endif
>
> +#if __cplusplus > 202302L
> +  [[__gnu__::__always_inline__]]
> +  inline __format::_Runtime_format_string
> +  runtime_format(string_view __fmt)
> +  { return {__fmt}; }
> +
> +#ifdef _GLIBCXX_USE_WCHAR_T
> +  [[__gnu__::__always_inline__]]
> +  inline __format::_Runtime_format_string
> +  runtime_format(wstring_view __fmt)
> +  { return {__fmt}; }
> +#endif
> +#endif // C++26
> +

These runtime_format overloads should also be noexcept.

- Daniel

Re: [committed] libstdc++: Define C++26 saturation arithmetic functions (P0543R3)

[Daniel Krügler]

Am Fr., 17. Nov. 2023 um 18:31 Uhr schrieb Jonathan Wakely :
>
> On Fri, 17 Nov 2023 at 17:01, Daniel Krügler  
> wrote:
> >
[..]
> > > +
> > > +namespace std _GLIBCXX_VISIBILITY(default)
> > > +{
> > > +_GLIBCXX_BEGIN_NAMESPACE_VERSION
> > > +
> > > +  /// Add two integers, with saturation in case of overflow.
> > > +  template requires __is_standard_integer<_Tp>::value
> > > +constexpr _Tp
> > > +add_sat(_Tp __x, _Tp __y) noexcept
> > > +{
> > > +  _Tp __z;
> > > +  if (!__builtin_add_overflow(__x, __y, &__z))
> > > +   return __z;
> > > +  if constexpr (is_unsigned_v<_Tp>)
> > > +   return __gnu_cxx::__int_traits<_Tp>::__max;
> > > +  else if (__x < 0)
> > > +   return __gnu_cxx::__int_traits<_Tp>::__min;
> >
> > My apologies, but why does the sign of x decide the direction of the
> > result, shouldn't that be the sign of the returned value of z?
>
> z is incorrect at this point, it only has the correct value if no
> overflow occurred. But we know that an overflow occurred because the
> built-in returned true.
>
> We need to determine whether the overflow was positive, i.e. greater
> than numeric_limits::max(), or negative, i.e. lower than
> numeric_limits::min(). For unsigned types, it must have been a
> positive overflow, because neither value is negative so that's easy.
>
> If x is negative, then there is no possible y that can cause a
> positive overflow. If we consider Tp==int, then the maximum y is
> INT_MAX, so if x is negative, x+INT_MAX < INT_MAX. So if x is
> negative, we must have had a negative overflow, and so the result
> saturates to INT_MIN.
>
> If x is positive, there is no possible y that can cause a negative
> overflow. The minimum y is INT_MIN, and so if x is positive, x +
> INT_MIN > INT_MIN. So if x is positive, we must have had a positive
> overflow.
>
> (And x can't be zero, because 0+y would not overflow).

Ah right, thanks.

- Daniel

Re: [committed] libstdc++: Define C++26 saturation arithmetic functions (P0543R3)

[Daniel Krügler]

Am Fr., 17. Nov. 2023 um 16:32 Uhr schrieb Jonathan Wakely :
>
> Tested x86_64-linux. Pushed to trunk.
>
> GCC generates better code for add_sat if we use:
>
> unsigned z = x + y;
> z |= -(z < x);
> return z;
>
> If the compiler can't be improved we should consider using that instead
> of __builtin_add_overflow.
>
>
> -- >8 --
>
>
> This was approved for C++26 last week at the WG21 meeting in Kona.
>
> libstdc++-v3/ChangeLog:
>
> * include/Makefile.am: Add new header.
> * include/Makefile.in: Regenerate.
> * include/bits/version.def (saturation_arithmetic): Define.
> * include/bits/version.h: Regenerate.
> * include/std/numeric: Include new header.
> * include/bits/sat_arith.h: New file.
> * testsuite/26_numerics/saturation/add.cc: New test.
> * testsuite/26_numerics/saturation/cast.cc: New test.
> * testsuite/26_numerics/saturation/div.cc: New test.
> * testsuite/26_numerics/saturation/mul.cc: New test.
> * testsuite/26_numerics/saturation/sub.cc: New test.
> * testsuite/26_numerics/saturation/version.cc: New test.
> ---
>  libstdc++-v3/include/Makefile.am  |   1 +
>  libstdc++-v3/include/Makefile.in  |   1 +
>  libstdc++-v3/include/bits/sat_arith.h | 148 ++
>  libstdc++-v3/include/bits/version.def |   8 +
>  libstdc++-v3/include/bits/version.h   |  11 ++
>  libstdc++-v3/include/std/numeric  |   5 +
>  .../testsuite/26_numerics/saturation/add.cc   |  73 +
>  .../testsuite/26_numerics/saturation/cast.cc  |  24 +++
>  .../testsuite/26_numerics/saturation/div.cc   |  45 ++
>  .../testsuite/26_numerics/saturation/mul.cc   |  34 
>  .../testsuite/26_numerics/saturation/sub.cc   |  86 ++
>  .../26_numerics/saturation/version.cc |  19 +++
>  12 files changed, 455 insertions(+)
>  create mode 100644 libstdc++-v3/include/bits/sat_arith.h
>  create mode 100644 libstdc++-v3/testsuite/26_numerics/saturation/add.cc
>  create mode 100644 libstdc++-v3/testsuite/26_numerics/saturation/cast.cc
>  create mode 100644 libstdc++-v3/testsuite/26_numerics/saturation/div.cc
>  create mode 100644 libstdc++-v3/testsuite/26_numerics/saturation/mul.cc
>  create mode 100644 libstdc++-v3/testsuite/26_numerics/saturation/sub.cc
>  create mode 100644 libstdc++-v3/testsuite/26_numerics/saturation/version.cc
>
> diff --git a/libstdc++-v3/include/Makefile.am 
> b/libstdc++-v3/include/Makefile.am
> index dab9f720cbb..17d9d9cec31 100644
> --- a/libstdc++-v3/include/Makefile.am
> +++ b/libstdc++-v3/include/Makefile.am
> @@ -142,6 +142,7 @@ bits_freestanding = \
> ${bits_srcdir}/ranges_uninitialized.h \
> ${bits_srcdir}/ranges_util.h \
> ${bits_srcdir}/refwrap.h \
> +   ${bits_srcdir}/sat_arith.h \
> ${bits_srcdir}/stl_algo.h \
> ${bits_srcdir}/stl_algobase.h \
> ${bits_srcdir}/stl_construct.h \
> diff --git a/libstdc++-v3/include/Makefile.in 
> b/libstdc++-v3/include/Makefile.in
> index 4f7ab2dfbab..f038af709cc 100644
> --- a/libstdc++-v3/include/Makefile.in
> +++ b/libstdc++-v3/include/Makefile.in
> @@ -497,6 +497,7 @@ bits_freestanding = \
> ${bits_srcdir}/ranges_uninitialized.h \
> ${bits_srcdir}/ranges_util.h \
> ${bits_srcdir}/refwrap.h \
> +   ${bits_srcdir}/sat_arith.h \
> ${bits_srcdir}/stl_algo.h \
> ${bits_srcdir}/stl_algobase.h \
> ${bits_srcdir}/stl_construct.h \
> diff --git a/libstdc++-v3/include/bits/sat_arith.h 
> b/libstdc++-v3/include/bits/sat_arith.h
> new file mode 100644
> index 000..71793467984
> --- /dev/null
> +++ b/libstdc++-v3/include/bits/sat_arith.h
> @@ -0,0 +1,148 @@
> +// Saturation arithmetic -*- C++ -*-
> +
> +// Copyright The GNU Toolchain Authors.
> +//
> +// This file is part of the GNU ISO C++ Library.  This library is free
> +// software; you can redistribute it and/or modify it under the
> +// terms of the GNU General Public License as published by the
> +// Free Software Foundation; either version 3, or (at your option)
> +// any later version.
> +
> +// This library is distributed in the hope that it will be useful,
> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +// GNU General Public License for more details.
> +
> +// Under Section 7 of GPL version 3, you are granted additional
> +// permissions described in the GCC Runtime Library Exception, version
> +// 3.1, as published by the Free Software Foundation.
> +
> +// You should have received a copy of the GNU General Public License and
> +// a copy of the GCC Runtime Library Exception along with this program;
> +// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> +// .
> +
> +/** @file include/bits/sat_arith.h
> + *  This is an internal header file, included by other library headers.
> + *  Do not 

Re: [PATCH 2/2] libstdc++: use new built-in trait __is_pointer

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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()

[Daniel Krügler via Gcc-patches]

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()

[Daniel Krügler via Gcc-patches]

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()

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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)

[Daniel Krügler via Gcc-patches]

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]

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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

[Daniel Krügler via Gcc-patches]

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]

[Daniel Krügler via Gcc-patches]

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

Re: [committed] libstdc++: Add __maybe_const_t and __maybe_empty_t aliases

[Daniel Krügler]

Am Mi., 26. Feb. 2020 um 16:20 Uhr schrieb Jonathan Wakely :
>
> This introduces a couple of convenience alias templates to be used for
> some repeated patterns using std::conditional_t.

I find it a bit confusing/inconsistent to define __maybe_const_t such
that the bool argument says "is const", while for __maybe_empty_t the
corresponding bool argument says "is not empty". Suggestion: Implement
__maybe_empty_t such that its bool argument says "is empty" or change
the alias to __maybe_nonempty_t.

Thanks,

- Daniel

Re: [PATCH] libstdc++: P0769R2 Add shift to

[Daniel Krügler]

Am Mo., 24. Feb. 2020 um 15:12 Uhr schrieb Patrick Palka :
>
> On Mon, 24 Feb 2020, Jonathan Wakely wrote:
>
[...]
> > > @@ -3683,6 +3683,98 @@ namespace ranges
> > >   inline constexpr __prev_permutation_fn prev_permutation{};
> > >
> > > } // namespace ranges
> > > +
> > > +  template
> > > +constexpr ForwardIterator
> > > +shift_left(ForwardIterator __first, ForwardIterator __last,
> > > +  typename iterator_traits::difference_type __n)
> > > +{
> > > +  __glibcxx_assert(__n >= 0);
> >
> > If I'm reading the current draft correctly, n < 0 is allowed (and does
> > nothing) so we shouldn't assert here.
>
> From what I can tell, this is changed by P1243R4 (Rangify new
> algorithms) which adds the precondition n >= 0 to these routines.

Yes, that's correct. This part of the wording applied the accepted
changes of p1233r1.

- Daniel

Re: [committed] libstdc++: Add lightweight replacement for std::numeric_limits (PR 92546)

[Daniel Krügler]

Am Mo., 17. Feb. 2020 um 16:33 Uhr schrieb Jonathan Wakely :
>
> Many uses of std::numeric_limits in C++17 and C++20 features only really
> need the min(), max() and digits constants for integral types. By adding
> __detail::__int_limits we can avoid including the whole  header.

numeric_limits has specializations for cv-qualified types, but for
__ini_limits there is only an undefined specialization for bool.
Shouldn't the same undefined specialization be provided for cv bool?
It may be that currently all usages of that trait apply on already
unqualified types, but this might be a fragile assumption.

- Daniel

Re: [PATCH] libstdc++: Optimize C++20 comparison category types

[Daniel Krügler]

Am Fr., 7. Feb. 2020 um 15:23 Uhr schrieb Jonathan Wakely :
>
> On 07/02/20 10:04 +0100, Daniel Krügler wrote:
> >Am Do., 6. Feb. 2020 um 15:28 Uhr schrieb Jonathan Wakely 
> >:
> >>
> >> On 06/02/20 13:53 +, Jonathan Wakely wrote:
> >> >On 06/02/20 13:40 +, Jonathan Wakely wrote:
> >> >>This reduces sizeof(std::partial_ordering) and optimizes conversion and
> >> >>comparison operators to avoid conditional branches where possible.
> >> >>
> >> >>  * libsupc++/compare (__cmp_cat::_Ncmp::unordered): Change value to 
> >> >> 2.
> >> >>  (partial_ordering::_M_is_ordered): Remove data member.
> >> >>  (partial_ordering): Use second bit of _M_value for unordered. 
> >> >> Adjust
> >> >>  comparison operators.
> >> >>  (weak_ordering::operator partial_ordering): Simplify to remove
> >> >>  branches.
> >> >>  (operator<=>(unspecified, weak_ordering)): Likewise.
> >> >>  (strong_ordering::operator partial_ordering): Likewise.
> >> >>  (strong_ordering::operator weak_ordering): Likewise.
> >> >>  (operator<=>(unspecified, strong_ordering)): Likewise.
> >> >>  * testsuite/18_support/comparisons/categories/partialord.cc: New 
> >> >> test.
> >> >>  * testsuite/18_support/comparisons/categories/strongord.cc: New 
> >> >> test.
> >> >>  * testsuite/18_support/comparisons/categories/weakord.cc: New test.
> >> >>
> >> >>Tested powerpc64le-linux and x86_64-linux.
> >> >>
> >> >>This is an ABI change for the partial_ordering type, but that is why I
> >> >>think we should do it now, not after GCC 10 is released. The sooner
> >> >>the better, before these types are being widely used.
> >> >>
> >> >>I plan to commit this in the next 12 hours or so, unless there are
> >> >>(valid :-) objections.
> >> >>
> >> >>Thanks to Barry Revzin for pointing out there was room for these
> >> >>operators to be improved.
> >> >
> >> >We could also change the int _M_value data member of all three
> >> >comparison category types to be a signed char instead of int. That
> >> >would reduce the size further.
> >>
> >> Or maybe std::int_fast8_t is the right type here.
> >
> >I like this suggestion.
>
> After discussing it with Jakub, I've decided to just use signed char.
>
> In theory int_fast8_t seems like the right choice, but it depends on
> how "fast" is interpreted. Fast for which operations? Is it actually
> going to be faster for the simple comparisons to constants and the
> bit masks that I use in ?
>
> On a number of operating systems int_fast8_t is always int, even
> though byte accesses are no slower on many of the processors whre that
> OS runs.
>
> So we decided that unconditionally using a single byte will give us a
> small size and alignment, without sacrificing any performance.

Yes, I agree with your decision.

- Daniel

Re: [PATCH] libstdc++: Optimize C++20 comparison category types

[Daniel Krügler]

Am Do., 6. Feb. 2020 um 15:28 Uhr schrieb Jonathan Wakely :
>
> On 06/02/20 13:53 +, Jonathan Wakely wrote:
> >On 06/02/20 13:40 +, Jonathan Wakely wrote:
> >>This reduces sizeof(std::partial_ordering) and optimizes conversion and
> >>comparison operators to avoid conditional branches where possible.
> >>
> >>  * libsupc++/compare (__cmp_cat::_Ncmp::unordered): Change value to 2.
> >>  (partial_ordering::_M_is_ordered): Remove data member.
> >>  (partial_ordering): Use second bit of _M_value for unordered. Adjust
> >>  comparison operators.
> >>  (weak_ordering::operator partial_ordering): Simplify to remove
> >>  branches.
> >>  (operator<=>(unspecified, weak_ordering)): Likewise.
> >>  (strong_ordering::operator partial_ordering): Likewise.
> >>  (strong_ordering::operator weak_ordering): Likewise.
> >>  (operator<=>(unspecified, strong_ordering)): Likewise.
> >>  * testsuite/18_support/comparisons/categories/partialord.cc: New test.
> >>  * testsuite/18_support/comparisons/categories/strongord.cc: New test.
> >>  * testsuite/18_support/comparisons/categories/weakord.cc: New test.
> >>
> >>Tested powerpc64le-linux and x86_64-linux.
> >>
> >>This is an ABI change for the partial_ordering type, but that is why I
> >>think we should do it now, not after GCC 10 is released. The sooner
> >>the better, before these types are being widely used.
> >>
> >>I plan to commit this in the next 12 hours or so, unless there are
> >>(valid :-) objections.
> >>
> >>Thanks to Barry Revzin for pointing out there was room for these
> >>operators to be improved.
> >
> >We could also change the int _M_value data member of all three
> >comparison category types to be a signed char instead of int. That
> >would reduce the size further.
>
> Or maybe std::int_fast8_t is the right type here.

I like this suggestion.

- Daniel

Re: [PATCH] libsupc++: Implement comparison algorithms for C++20

[Daniel Krügler]

Am Mi., 13. Nov. 2019 um 17:26 Uhr schrieb Jonathan Wakely :
>
> This is incomplete because std::strong_order doesn't support
> floating-point types.

I'm wondering whether the local __cat lambda expression at the
beginning of __fp_weak_ordering is part of the incomplete code or just
spurious?

- Daniel

Re: PR 90409 Deque fiil/copy/move/copy_backward/move_backward/equal overloads

[Daniel Krügler]

Am Do., 1. Aug. 2019 um 13:01 Uhr schrieb Jonathan Wakely :
>
> On 01/08/19 12:36 +0200, Daniel Krügler wrote:
> >Am Do., 1. Aug. 2019 um 11:57 Uhr schrieb Jonathan Wakely 
> >:
> >>
> >> More comments inline below ...
> >[..]
> >>
> >> >François
> >> >
> >> >On 6/19/19 7:32 PM, François Dumont wrote:
> >> >>I wanted to implement Debug overloads for those already existing
> >> >>overloads but then realized that those algos could be generalized.
> >> >>This way we will benefit from the memmove replacement when operating
> >> >>with C array or std::array or std::vector iterators.
> >> >>
> >> >>I might do the same for lexicographical_compare one day.
> >> >>
> >> >>The ChangeLog below is quite huge so I attached it. I wonder if I
> >> >>could use deque::iterator and deque::const_iterator in place of the
> >> >>_Deque_iterator<> to reduce it ?
> >> >>
> >> >>Tested under Linux x86_64 normal and debug modes, ok to commit ?
> >> >>
> >> >>François
> >> >>
> >> >
> >>
> >> >diff --git a/libstdc++-v3/include/bits/deque.tcc 
> >> >b/libstdc++-v3/include/bits/deque.tcc
> >> >index 3f77b4f079c..9db869fb666 100644
> >> >--- a/libstdc++-v3/include/bits/deque.tcc
> >> >+++ b/libstdc++-v3/include/bits/deque.tcc
> >> >@@ -967,155 +967,507 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> >> >   this->_M_impl._M_finish._M_set_node(__new_nstart + __old_num_nodes 
> >> > - 1);
> >> > }
> >> >
> >[..]
> >>
> >> And anyway, isn't _Deque_iterator::_Self just the same type as
> >> _Deque_iterator ? It should be something like:
> >>
> >>   typedef typename _GLIBCXX_STD_C::_Deque_iterator<_Tp, _Tp&, _Tp*> 
> >> _Iter;
> >>
> >> >+  template
> >> >+typename enable_if<
> >> >+  is_same::iterator_category,
> >> >+std::random_access_iterator_tag>::value,
> >>
> >> Use is_base_of so
> >> it works for types derived from random_access_iterator_tag too.
> >
> >Interesting. Traditional type tag dispatching approaches (as function
> >parameters) do have more in a manner that would be equivalent to an
> >implicit conversion (Being used as "by-value-parameters"), so I'm
> >wondering whether this should not instead refer to is_convertible? I
> >also found examples where this trait is currently used in 
> >such as
> >
> >  static_assert(
> >  __or_,
> >is_convertible<__samp_cat, random_access_iterator_tag>>::value,
> >  "output range must use a RandomAccessIterator when input range"
> >  " does not meet the ForwardIterator requirements");
> >
> >Should possibly this trait be preferred?
>
> Hmm, I don't know why I did it that way in sample.
>
> The standard requires derivation in a couple of places today, see
> [reverse.iterator] bullet 2.1 and [move.iterator] bullet 1.1 which use
> DerivedFrom to check whether the base
> iterator is random access or not.

If you want to mimic DerivedFrom you also need to include
is_convertible in some way, because is_base_of does not care about
access. Maybe introduce __is_derived_from?

- Daniel

Re: PR 90409 Deque fiil/copy/move/copy_backward/move_backward/equal overloads

[Daniel Krügler]

Am Do., 1. Aug. 2019 um 11:57 Uhr schrieb Jonathan Wakely :
>
> More comments inline below ...
[..]
>
> >François
> >
> >On 6/19/19 7:32 PM, François Dumont wrote:
> >>I wanted to implement Debug overloads for those already existing
> >>overloads but then realized that those algos could be generalized.
> >>This way we will benefit from the memmove replacement when operating
> >>with C array or std::array or std::vector iterators.
> >>
> >>I might do the same for lexicographical_compare one day.
> >>
> >>The ChangeLog below is quite huge so I attached it. I wonder if I
> >>could use deque::iterator and deque::const_iterator in place of the
> >>_Deque_iterator<> to reduce it ?
> >>
> >>Tested under Linux x86_64 normal and debug modes, ok to commit ?
> >>
> >>François
> >>
> >
>
> >diff --git a/libstdc++-v3/include/bits/deque.tcc 
> >b/libstdc++-v3/include/bits/deque.tcc
> >index 3f77b4f079c..9db869fb666 100644
> >--- a/libstdc++-v3/include/bits/deque.tcc
> >+++ b/libstdc++-v3/include/bits/deque.tcc
> >@@ -967,155 +967,507 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> >   this->_M_impl._M_finish._M_set_node(__new_nstart + __old_num_nodes - 
> > 1);
> > }
> >
[..]
>
> And anyway, isn't _Deque_iterator::_Self just the same type as
> _Deque_iterator ? It should be something like:
>
>   typedef typename _GLIBCXX_STD_C::_Deque_iterator<_Tp, _Tp&, _Tp*> _Iter;
>
> >+  template
> >+typename enable_if<
> >+  is_same::iterator_category,
> >+std::random_access_iterator_tag>::value,
>
> Use is_base_of so
> it works for types derived from random_access_iterator_tag too.

Interesting. Traditional type tag dispatching approaches (as function
parameters) do have more in a manner that would be equivalent to an
implicit conversion (Being used as "by-value-parameters"), so I'm
wondering whether this should not instead refer to is_convertible? I
also found examples where this trait is currently used in 
such as

  static_assert(
  __or_,
is_convertible<__samp_cat, random_access_iterator_tag>>::value,
  "output range must use a RandomAccessIterator when input range"
  " does not meet the ForwardIterator requirements");

Should possibly this trait be preferred?

- Daniel

Re: [PATCH] Fix ODR violations in code using

[Daniel Krügler]

Am Fr., 5. Juli 2019 um 18:13 Uhr schrieb Jonathan Wakely :
>
[..]
> I decided against the simplification in the second patch, and
> committed the attached one which is closer to the first patch I sent
> (preserving the __atomic_add and __exchange_and_add functions even
> when they just call the built-ins).
>
> Tested x86_64-linux, powerpc64-linux, powerpc-aix. Committed to trunk.

Unrelated to the actual patch, I noticed some explicit "throw()" forms
used as exception specifications - shouldn't these be replaced by
either explicit "noexcept" or at least by a library macro that expands
to one or the other? (I'm sorry, if such unrelated questions are
considered as inappropriate for this list).

- Daniel

Re: [PATCH] Disable -Wctor-dtor-privacy warnings for some standard types

[Daniel Krügler]

Am Sa., 15. Juni 2019 um 12:52 Uhr schrieb Daniel Krügler
:
>
> Am Fr., 14. Juni 2019 um 16:05 Uhr schrieb Jonathan Wakely 
> :
> >
> > These types are not constructible by design, so we never want warnings
> > for them, even with -Wsystem-headers.
> >
> > * include/experimental/type_traits (experimental::nonesuch): Use
> > pragma to disable -Wctor-dtor-privacy warnings.
> > * include/std/type_traits (__is_convertible_helper)
> > (__is_nt_convertible_helper, __nonesuch): Likewise.
> >
> > Tested x86_64-linux, committed to trunk.
>
> Unless I'm misunderstanding something, __nonesuchbase (twice) would
> not be affected by that warning, so maybe the start of the
> corresponding warning suppression could be moved after their
> definition? Or did you do it that way to keep __nonesuchbase and
> nonesuch close together?

Jonathan is momentarily not able to respond to this list using proper
email format, but he responded to me in private as follows:

"I did do that to keep them together, rather than introducing white
space between the base and the class using it. I even considered
putting the pragmas around the whole file, but decided to add them
just locally where needed.

I don't mind moving the base struct out of the pragma if you or
anybody else feels strongly, but thought it didn't do any harm this
way."

Personally I don't feel strongly about it - Thanks for the explanation!

- Daniel

Re: [PATCH] Disable -Wctor-dtor-privacy warnings for some standard types

[Daniel Krügler]

Am Fr., 14. Juni 2019 um 16:05 Uhr schrieb Jonathan Wakely :
>
> These types are not constructible by design, so we never want warnings
> for them, even with -Wsystem-headers.
>
> * include/experimental/type_traits (experimental::nonesuch): Use
> pragma to disable -Wctor-dtor-privacy warnings.
> * include/std/type_traits (__is_convertible_helper)
> (__is_nt_convertible_helper, __nonesuch): Likewise.
>
> Tested x86_64-linux, committed to trunk.

Unless I'm misunderstanding something, __nonesuchbase (twice) would
not be affected by that warning, so maybe the start of the
corresponding warning suppression could be moved after their
definition? Or did you do it that way to keep __nonesuchbase and
nonesuch close together?

- Daniel

Re: [PATCH] Add __gnu_test::NullablePointer utility to testsuite

[Daniel Krügler]

Am Di., 14. Mai 2019 um 13:20 Uhr schrieb Jonathan Wakely :
>
> * testsuite/20_util/allocator_traits/members/allocate_hint_nonpod.cc:
> Use operator-> to access raw pointer member.
> * testsuite/23_containers/vector/59829.cc: Likewise.
> * testsuite/23_containers/vector/bool/80893.cc: Likewise.
> * testsuite/libstdc++-prettyprinters/cxx11.cc: Use NullablePointer.
> * testsuite/util/testsuite_allocator.h (NullablePointer): New utility
> for tests.
> (PointerBase, PointerBase_void): Derive from NullablePointer and use
> its constructors and equality operators. Change converting
> constructors to use operator-> to access private member of the other
> pointer type.
> (PointerBase_void::operator->()): Add, for access to private member.
> (operator-(PointerBase, PointerBase)): Change to hidden friend.
> (operator==(PointerBase, PointerBase)): Remove.
> (operator!=(PointerBase, PointerBase)): Remove.
>
> There are probably more places in the testsuite that could use
> NullablePointer as a minimally-conforming type that meets the
> Cpp17NullablePointer requirements, instead of defining a new type each
> time one is needed.
>
> Tested powerpc64le-linux, committed to trunk.
>

In the primary template of NullablePointer we have:

explicit operator bool() const noexcept { return value == nullptr; }

This is incorrect according to the NullablePointer requirements, it needs to be:

explicit operator bool() const noexcept { return value != nullptr; }

- Daniel

Re: [PATCH] Improve API docs for header

[Daniel Krügler]

Am Sa., 4. Mai 2019 um 16:37 Uhr schrieb Jonathan Wakely :
>
> * include/std/system_error (error_category, error_code)
> (error_condition): Improve docs.
> * libsupc++/exception: Add missing @addtogroup Doxygen command.
> * libsupc++/exception_ptr.h (exception_ptr): Link equality operators
> to class documentation. Suppress documentation for implementation
> details.
> * libsupc++/nested_exception.h (throw_with_nested, rethrow_if_nested):
> Suppress documentation for implementation details.
>
> Committed to trunk.

The new docs for error_category say now:

"An error category defines a context that give meaning to the integer
* stored in an `error_code` or `error_category` object."

The last "or `error_category`" looks misleading to me, did you mean
"or `error_condition`" instead?

- Daniel

Re: Implement C++20 constexpr , , and

[Daniel Krügler]

Am Fr., 29. März 2019 um 19:08 Uhr schrieb Ed Smith-Rowland via
libstdc++ :
>
> I made __memmove and __memcmp inline so that, certainly for C++ < 20
> these don't pessimize.

Hmmh, are you sure? In my (not very up-to-date) code base I find that
c++config.h defines

#ifndef _GLIBCXX20_CONSTEXPR
# if __cplusplus > 201703L
#  define _GLIBCXX20_CONSTEXPR constexpr
# else
#  define _GLIBCXX20_CONSTEXPR
# endif
#endif

So unless __cplusplus > 201703L, there is no inline in sight.

- Daniel

Re: [PATCH, libstdc++] Implement P0415 More constexpr for std::complex.

[Daniel Krügler]

Am Fr., 16. Nov. 2018 um 18:13 Uhr schrieb Ed Smith-Rowland
<3dw...@verizon.net>:
>
> Greetings,
>
> This is late but I wanted to put it out there just to finish a thing.
>
> It's fairly straightforward constexpr of operators and some simple
> functions for std::complex.
>
> The only thing that jumped out was the norm function.  We had this:
>
>  struct _Norm_helper
>  {
>template
>  static inline _Tp _S_do_it(const complex<_Tp>& __z)
>  {
>_Tp __res = std::abs(__z);
>return __res * __res;
>  }
>  };
>
> Since abs can't be made constexpr for complex since it involves sqrt (It
> probably could but that's another story) I had to fall back to the x^2 +
> y^2.  I don't know who that will bother.  This version should be faster
> and I can't think of any useful trustworthy difference numerically
> either in terms of accuracy of stability.
>
> Barring any feedback on that I'll clean it up and maybe rename my tests
> from constexpr_all_the_things.cc to more_constexpr.cc ;-)
>
> It builds and tests cleanly on x86_64-linux.

Hmmh, according to the recent working draft the following complex
functions are *not* constexpr:

arg, proj

So, shouldn't their new C++20-constexpr specifiers be added
conditionally (In the sense of gcc extensions)?

- Daniel

Re: std::advance istreambuf_iterator overload

[Daniel Krügler]

2017-11-13 21:23 GMT+01:00 François Dumont :
> On 10/11/2017 21:57, Jonathan Wakely wrote:
>>> diff --git a/libstdc++-v3/include/bits/streambuf_iterator.h
>>> b/libstdc++-v3/include/bits/streambuf_iterator.h
>>> index 0a6c7f9..b60626a 100644
>>> --- a/libstdc++-v3/include/bits/streambuf_iterator.h
>>> +++ b/libstdc++-v3/include/bits/streambuf_iterator.h
>>> @@ -417,6 +421,55 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>>   return __last;
>>> }
>>>
>>> +  template
>>> +inline _GLIBCXX17_CONSTEXPR void
>>
>>
>> This function can never be constexpr.
>
> I just replicate the _GLIBCXX17_CONSTEXPR qualification of the general
> std::advance overload. I am not clear about those different constexpr
> concepts but I also found strange that it could be consider as such.

The general std::advance function can be constexpr, depending on the
actual iterator, e.g.

#include 

template
constexpr T* next(T* p)
{
  std::advance(p, 1);
  return p;
}

int main()
{
  static int arr[2] = {1, 2};
  constexpr int* p = next(arr);
}

but as Jonathan already said, for std::istreambuf_iterator this can
never be true (because of the involved IO operations).

- Daniel

Re: Rename cxx1998 into normal

[Daniel Krügler]

2017-10-26 7:51 GMT+02:00 François Dumont :
> Hi
>
> We once talk about rename the __cxx1998 namespace into something less
> C++98 biased. Here is the patch to do so.
>
> Ok with the new name ?

IMO the name should somehow still contain "cxx" somewhere, otherwise
this could easily cause a semantic ambiguity in situations, where the
term "normal" has a specific meaning.

What about "__cxxdef[ault]" ?

- Daniel

Re: std::forward_list optim for always equal allocator

[Daniel Krügler]

2017-09-11 22:36 GMT+02:00 François Dumont :
[..]
> So my remark was rather for the:
>
>   _Fwd_list_iterator() noexcept
>   : _M_node() { }
>
> that could simply be
>
> _Fwd_list_iterator() = default;
>
> no ?

Yes, that should be fine.

- Daniel

Re: std::forward_list optim for always equal allocator

[Daniel Krügler]

2017-09-11 7:12 GMT+02:00 François Dumont :
> When user declare a container iterator like that:
>
> std::forward_list::iterator it;
>
> There is no reason to initialize it with a null node pointer. It is just an
> uninitialized iterator which is invalid to use except to initialize it.

While that is correct, for every forward iterator (and
std::forward_list::iterator meets these requirements), it is also
required that a value-initialized iterator can be compared against
other initialized iterators, so this reduces the amount of freedom to
define a default constructor for such iterators even when used to
default-initialize. This is not meant as a showstopper argument, since
I have not fully understood of what you are planning, but just a
reminder.

- Daniel

Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

[Daniel Krügler]

Hi,

This is a friendly reminder asking for a review of the suggested patch!

Thanks,

- Daniel

2017-07-30 15:01 GMT+02:00 Daniel Krügler <daniel.krueg...@gmail.com>:
> 2017-07-28 22:40 GMT+02:00 Daniel Krügler <daniel.krueg...@gmail.com>:
>> 2017-07-28 22:29 GMT+02:00 Daniel Krügler <daniel.krueg...@gmail.com>:
>>> 2017-07-28 22:25 GMT+02:00 Tim Song <t.canens@gmail.com>:
>>>> On Fri, Jul 28, 2017 at 4:10 PM, Daniel Krügler
>>>> <daniel.krueg...@gmail.com> wrote:
>>>>> +  // Performs an implicit conversion from _Tp to __sv_type.
>>>>> +  template
>>>>> +static __sv_type _S_to_string_view(const _Tp& __svt)
>>>>> +{
>>>>> +  return __svt;
>>>>> +}
>>>>
>>>> I might have gone for
>>>>
>>>> +static __sv_type _S_to_string_view(__sv_type __svt) noexcept
>>>> +{
>>>> +  return __svt;
>>>> +}
>>>>
>>>> With that, we can also use noexcept(_S_to_string_view(__t)) to make up
>>>> for the absence of is_nothrow_convertible (basically the same thing I
>>>> did in LWG 2993's PR).
>>>
>>> Agreed, that makes very much sense. I will adjust the P/R, but before
>>> I resubmit I would like to get feedback whether the other two compare
>>> functions also should become conditionally noexcept.
>>
>> Locally I have now performed the sole change of the _S_to_string_view
>> declaration getting rid of the template, but would also like to gather
>> feedback from the maintainers whether I should also change the form of
>> the conditional noexcept to use the expression
>>
>> noexcept(_S_to_string_view(__t))
>>
>> instead of the current
>>
>> is_same<_Tp, __sv_type>::value
>>
>> as suggested by Tim Song.
>>
>> I'm asking also, because I have a paper proposing to standardize
>> is_nothrow_convertible submitted for the upcoming C++ mailing - This
>> would be one of the first applications in the library ;-)
>
> A slightly revised patch update: It replaces the _S_to_string_view
> template by a simpler _S_to_string_view function as of Tim Song's
> suggestion, but still uses the simplified noexcept specification
> deferring it to a future application case for is_nothrow_convertible.
> Furthermore now all three compare function templates are now
> (conditionally) noexcept by an (off-list) suggestion from Jonathan
> Wakely.
>
> Thanks,
>
> - Daniel



-- 


SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154

Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

[Daniel Krügler]

2017-07-28 22:40 GMT+02:00 Daniel Krügler <daniel.krueg...@gmail.com>:
> 2017-07-28 22:29 GMT+02:00 Daniel Krügler <daniel.krueg...@gmail.com>:
>> 2017-07-28 22:25 GMT+02:00 Tim Song <t.canens@gmail.com>:
>>> On Fri, Jul 28, 2017 at 4:10 PM, Daniel Krügler
>>> <daniel.krueg...@gmail.com> wrote:
>>>> +  // Performs an implicit conversion from _Tp to __sv_type.
>>>> +  template
>>>> +static __sv_type _S_to_string_view(const _Tp& __svt)
>>>> +{
>>>> +  return __svt;
>>>> +}
>>>
>>> I might have gone for
>>>
>>> +static __sv_type _S_to_string_view(__sv_type __svt) noexcept
>>> +{
>>> +  return __svt;
>>> +}
>>>
>>> With that, we can also use noexcept(_S_to_string_view(__t)) to make up
>>> for the absence of is_nothrow_convertible (basically the same thing I
>>> did in LWG 2993's PR).
>>
>> Agreed, that makes very much sense. I will adjust the P/R, but before
>> I resubmit I would like to get feedback whether the other two compare
>> functions also should become conditionally noexcept.
>
> Locally I have now performed the sole change of the _S_to_string_view
> declaration getting rid of the template, but would also like to gather
> feedback from the maintainers whether I should also change the form of
> the conditional noexcept to use the expression
>
> noexcept(_S_to_string_view(__t))
>
> instead of the current
>
> is_same<_Tp, __sv_type>::value
>
> as suggested by Tim Song.
>
> I'm asking also, because I have a paper proposing to standardize
> is_nothrow_convertible submitted for the upcoming C++ mailing - This
> would be one of the first applications in the library ;-)

A slightly revised patch update: It replaces the _S_to_string_view
template by a simpler _S_to_string_view function as of Tim Song's
suggestion, but still uses the simplified noexcept specification
deferring it to a future application case for is_nothrow_convertible.
Furthermore now all three compare function templates are now
(conditionally) noexcept by an (off-list) suggestion from Jonathan
Wakely.

Thanks,

- Daniel


ChangeLog_79162.patch
Description: Binary data


79162.patch
Description: Binary data

Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

[Daniel Krügler]

2017-07-28 22:29 GMT+02:00 Daniel Krügler <daniel.krueg...@gmail.com>:
> 2017-07-28 22:25 GMT+02:00 Tim Song <t.canens@gmail.com>:
>> On Fri, Jul 28, 2017 at 4:10 PM, Daniel Krügler
>> <daniel.krueg...@gmail.com> wrote:
>>> +  // Performs an implicit conversion from _Tp to __sv_type.
>>> +  template
>>> +static __sv_type _S_to_string_view(const _Tp& __svt)
>>> +{
>>> +  return __svt;
>>> +}
>>
>> I might have gone for
>>
>> +static __sv_type _S_to_string_view(__sv_type __svt) noexcept
>> +{
>> +  return __svt;
>> +}
>>
>> With that, we can also use noexcept(_S_to_string_view(__t)) to make up
>> for the absence of is_nothrow_convertible (basically the same thing I
>> did in LWG 2993's PR).
>
> Agreed, that makes very much sense. I will adjust the P/R, but before
> I resubmit I would like to get feedback whether the other two compare
> functions also should become conditionally noexcept.

Locally I have now performed the sole change of the _S_to_string_view
declaration getting rid of the template, but would also like to gather
feedback from the maintainers whether I should also change the form of
the conditional noexcept to use the expression

noexcept(_S_to_string_view(__t))

instead of the current

is_same<_Tp, __sv_type>::value

as suggested by Tim Song.

I'm asking also, because I have a paper proposing to standardize
is_nothrow_convertible submitted for the upcoming C++ mailing - This
would be one of the first applications in the library ;-)

> Thanks,
>
> - Daniel

Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

[Daniel Krügler]

2017-07-28 22:25 GMT+02:00 Tim Song <t.canens@gmail.com>:
> On Fri, Jul 28, 2017 at 4:10 PM, Daniel Krügler
> <daniel.krueg...@gmail.com> wrote:
>> +  // Performs an implicit conversion from _Tp to __sv_type.
>> +  template
>> +static __sv_type _S_to_string_view(const _Tp& __svt)
>> +{
>> +  return __svt;
>> +}
>
> I might have gone for
>
> +static __sv_type _S_to_string_view(__sv_type __svt) noexcept
> +{
> +  return __svt;
> +}
>
> With that, we can also use noexcept(_S_to_string_view(__t)) to make up
> for the absence of is_nothrow_convertible (basically the same thing I
> did in LWG 2993's PR).

Agreed, that makes very much sense. I will adjust the P/R, but before
I resubmit I would like to get feedback whether the other two compare
functions also should become conditionally noexcept.

Thanks,

- Daniel

[PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

[Daniel Krügler]

This patch attempts to solve an issue in basic_string after adding
string_view to several functions that came in during incomplete patch
of LWG 2758/LWG 2946, in short: Functions that take a string_view
parameter value are now replaced by constrained templates taking const
T& that is convertible to string_view. The patch also attempts to
complete the LWG 2946 P/R. With the absence of the
std::is_nothrow_convertible traits, the P/R also restores some of the
lost noexcept specifications of const functions (find, compare, etc)
by conditional noexcept simply comparing whether T is the same type as
string_view.

During that fix two related, minor problems where found and also fixed:

a) Member

int compare(basic_string_view sv) const;

should be noexcept according the spec, but this function wasn't at
all. Since the changes for LWG 2946 required me to touch the noexcept
specifier anyway I replaced it by the conditional noexcept mentioned
above. I do not know what the general policy for "narrow contract"
functions is in libstdc++ code, I therefore didn't touch the also
missing (but optional) noexcept for

int compare(size_type pos1, size_type n1,basic_string_view sv) const;
template
int compare(size_type pos1, size_type n1, const T& t, size_type pos2,
size_type n2 = npos) const;

If wanted, I can apply the same conditional noexcept here as well.

b) Two constructors using the const T& -> string_view conversion did
this via explicit conversion instead of implicit conversion. This
difference can be observed by user-code and in certain cases either a
well-formed program can become ill-formed or may perform different
runtime behaviour (Overloaded conversion operators, one explicit, the
other implicit).

This patch is *untested*, because I cannot make the tests run on my
Windows system.

Thanks,

- Daniel


ChangeLog_79162.patch
Description: Binary data


79162.patch
Description: Binary data

Re: std::forward_list optim for always equal allocator

[Daniel Krügler]

2017-07-17 22:10 GMT+02:00 François Dumont :
> Hi
>
> Here is the patch to implement the always equal alloc optimization for
> forward_list. With this version there is no abi issue.
>
> I also prefer to implement the _Fwd_list_node_base move operator for
> consistency with the move constructor and used it where applicable.
>
>
> * include/bits/forward_list.h
> (_Fwd_list_node_base& operator=(_Fwd_list_node_base&&)): Implement.
> (_Fwd_list_impl(_Fwd_list_impl&&, _Node_alloc_type&&)): New.
> (_Fwd_list_base(_Fwd_list_base&&, _Node_alloc_type&&, std::true_type)):
> New, use latter.
> (forward_list(forward_list&&, _Node_alloc_type&&, std::false_type)):
> New.
> (forward_list(forward_list&&, _Node_alloc_type&&, std::true_type)):
> New.
> (forward_list(forward_list&&, const _Alloc&)): Adapt to use latters.
> * include/bits/forward_list.tcc
> (_Fwd_list_base(_Fwd_list_base&&, _Node_alloc_type&&)): Adapt to use
> _M_impl._M_head move assignment.
> (forward_list<>::merge(forward_list<>&&, _Comp)): Likewise.
>
> Tested under Linux x86_64, ok to commit ?

Out of curiosity: Shouldn't

_Fwd_list_node_base&
operator=(_Fwd_list_node_base&& __x);

be declared noexcept?

Thanks,

- Daniel

Re: [PATCH] Add header implementation of std::to_string for integers (PR libstdc++/71108)

[Daniel Krügler]

2017-05-28 21:38 GMT+02:00 Adrian Wielgosik :
>> so a conforming program could notice the difference by either calling 
>> std::setlocale.
>
> Unless I missed or misunderstood something about locale (please let me
> know if I did), I don't know of any way for locale to affect %d and
> its integer friends.

Hmmh, rethinking about it, I agree that I also cannot see a possible
effect here for the integer types. Initially I was alarmed by the fact
alone that the current wording is basically local-depending, but now I
agree that in this case I cannot find how a conforming program could
observe the difference. Thanks for remaining stubbornly ;-)

- Daniel

Re: [PATCH] Add header implementation of std::to_string for integers (PR libstdc++/71108)

[Daniel Krügler]

2017-05-27 23:46 GMT+02:00 Adrian Wielgosik :
> Currently std::to_string takes a fairly long trip to vs(n/w)printf. The patch
> implements int-to-string formatting in header, to improve function 
> performance.

The existing specification of std::to_string is specified in a way
that would make this replacement implementation non-conforming, IMO.
Reason for this is, that the C++ specification says:

"Each function returns a string object holding the character
representation of the value of
its argument that would be generated by calling sprintf(buf, fmt, val)
with a format specifier of
"%d", "%u", "%ld", "%lu", "%lld", "%llu", "%f", "%f", or "%Lf",
respectively, where buf designates
an internal character buffer of sufficient size."

The explicit reference to sprintf without specification of any locale
means that the outcome should depend on the currently set locale, so a
conforming program could notice the difference by either calling
std::setlocale.

This is different for the new "primitive numeric output" functions
(std::to_chars, std::from_chars), which explicitly require a
conversion as if the "C" locale would be active.

- Daniel

Re: [C++ PATCH, RFC] Implement new C++ intrinsics __is_assignable and __is_constructible.

[Daniel Krügler]

2017-05-12 12:39 GMT+02:00 Ville Voutilainen :
> I have tested this with the full suite on Linux-PPC64. It works otherwise 
> fine,
> but there's one snag: 20_util/unique_ptr/specialized_algorithms/swap_cxx17.cc
> fails, and it looks like the trait ends up instantiating the definition
> of a destructor, which then ends up being hard-error ill-formed.

I'm pretty sure that the library-based implementation does not
instantiate the destructor definition.

Your description sounds remotely similar to me to the current problem
of __is_trivially_constructible intrinsic, which seems to instantiate
the copy constructor definition albeit it (IMO) shouldn't:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654

Could there be a similar cause?

- Daniel

> That is, we have
>
> struct C { };
> void swap(C&, C&) = delete;
> static_assert( !std::is_swappable_v> );
>
> struct D { D(D&&) = delete; };
> static_assert( !std::is_swappable_v> );
>
> The destructor definitions of unique_ptr and unique_ptr
> are not valid because that destructor will try to call an operator()
> on those deleters, and they don't have that operator.
>
> The existing library implementation of is_constructible doesn't
> instantiate the destructor definitions, or if it does, they don't cause
> a hard error. This intrinsic trait approach behaves differently, and I would
> welcome any help fixing that problem.
>
> 2017-05-12  Ville Voutilainen  
>
> c-family/
>
> Implement new C++ intrinsics __is_assignable and __is_constructible.
> * c-common.c (__is_assignable, __is_constructible): New.
> * c-common.h (RID_IS_ASSIGNABLE, RID_IS_CONSTRUCTIBLE): Likewise.
>
> cp/
>
> Implement new C++ intrinsics __is_assignable and __is_constructible.
> * cp-tree.h (CPTK_IS_ASSIGNABLE, CPTK_IS_CONSTRUCTIBLE): New.
> (is_xible): New.
> * cxx-pretty-print.c (pp_cxx_trait_expression): Handle
> CPTK_IS_ASSIGNABLE and CPTK_IS_CONSTRUCTIBLE.
> * method.c (is_xible_helper): New.
> (is_trivially_xible): Adjust.
> (is_xible): New.
> * parser.c (cp_parser_primary_expression): Handle
> RID_IS_ASSIGNABLE and RID_IS_CONSTRUCTIBLE.
> (cp_parser_trait_expr): Likewise.
> * semantics.c (trait_expr_value): Handle
> CPTK_IS_ASSIGNABLE and CPTK_IS_CONSTRUCTIBLE.
>
> libstdc++-v3/
>
> Implement new C++ intrinsics __is_assignable and __is_constructible.
> * include/std/type_traits (__do_is_static_castable_impl): Remove.
> (__is_static_castable_impl, __is_static_castable_safe): Likewise.
> (__is_static_castable, __do_is_direct_constructible_impl): Likewise.
> (__is_direct_constructible_impl): Likewise.
> (__is_direct_constructible_new_safe): Likewise.
> (__is_base_to_derived_ref, __is_lvalue_to_rvalue_ref): Likewise.
> (__is_direct_constructible_ref_cast): Likewise.
> (__is_direct_constructible_new, __is_direct_constructible): Likewise.
> (__do_is_nary_constructible_impl): Likewise.
> (__is_nary_constructible_impl, __is_nary_constructible): Likewise.
> (__is_constructible_impl): Likewise.
> (is_constructible): Call the intrinsic.
> (__is_assignable_helper): Remove.
> (is_assignable): Call the intrinsic.
> (is_trivially_constructible): Likewise.
> (is_trivially_assignable): Likewise.
> (testsuite/20_util/declval/requirements/1_neg.cc): Adjust.
> (testsuite/20_util/make_signed/requirements/typedefs_neg.cc): Likewise.
> (testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc):
> Likewise.



-- 


SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154

Re: [Patch] Inline Variables for the Standard Library (p0607r0)

[Daniel Krügler]

2017-03-12 1:04 GMT+01:00 Daniel Krügler <daniel.krueg...@gmail.com>:
> 2017-03-11 23:14 GMT+01:00 Daniel Krügler <daniel.krueg...@gmail.com>:
>> 2017-03-11 23:09 GMT+01:00 Tim Song <t.canens@gmail.com>:
>>> On Sat, Mar 11, 2017 at 3:37 PM, Daniel Krügler
>>> <daniel.krueg...@gmail.com> wrote:
>>>> 2017-03-11 21:23 GMT+01:00 Tim Song <t.canens@gmail.com>:
>>>>> On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler
>>>>> <daniel.krueg...@gmail.com> wrote:
>>>>>> This patch applies inline to all namespace scope const variables
>>>>>> according to options A and B2 voted in during the Kona meeting, see:
>>>>>>
>>>>>> http://wiki.edg.com/pub/Wg21kona2017/StrawPolls/p0607r0.html
>>>>>>
>>>>>> During that work it has been found that std::ignore was not declared
>>>>>> constexpr (http://cplusplus.github.io/LWG/lwg-defects.html#2773),
>>>>>> which was fixed as well.
>>>>>
>>>>> Just adding constexpr to std::ignore does ~nothing. The assignment
>>>>> operator needs to be made constexpr too; there is really no other
>>>>> reason to use std::ignore.
>>>>
>>>> There is nothing in the resolution of the issue (Nor in the discussion
>>>> that argues for the change) that says so. Yes, I considered to make
>>>> the assignment function template constexpr, but decided against it,
>>>> because the wording of the issue doesn't have this requirement). I'm
>>>> also aware of a test-case which would show the difference, but again:
>>>> This was not what the issue said. In fact I'm in the process to open a
>>>> new library issue that should impose that additional requirement.
>>>>
>>>> - Daniel
>>>
>>> Well, technically speaking, the issue resolution doesn't even
>>> guarantee that the use case mentioned in the issue would compile since
>>> the standard says nothing about whether the copy constructor of
>>> decltype(std::ignore) is constexpr, or even whether it can be copied
>>> at all. Yes, std::ignore is underspecified, but I'm not sure I see the
>>> point in waiting; it's a completely conforming change and IMHO the
>>> issue's intent is clearly to make std::ignore fully usable in
>>> constexpr functions.
>>>
>>> Also, the only specification we have for std::ignore's semantics is
>>> "when an argument in t is ignore, assigning any value to the
>>> corresponding tuple element has no effect". I think one can argue that
>>> "causes an expression to be non-constant" is an "effect".
>>>
>>> Re "new library issue", we already have issue 2933.
>>
>> Good point, it already exists ;-)
>
> Revised patch attached.

I would just like to point out that I'm on vacation from Friday on for
two weeks, so if any changes to this patch are requested, I will work
on them after my return.

Thanks,

- Daniel

Re: [PATCH] Implement LWG 2686, hash

[Daniel Krügler]

2017-03-12 13:16 GMT+01:00 Daniel Krügler <daniel.krueg...@gmail.com>:
> The following is an *untested* patch suggestion, please verify.
>
> Notes: My interpretation is that hash should be
> defined outside of the _GLIBCXX_COMPATIBILITY_CXX0X block, please
> double-check that course of action.
>
> I noticed that the preexisting hash did directly refer to
> the private members of error_code albeit those have public access
> functions. For consistency I mimicked that existing style when
> implementing hash.
>
> - Daniel

I would just point out that I'm on vacations from Friday on for two
weeks, so if any changes to this patch are requested, I will work on
them after my return.

Thanks,

- Daniel

[PATCH] Implement LWG 2686, hash

[Daniel Krügler]

The following is an *untested* patch suggestion, please verify.

Notes: My interpretation is that hash should be
defined outside of the _GLIBCXX_COMPATIBILITY_CXX0X block, please
double-check that course of action.

I noticed that the preexisting hash did directly refer to
the private members of error_code albeit those have public access
functions. For consistency I mimicked that existing style when
implementing hash.

- Daniel


lwg2686.patch
Description: Binary data


ChangeLog_lwg2686.patch
Description: Binary data

Re: [Patch] Inline Variables for the Standard Library (p0607r0)

[Daniel Krügler]

2017-03-11 23:14 GMT+01:00 Daniel Krügler <daniel.krueg...@gmail.com>:
> 2017-03-11 23:09 GMT+01:00 Tim Song <t.canens@gmail.com>:
>> On Sat, Mar 11, 2017 at 3:37 PM, Daniel Krügler
>> <daniel.krueg...@gmail.com> wrote:
>>> 2017-03-11 21:23 GMT+01:00 Tim Song <t.canens@gmail.com>:
>>>> On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler
>>>> <daniel.krueg...@gmail.com> wrote:
>>>>> This patch applies inline to all namespace scope const variables
>>>>> according to options A and B2 voted in during the Kona meeting, see:
>>>>>
>>>>> http://wiki.edg.com/pub/Wg21kona2017/StrawPolls/p0607r0.html
>>>>>
>>>>> During that work it has been found that std::ignore was not declared
>>>>> constexpr (http://cplusplus.github.io/LWG/lwg-defects.html#2773),
>>>>> which was fixed as well.
>>>>
>>>> Just adding constexpr to std::ignore does ~nothing. The assignment
>>>> operator needs to be made constexpr too; there is really no other
>>>> reason to use std::ignore.
>>>
>>> There is nothing in the resolution of the issue (Nor in the discussion
>>> that argues for the change) that says so. Yes, I considered to make
>>> the assignment function template constexpr, but decided against it,
>>> because the wording of the issue doesn't have this requirement). I'm
>>> also aware of a test-case which would show the difference, but again:
>>> This was not what the issue said. In fact I'm in the process to open a
>>> new library issue that should impose that additional requirement.
>>>
>>> - Daniel
>>
>> Well, technically speaking, the issue resolution doesn't even
>> guarantee that the use case mentioned in the issue would compile since
>> the standard says nothing about whether the copy constructor of
>> decltype(std::ignore) is constexpr, or even whether it can be copied
>> at all. Yes, std::ignore is underspecified, but I'm not sure I see the
>> point in waiting; it's a completely conforming change and IMHO the
>> issue's intent is clearly to make std::ignore fully usable in
>> constexpr functions.
>>
>> Also, the only specification we have for std::ignore's semantics is
>> "when an argument in t is ignore, assigning any value to the
>> corresponding tuple element has no effect". I think one can argue that
>> "causes an expression to be non-constant" is an "effect".
>>
>> Re "new library issue", we already have issue 2933.
>
> Good point, it already exists ;-)

Revised patch attached.

> - Daniel


ChangeLog_p0607r0.patch
Description: Binary data


p0607r0.patch
Description: Binary data

Re: [Patch] Inline Variables for the Standard Library (p0607r0)

[Daniel Krügler]

2017-03-11 23:09 GMT+01:00 Tim Song <t.canens@gmail.com>:
> On Sat, Mar 11, 2017 at 3:37 PM, Daniel Krügler
> <daniel.krueg...@gmail.com> wrote:
>> 2017-03-11 21:23 GMT+01:00 Tim Song <t.canens@gmail.com>:
>>> On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler
>>> <daniel.krueg...@gmail.com> wrote:
>>>> This patch applies inline to all namespace scope const variables
>>>> according to options A and B2 voted in during the Kona meeting, see:
>>>>
>>>> http://wiki.edg.com/pub/Wg21kona2017/StrawPolls/p0607r0.html
>>>>
>>>> During that work it has been found that std::ignore was not declared
>>>> constexpr (http://cplusplus.github.io/LWG/lwg-defects.html#2773),
>>>> which was fixed as well.
>>>
>>> Just adding constexpr to std::ignore does ~nothing. The assignment
>>> operator needs to be made constexpr too; there is really no other
>>> reason to use std::ignore.
>>
>> There is nothing in the resolution of the issue (Nor in the discussion
>> that argues for the change) that says so. Yes, I considered to make
>> the assignment function template constexpr, but decided against it,
>> because the wording of the issue doesn't have this requirement). I'm
>> also aware of a test-case which would show the difference, but again:
>> This was not what the issue said. In fact I'm in the process to open a
>> new library issue that should impose that additional requirement.
>>
>> - Daniel
>
> Well, technically speaking, the issue resolution doesn't even
> guarantee that the use case mentioned in the issue would compile since
> the standard says nothing about whether the copy constructor of
> decltype(std::ignore) is constexpr, or even whether it can be copied
> at all. Yes, std::ignore is underspecified, but I'm not sure I see the
> point in waiting; it's a completely conforming change and IMHO the
> issue's intent is clearly to make std::ignore fully usable in
> constexpr functions.
>
> Also, the only specification we have for std::ignore's semantics is
> "when an argument in t is ignore, assigning any value to the
> corresponding tuple element has no effect". I think one can argue that
> "causes an expression to be non-constant" is an "effect".
>
> Re "new library issue", we already have issue 2933.

Good point, it already exists ;-)

- Daniel

Re: [Patch] Inline Variables for the Standard Library (p0607r0)

[Daniel Krügler]

2017-03-11 21:23 GMT+01:00 Tim Song <t.canens@gmail.com>:
> On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler
> <daniel.krueg...@gmail.com> wrote:
>> This patch applies inline to all namespace scope const variables
>> according to options A and B2 voted in during the Kona meeting, see:
>>
>> http://wiki.edg.com/pub/Wg21kona2017/StrawPolls/p0607r0.html
>>
>> During that work it has been found that std::ignore was not declared
>> constexpr (http://cplusplus.github.io/LWG/lwg-defects.html#2773),
>> which was fixed as well.
>
> Just adding constexpr to std::ignore does ~nothing. The assignment
> operator needs to be made constexpr too; there is really no other
> reason to use std::ignore.

There is nothing in the resolution of the issue (Nor in the discussion
that argues for the change) that says so. Yes, I considered to make
the assignment function template constexpr, but decided against it,
because the wording of the issue doesn't have this requirement). I'm
also aware of a test-case which would show the difference, but again:
This was not what the issue said. In fact I'm in the process to open a
new library issue that should impose that additional requirement.

- Daniel

[Patch] Inline Variables for the Standard Library (p0607r0)

[Daniel Krügler]

This patch applies inline to all namespace scope const variables
according to options A and B2 voted in during the Kona meeting, see:

http://wiki.edg.com/pub/Wg21kona2017/StrawPolls/p0607r0.html

During that work it has been found that std::ignore was not declared
constexpr (http://cplusplus.github.io/LWG/lwg-defects.html#2773),
which was fixed as well.

The patch suggests to apply the same fix to implementation-private
constants such as __index_of_v, for example, as well.

Due to the large number of affected variables in header
include/bits/regex_constants.h and include/type_traits, I used a
shortened description of the changes in the ChangeLog instead of
enumerating each constant individually, I hope that this is ok.

Please note that I added the newly introduced _GLIBCXX17_INLINE also
to the commented references of hardware_destructive_interference_size
and hardware_constructive_interference_size in
testsuite/18_support/headers/new/synopsis.cc as a reminder when these
constants will be introduced in the future.

This patch is *untested*, because I cannot make the tests run on my
Windows system.

- Daniel


ChangeLog_p0607r0.patch
Description: Binary data


p0607r0.patch
Description: Binary data

Re: [PATCHv2] do not throw in std::make_exception_ptr

[Daniel Krügler]

2016-08-05 6:49 GMT+02:00 Gleb Natapov :
> Instead of throwing an exception allocate its memory and initialize it
> explicitly. Makes std::make_exception_ptr more efficient since no stack
> unwinding is needed.

[..]

> +#ifndef _CXXABI_INIT_EXCEPTION_H
> +#define _CXXABI_INIT_EXCEPTION_H 1
> +
> +#pragma GCC system_header
> +
> +#pragma GCC visibility push(default)
> +
> +#include 
> +#include 
> +
> +#ifndef _GLIBCXX_CDTOR_CALLABI
> +#define _GLIBCXX_CDTOR_CALLABI
> +#define _GLIBCXX_HAVE_CDTOR_CALLABI 0
> +#else
> +#define _GLIBCXX_HAVE_CDTOR_CALLABI 1
> +#endif

>/// Obtain an exception_ptr pointing to a copy of the supplied object.
>template
> @@ -173,7 +184,16 @@ namespace std
>  #if __cpp_exceptions
>try
> {
> - throw __ex;
> +#if __cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI
> +  void *__e = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ex));
> +  (void)__cxxabiv1::__cxa_init_primary_exception(__e,
> +   
> const_cast((__ex)),
> +   
> __exception_ptr::__dest_thunk<_Ex>);
> +  new (__e) _Ex(__ex);
> +  return exception_ptr(__e);
> +#else
> +  throw __ex;
> +#endif

Please take this question was a grain of salt: Is it really correct
that the more efficient approach is used, when

!_GLIBCXX_HAVE_CDTOR_CALLABI

instead of

_GLIBCXX_HAVE_CDTOR_CALLABI

?

To me _GLIBCXX_HAVE_CDTOR_CALLABI sounds like a feature but with that
logic it sounds more like it would be constraint, is that correct?

Thanks,

- Daniel

Re: [libstdc++] Add C++17clamp

[Daniel Krügler]

2016-07-22 9:55 GMT+02:00 Jonathan Wakely :
> On 22/07/16 08:51 +0100, Jonathan Wakely wrote:
>>
>> On 21/07/16 19:38 -0400, NightStrike wrote:
>>>
>>> On Thu, Jul 14, 2016 at 7:50 PM, Ed Smith-Rowland <3dw...@verizon.net>
>>> wrote:

 Here is an implementation of P0025
 An algorithm to "clamp" a value between a pair of boundary values.

 Testing is almost finished - looks good so far.

 OK if testing passes?

 I didn't see a feature test in any of the SD-6 papers or P0025.

>>>
>>> This is not an efficient implementation.  See here:
>>>
>>> https://gcc.gnu.org/ml/gcc-help/2014-10/msg00112.html
>>>
>>> Which I derived from this SO answer (which is sadly not the accepted
>>> answer at this time):
>>>
>>> http://stackoverflow.com/a/16659263
>>>
>>> I suggest using the very efficient method that requires a temporary.
>>
>>
>> That isn't a valid implementation of std::clamp, since it performs a
>> copy. The template argument might not even be copyable.
>
> We could possibly dispatch to such an implementation for arithmetic
> types, but we wouldn't want to do it for all copyable types. There's
> no way you can know whether making that local copy is expensive for an
> arbitrary type, and making a copy isn't allowed anyway.

But given that clamp is required not even to *return* copies of any of
it's arguments, it doesn't seem to be possible to do that for
arithmetic types either, unless I'm misunderstanding something very
fundamentally here. Or are you interpolating that the same performance
will result out of (ignoring constexpr) the following transformation

const float& clamp(const float& x, const float& min, const max) {
  const float& t = x < min ? min : x;
  return t > max ? max : t;
}

?

Re: [v3 PATCH] Implement P0307R2, Making Optional Greater Equal Again.

[Daniel Krügler]

2016-07-13 20:32 GMT+02:00 Ville Voutilainen <ville.voutilai...@gmail.com>:
> On 13 July 2016 at 21:25, Daniel Krügler <daniel.krueg...@gmail.com> wrote:
>> How would you feel about the introduction of an internal trait
>> __is_boolean_testable, that would test both is_convertible> bool> and is_constructible<bool, const T&> for now, so that we could
>> reuse that at places like these and others pointed out by LWG 2114?
>>
>> If you like that idea, I would work on a contribution.
>
> Sounds like an excellent idea to me.

I have opened an enhancement request and have now a (actually two)
proposal(s) for this. I would appreciate if you could express your
opinion here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899#c1

Thanks,

- Daniel

Re: [PATCH] Add constexpr to iterator adaptors, array and range access

[Daniel Krügler]

2016-07-16 1:09 GMT+02:00 Jonathan Wakely :
> This patch implements http://wg21.link/p0031 which adds constexpr to
> most operations on std::reverse_iterator, std::move_iterator,
> std::array, as well as std::advance, std::distance, and the
> range-access functions std::begin, std::rbegin etc.
>
> Strictly speaking, those functions should only be constexpr in C++17
> and not before, but this patch makes them constexpr whenever possible.
> That means the changes are fully implemented for C++14 (and the
> feature-test macro is defined) but only partially implemented for
> C++11, because some of the functions can't be constexpr in C++11.
>
> My thinking is that if the committee has decided that these functions
> *should* be constexpr, and changed them for C++17, then it doesn't
> serve users to make them non-constexpr in C++11 and C++14 just because
> the standard says so.
>
> How do other people feel about that?
>
> The alternative would be to define a new _GLIBCXX17_CONSTEXPR macro
> and use it in all these places, so they're only constexpr in C++17
> (and probably for -std=gnu++14 too, but not -std=c++14).
>
> How strict do we want to be about obeying the "implementors can't add
> constexpr" rule in these cases?

As much as I hate the current restrictions, I tend to suggest to
follow them strictly in __STRICT_ANSI__ mode.

> Here's the patch, but I'm not committing it yet.

Since I made a similar (unintentional) omission recently myself:
Shouldn't you touch std::__debug::array as well? What about other
functions from std::__debug?

- Daniel

Re: [PATCH] Remove redundant std::move in std::for_each

[Daniel Krügler]

2016-07-15 21:53 GMT+02:00 Jonathan Wakely :
> Returning a parameter will try to move anyway, so using std::move here
> is redundant (and clang even warns about it being redundant).
>
> * include/bits/stl_algo.h (for_each): Remove redundant _GLIBCXX_MOVE
> and adjust comment.

Actually I think this should also be reported as an LWG issue.

- Daniel

Re: [v3 PATCH] Implement P0307R2, Making Optional Greater Equal Again.

[Daniel Krügler]

2016-07-13 12:05 GMT+02:00 Ville Voutilainen :
> On 13 July 2016 at 01:31, Jonathan Wakely  wrote:
>> On 11/07/16 23:41 +0300, Ville Voutilainen wrote:
>>>
>>> @@ -785,41 +785,60 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>> }
>>> };
>>>
>>> +  template
>>> +using __optional_relop_t =
>>> +enable_if_t::value, bool>;
>>
>>
>> Should this be is_convertible<_Tp, bool> instead?
>
> Yeah.. it would be more reasonable to return a type explicitly
> convertible to bool from a relop
> if a non-bool is returned, but since built-in operators are not
> contextually-convertible-to-bool,
> that "protection" wouldn't buy much. And since the implementation
> doesn't really do bool-wrappings
> everywhere, let's go with is_convertible and change that if someone complains.

How would you feel about the introduction of an internal trait
__is_boolean_testable, that would test both is_convertible and is_constructible for now, so that we could
reuse that at places like these and others pointed out by LWG 2114?

If you like that idea, I would work on a contribution.

Thanks,

- Daniel

Re: [Patch] Implement is_[nothrow_]swappable (p0185r1) - 2nd try

[Daniel Krügler]

2016-06-16 17:07 GMT+02:00 Jonathan Wakely :
> On 16/06/16 14:08 +0100, Jonathan Wakely wrote:
>>
>>
>> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/20_util/is_nothrow_swappable/./value.h:285:3:
>> error: static assertion failed
>>
>> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/20_util/is_nothrow_swappable/./value.h:287:3:
>> error: static assertion failed
>>
>> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/20_util/is_nothrow_swappable/./value.h:289:3:
>> error: static assertion failed
>>
>> Those assertions fail for both 20_util/is_nothrow_swappable/value.cc
>> and 20_util/is_nothrow_swappable/value_ext.cc
>
>
> Those assertions should be changed because with your patch queue,
> priority_queue and stack are nothrow swappable, because they don't
> depend on the value_type's swappable trait, but the sequence's.

Yes, I agree.

> The other problems are that some tests need their dg-error lines
> adjusting, and  says #ifdef __cplusplus >= 201402L which
> should be #if.

OK.

Thanks again for your patience to test the whole mess!

- Daniel

Re: [Patch] Implement is_[nothrow_]swappable (p0185r1) - 2nd try

[Daniel Krügler]

2016-06-14 23:22 GMT+02:00 Daniel Krügler <daniel.krueg...@gmail.com>:
> This is an implementation of the Standard is_swappable traits according to
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0185r1.html
>
> During that work it has been found that std::array's member swap's exception
> specification for zero-size arrays was incorrectly depending on the value_type
> and that was fixed as well.
>
> This patch is *untested*, because I cannot make the tests run on my
> Windows system.
>
> Upon the suggestion of Mike Stump I'm proposing this patch
> nonetheless, asking for sending
> me as specific feedback as possible for any failing tests so that I
> can try to make further
> adjustments if needed.

And now also with the promised patch files.

> Thanks for your patience,
>
> - Daniel


changelog.patch
Description: Binary data


is_swappable_2.patch
Description: Binary data

[Patch] Implement is_[nothrow_]swappable (p0185r1) - 2nd try

[Daniel Krügler]

This is an implementation of the Standard is_swappable traits according to

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0185r1.html

During that work it has been found that std::array's member swap's exception
specification for zero-size arrays was incorrectly depending on the value_type
and that was fixed as well.

This patch is *untested*, because I cannot make the tests run on my
Windows system.

Upon the suggestion of Mike Stump I'm proposing this patch
nonetheless, asking for sending
me as specific feedback as possible for any failing tests so that I
can try to make further
adjustments if needed.

Thanks for your patience,

- Daniel

Re: [Patch] Implement is_[nothrow_]swappable (p0185r1)

[Daniel Krügler]

2016-05-23 13:50 GMT+02:00 Jonathan Wakely <jwak...@redhat.com>:
> On 17/05/16 20:39 +0200, Daniel Krügler wrote:
>>
>> This is an implementation of the Standard is_swappable traits according to
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0185r1.html
>>
>> During that work it has been found that std::array's member swap's
>> exception
>> specification for zero-size arrays was incorrectly depending on the
>> value_type
>> and that was fixed as well.
>
> This looks good to me, I'll get it committed (with some adjustment to
> the ChangeLog format) - thanks.

Unfortunately I need to withdraw the suggested patch. Besides some
obvious errors there are issues that require me to get the testsuite
run on my Windows system, which had not yet succeeded.

I would appreciate, if anyone who has succeeded to run the test suite
on a Windows system (preferably mingw), could contact me off-list.

Thanks,

- Daniel


-- 


SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154

[Patch] Implement is_[nothrow_]swappable (p0185r1)

[Daniel Krügler]

This is an implementation of the Standard is_swappable traits according to

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0185r1.html

During that work it has been found that std::array's member swap's exception
specification for zero-size arrays was incorrectly depending on the value_type
and that was fixed as well.

- Daniel


changelog.patch
Description: Binary data


is_swappable.patch
Description: Binary data

Re: New hashtable power 2 rehash policy

[Daniel Krügler]

2016-05-14 18:13 GMT+02:00 François Dumont :

> New patch attached, tested under linux x86_64.
>
> François

1) The function __clp2 is declared using _GLIBCXX14_CONSTEXPR, which
means that it is an inline function if and *only* if
_GLIBCXX14_CONSTEXPR really expands to constexpr, otherwise it is
*not* inline, which is probably not intended and could easily cause
ODR problems. I suggest to mark it unconditionally as inline,
regardless of _GLIBCXX14_CONSTEXPR.

2) Furthermore I suggest to declare __clp2 as noexcept - this is
(intentionally) *not* implied by constexpr.

3) Is there any reason, why _Power2_rehash_policy::_M_next_bkt
shouldn't be noexcept?

4) Similar to (3) for _Power2_rehash_policy's member functions
_M_bkt_for_elements, _M_need_rehash, _M_state, _M_reset

- Daniel

Re: [v3 PATCH] Avoid endless run-time recursion for copying single-element tuples where the element type is by-value constructible from any type

[Daniel Krügler]

Have you considered to test against decay instead of
remove_reference/remove_const? That would be similar to other places
in the standard. (I also believe that your fix actually should be
submitted as an LWG issue)

- Daniel

2016-05-08 13:43 GMT+02:00 Ville Voutilainen :
> Tested on Linux-PPC64.
>
> 2016-05-08  Ville Voutilainen  
>
> Avoid endless run-time recursion for copying single-element
> tuples where the element type is by-value constructible
> from any type.
>  * include/std/tuple (_TC<>::_NotSameTuple): New.
>  * include/std/tuple (tuple(_UElements&&...): Use it.
> * testsuite/20_util/tuple/cons/element_accepts_anything_byval.cc: New.



-- 


SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154

Re: [patch] libstdc++/69240 generic operator!= for random number distributions

[Daniel Krügler]

2016-01-14 20:21 GMT+01:00 Jonathan Wakely :
> We could constrain the generic operator== and operator!= to only match
> types that we want it to match, e.g. by having a type trait that is
> true for all our distributions and their parameter types. That would
> mean adding a specialization of it for each distribution and parameter
> type:
>
>  template
>struct
>__is_comparable_random_dist>
>: true_type { };
>
> Having to do that for every type removes some of the advantages of the
> patch, but would still be less code overall.
>
> If the operators are constrained in that way then I don't think it's a
> problem that the namespaces would be associated with more types,
> because there's nothing else in those namespaces that could be found
> by ADL.

If there were an __is_direct_base_of intrinsic (or is there?), it
seems to me that there would be no need for all these specializations
(each one nearly taking as much space as the explicit inline
definition of operator!) and there could be a single constrained
operator!= that would only trigger for types that are direct base
classes of __tag.

- Daniel

Re: [Patch, libstdc++/68877] Reimplement __is_[nothrow_]swappable

[Daniel Krügler]

Ping - this is a tentative reminder for this patch proposal.

2015-12-23 22:15 GMT+01:00 Daniel Krügler <daniel.krueg...@gmail.com>:
> This is a second try for a patch for libstdc++ bug 68877. See below
> for responses.
>
> 2015-12-22 22:42 GMT+01:00 Jonathan Wakely <jwak...@redhat.com>:
>> On 21/12/15 12:45 +0100, Daniel Krügler wrote:
>>>
>>> 2015-12-14 21:48 GMT+01:00 Daniel Krügler <daniel.krueg...@gmail.com>:
>>>>
>>>> This is a reimplementation of __is_swappable and
>>>> __is_nothrow_swappable according to
>>>>
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4511.html
>>>>
>>>> and also adds a missing usage of __is_nothrow_swappable in the swap
>>>> overload for arrays. Strictly speaking the latter change differs from
>>>> the Standard specification which requires the expression
>>>> noexcept(swap(*a, *b)) to be used. On the other hand the Standard is
>>>> broken in this regard, as pointed out by
>>>>
>>>> http://cplusplus.github.io/LWG/lwg-active.html#2554
>>
>> The patch doesn't apply cleanly because it repeats some of the new
>> files either twice or three times (and also has some trailing
>> whitespace that shouldn't be there).
>
> I can confirm this, albeit I don't understand why this happens. I'm
> using TortoiseSVN and when trying to create a patch file it creates
> double entries for new directories. I have now explicitly removed the
> added directories from the patch, I hope that your patch experience is
> now better.
>
>> After fixing the patch to only
>> create new files once it applies, but then I get some FAILs:
>>
>> FAIL: 20_util/is_nothrow_swappable/value.cc (test for excess errors)
>> FAIL: 20_util/is_swappable/value.cc (test for excess errors)
>>
>> I don't have time to analyse these today, so I'll wait until you're
>> able to do so.
>
> I'm sorry for these errors. I could now find a way to reproduce the
> tests and found that they were partially due to an incomplete commit
> and partially because of sleepiness on my side. I hopefully fixed
> these blatant errors and took the chance to increase the test cases
> even further.
>
> Thanks again,
>
> - Daniel



-- 


SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154

Re: [Patch, libstdc++/68877] Reimplement __is_[nothrow_]swappable

[Daniel Krügler]

This is a second try for a patch for libstdc++ bug 68877. See below
for responses.

2015-12-22 22:42 GMT+01:00 Jonathan Wakely <jwak...@redhat.com>:
> On 21/12/15 12:45 +0100, Daniel Krügler wrote:
>>
>> 2015-12-14 21:48 GMT+01:00 Daniel Krügler <daniel.krueg...@gmail.com>:
>>>
>>> This is a reimplementation of __is_swappable and
>>> __is_nothrow_swappable according to
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4511.html
>>>
>>> and also adds a missing usage of __is_nothrow_swappable in the swap
>>> overload for arrays. Strictly speaking the latter change differs from
>>> the Standard specification which requires the expression
>>> noexcept(swap(*a, *b)) to be used. On the other hand the Standard is
>>> broken in this regard, as pointed out by
>>>
>>> http://cplusplus.github.io/LWG/lwg-active.html#2554
>
> The patch doesn't apply cleanly because it repeats some of the new
> files either twice or three times (and also has some trailing
> whitespace that shouldn't be there).

I can confirm this, albeit I don't understand why this happens. I'm
using TortoiseSVN and when trying to create a patch file it creates
double entries for new directories. I have now explicitly removed the
added directories from the patch, I hope that your patch experience is
now better.

> After fixing the patch to only
> create new files once it applies, but then I get some FAILs:
>
> FAIL: 20_util/is_nothrow_swappable/value.cc (test for excess errors)
> FAIL: 20_util/is_swappable/value.cc (test for excess errors)
>
> I don't have time to analyse these today, so I'll wait until you're
> able to do so.

I'm sorry for these errors. I could now find a way to reproduce the
tests and found that they were partially due to an incomplete commit
and partially because of sleepiness on my side. I hopefully fixed
these blatant errors and took the chance to increase the test cases
even further.

Thanks again,

- Daniel
2015-12-23  Daniel Kruegler  <daniel.krueg...@gmail.com>

PR libstdc++/68877
* include/std/type_traits: Following N4511, reimplement __is_swappable and
__is_nothrow_swappable. Move __is_swappable to namespace std, adjust
callers. Use __is_nothrow_swappable in swap.
* include/bits/move.h: Use __is_nothrow_swappable in swap.
* testsuite/20_util/is_nothrow_swappable/value.cc: Extend; remove 
__is_swappable related tests.
* testsuite/20_util/is_swappable/value.cc: New.
* testsuite/20_util/is_swappable/requirements/explicit_instantiation.cc: 
New.
* testsuite/20_util/is_swappable/requirements/typedefs.cc: New.
* testsuite/25_algorithms/swap/68877.cc: New.


68877.patch
Description: Binary data

Re: [Patch, libstdc++/68877] Reimplement __is_[nothrow_]swappable

[Daniel Krügler]

2015-12-22 22:42 GMT+01:00 Jonathan Wakely <jwak...@redhat.com>:
> On 21/12/15 12:45 +0100, Daniel Krügler wrote:
>>
>> 2015-12-14 21:48 GMT+01:00 Daniel Krügler <daniel.krueg...@gmail.com>:
>>>
>>> This is a reimplementation of __is_swappable and
>>> __is_nothrow_swappable according to
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4511.html
>>>
>>> and also adds a missing usage of __is_nothrow_swappable in the swap
>>> overload for arrays. Strictly speaking the latter change differs from
>>> the Standard specification which requires the expression
>>> noexcept(swap(*a, *b)) to be used. On the other hand the Standard is
>>> broken in this regard, as pointed out by
>>>
>>> http://cplusplus.github.io/LWG/lwg-active.html#2554
>
>
> The patch doesn't apply cleanly because it repeats some of the new
> files either twice or three times (and also has some trailing
> whitespace that shouldn't be there). After fixing the patch to only
> create new files once it applies, but then I get some FAILs:
>
> FAIL: 20_util/is_nothrow_swappable/value.cc (test for excess errors)
> FAIL: 20_util/is_swappable/value.cc (test for excess errors)
>
> I don't have time to analyse these today, so I'll wait until you're
> able to do so. There's no great rush to fix this, as long as it's in
> stage 3.

Thanks for looking at this. When will stage 3 end?

Thanks,

- Daniel

Re: [Patch, libstdc++/68877] Reimplement __is_[nothrow_]swappable

[Daniel Krügler]

2015-12-14 21:48 GMT+01:00 Daniel Krügler <daniel.krueg...@gmail.com>:
> This is a reimplementation of __is_swappable and
> __is_nothrow_swappable according to
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4511.html
>
> and also adds a missing usage of __is_nothrow_swappable in the swap
> overload for arrays. Strictly speaking the latter change differs from
> the Standard specification which requires the expression
> noexcept(swap(*a, *b)) to be used. On the other hand the Standard is
> broken in this regard, as pointed out by
>
> http://cplusplus.github.io/LWG/lwg-active.html#2554

Jonathan explained to me that changelog entries should not be send as
diff, but just as plain text with the recommended addition, therefore
resending with that change applied.

Thanks,

- Daniel
2015-12-14  Daniel Kruegler  <daniel.krueg...@gmail.com>

PR libstdc++/68877
* include/std/type_traits: Following N4511, reimplement __is_swappable and
__is_nothrow_swappable. Move __is_swappable to namespace std, adjust
callers. Use __is_nothrow_swappable in swap.
* include/bits/move.h: Use __is_nothrow_swappable in swap.
* testsuite/20_util/is_nothrow_swappable/value.cc: Extend; remove 
__is_swappable related tests.
* testsuite/20_util/is_swappable/value.cc: New.
* testsuite/20_util/is_swappable/requirements/explicit_instantiation.cc: 
New.
* testsuite/20_util/is_swappable/requirements/typedefs.cc: New.
* testsuite/25_algorithms/swap/68877.cc: New.


68877.patch
Description: Binary data

[Patch, libstdc++/68877] Reimplement __is_[nothrow_]swappable

[Daniel Krügler]

This is a reimplementation of __is_swappable and
__is_nothrow_swappable according to

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4511.html

and also adds a missing usage of __is_nothrow_swappable in the swap
overload for arrays. Strictly speaking the latter change differs from
the Standard specification which requires the expression
noexcept(swap(*a, *b)) to be used. On the other hand the Standard is
broken in this regard, as pointed out by

http://cplusplus.github.io/LWG/lwg-active.html#2554

Thanks,

- Daniel


changelog.patch
Description: Binary data


68877.patch
Description: Binary data

Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

[Daniel Krügler]

2015-09-07 22:10 GMT+02:00 Jonathan Wakely <jwak...@redhat.com>:
> On 07/09/15 20:53 +0100, Jonathan Wakely wrote:
>> On 07/09/15 21:04 +0200, Daniel Krügler wrote:
>>> In the suggested doc changes:
>>>
>>> +When defined, _GLIBCXX_ASSERTIONS is defined
>>> +automatically, so all the assertions that enables are also
>>> enabled
>>> +in debug mode.
>>>
>>> there seems to be a typo, presumably it should be
>>>
>>> +When defined, _GLIBCXX_ASSERTIONS is defined
>>> +automatically, so all the assertions that it
>>> enables are also enabled
>>> +in debug mode.
>>>
>>> instead?
>>
>>
>> It's correct as I wrote it, but your version is clearer so I'll change
>> it.
>>
>> My original can be read as "so all the assertions that that enables"
>> where the first "that" can be removed without changing the meaning.
>> Stoopid English ;-)
>
>
> I think this is even better:
>
>  When defined, _GLIBCXX_ASSERTIONS is defined
>  automatically, so all the assertions enabled by that macro are
>  also enabled in debug mode.
>
> Is that clear?

It's perfect!

Thanks,

- Daniel

Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

[Daniel Krügler]

2015-09-07 20:27 GMT+02:00 Jonathan Wakely :
> This patch adds the "debug mode lite" we've been talking about, by
> changing __glibcxx_assert to be activated by _GLIBCXX_ASSERTIONS
> instead of _GLIBCXX_DEBUG (and making the latter imply the former).
>
> _GLIBCXX_ASSERTIONS is already used in Parallel Mode for enabling
> optional assertions (although some of them are O(n) and so we might
> want to change them to use another macro like _GLIBCXX_DEBUG or
> _GLIBCXX_PARALLEL_ASSERTIONS instead).
>
> With the change to define __glibcxx_assert() without Debug Mode we can
> change most uses of _GLIBCXX_DEBUG_ASSERT to simply __glibcxx_assert,
> so that the assertion is done when _GLIBCXX_ASSERTIONS is defined (not
> only in Debug Mode).
>
> I haven't added any new assertions yet, this just converts the
> lightweight Debug Mode checks, but the next step will be to add
> additional assertions to the (normal mode) containers. The google
> branches contain several good examples of checks to add.

In the suggested doc changes:

+When defined, _GLIBCXX_ASSERTIONS is defined
+automatically, so all the assertions that enables are also enabled
+in debug mode.

there seems to be a typo, presumably it should be

+When defined, _GLIBCXX_ASSERTIONS is defined
+automatically, so all the assertions that it
enables are also enabled
+in debug mode.

instead?

- Daniel

Re: Elimitate duplication of get_catalogs in different abi

[Daniel Krügler]

2015-08-21 23:11 GMT+02:00 François Dumont frs.dum...@gmail.com:
 I think I found a better way to handle this problem. It is c++locale.cc
 that needs to be built with --fimplicit-templates. I even think that the
 *_cow.cc file do not need this option but as I don't know what is the
 drawback of this option I kept it. I also explicitely used the file name
 c++locale.cc even if it is an alias to a configurable source file.  I
 guess there must be some variable to use no ?

 With this patch there are 6 additional symbols. I guess I need to
 declare those in the scripts even if it is for internal library usage,
 right ?

I would expect that the new Catalog_info definition either has deleted
or properly (user-)defined copy constructor and copy assignment
operator.


- Daniel

Re: [patch] libstdc++/66742 use allocators correctly in list::sort()

[Daniel Krügler]

2015-07-03 17:51 GMT+02:00 Jonathan Wakely jwak...@redhat.com:
 As well as reducing the number of lists we construct when sorting this
 also allows us to range-check and ensure we don't overflow the
 fixed-size array (we now get an exception if that happens, although
 that's probably not possible even on a 64-bit machine).

 Unfortunately this seems to hurt performance, presumably the extra
 indirections to the _ListSOrtBuf rather than just an array of lists
 confuse the optimisers.

 Does anyone see any better solution to this? (other than rewriting the
 whole sort function, which I think has been proposed)

I have not yet thought about better solutions, but:

- Isn't it necessary to cope with possibly final allocators when
unconditionally forming the derived member class

struct _Impl : allocator_type

? Maybe you could just define that as a non-deriving aggregate?

- Daniel

Re: [patch] std::polar requires non-negative rho

[Daniel Krügler]

2015-05-13 15:32 GMT+02:00 Jonathan Wakely jwak...@redhat.com:
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4383.html#2459

 Voted into the WP in Lenexa.

 Tested powerpc64le-linux, comitted to trunk.

What about assertions regarding non-NAN rho and finite theta, as
decided for by the LWG 2439?

- Daniel

Re: [patch] std::polar requires non-negative rho

[Daniel Krügler]

2015-05-13 16:05 GMT+02:00 Marc Glisse marc.gli...@inria.fr:
 On Wed, 13 May 2015, Daniel Krügler wrote:
 What about assertions regarding non-NAN rho and finite theta, as
 decided for by the LWG 2439?

 non-NAN rho is already covered by rho = 0.

Agreed on that.

- Daniel

Re: [patch] Fix std::experimental::any for small, non-trivial objects

[Daniel Krügler]

2015-05-02 15:03 GMT+02:00 Jonathan Wakely jwak...@redhat.com:
 Here's a much smaller patch for the gcc5 branch, which just avoids the
 small-object optimisation for non-trivially-copyable types. This
 pessimises some types, but is safe.

 (Given that this stuff is all experimental anyway, maybe we could
 just backport the full fix from trunk, but this is OK for now.)

 Tested powerpc64le-linux, committed to gcc-5-branch.

Not related to the patch, but is the second template argument of
any::_Storage::_M_buffer really correct:

std::aligned_storagesizeof(_M_ptr), sizeof(_M_ptr)::type _M_buffer;

I would have expected to see this to be an alignment value.

- Daniel

Re: [patch] std::experimental::ostream_joiner

[Daniel Krügler]

2015-05-02 19:14 GMT+02:00 Jonathan Wakely jwak...@redhat.com:
 The last piece of the Library Fundamentals 2 TS (until next week when
 all of v1 gets voted into v2, when it will include the v1 stuff we're
 missing).

 Tested powerpc64le-linux, committed to trunk.

Do you really want to copy the ugliness of the Standard specification
for in-class members or could this be made more readable as follows
(affects four members):

ostream_joiner_DelimT, _CharT, _Traits
=
ostream_joiner

? [I'm asking because I have not seen this to be the general style
used in libstdc++]

- Daniel

Re: [patch] Fix std::experimental::any for small, non-trivial objects

[Daniel Krügler]

2015-05-02 19:33 GMT+02:00 Jonathan Wakely jwak...@redhat.com:
 Looking at it now, I think the _Internal alias template should also
 check that alignof(_Tp) = alignof(void*) so that it can safely be
 stored in the _Storage.

 Otherwise a type with sizeof(T) = sizeof(void*) but
 alignof(T)  alignof(void*) would not be correctly aligned when stored
 in the buffer.

Yes, I agree.

- Daniel

Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

[Daniel Krügler]

2015-04-30 19:32 GMT+02:00 Jonathan Wakely jwak...@redhat.com:
 This is the complete experimental/filesystem implementation I intend
 to commit shortly. (It's also been pushed to the redi/filesystem-ts
 branch in the git mirror).

- There are three places where you refer to std::__addressof and one
where you refer to std::addressof. Is this difference intentional?

- I found all together six non-uglified usages of parameter name rhs
in the synopsis of directory_iterator and
recursive_directory_iterator.

b/libstdc++-v3/include/experimental/fs_ops.h:

- non-uglified parameters names ec, base, p, options,
new_time, prms:

path canonical(const path p, error_code ec);
path canonical(const path p, const path base, error_code ec);

void copy(const path __from, const path __to, copy_options options);
void copy(const path __from, const path __to, copy_options options,
error_code __ec) noexcept;

void last_write_time(const path __p, file_time_type new_time);
void last_write_time(const path __p, file_time_type new_time,
error_code __ec) noexcept;

void permissions(const path __p, perms prms);
void permissions(const path __p, perms prms, error_code __ec) noexcept;

b/libstdc++-v3/include/experimental/fs_path.h:

- non-uglified parameters names n, pos, equals:

void _M_add_root_name(size_t n);
void _M_add_root_dir(size_t pos);
void _M_add_filename(size_t pos, size_t n);

class path::iterator:
bool equals(iterator) const;

b/libstdc++-v3/src/filesystem/dir.cc:

- Shouldn't the template bool is_set(Bitmask obj, Bitmask bits) be inline?

b/libstdc++-v3/src/filesystem/ops.cc:

- Shouldn't the template  bool is_set(Bitmask obj, Bitmask bits) be inline?

- fs::space(const path p, error_code ec) noexcept:

If _GLIBCXX_HAVE_SYS_STATVFS_H is not defined, there should be a #else
that performs

ec = std::make_error_code(std::errc::not_supported);

- fs::path fs::temp_directory_path(error_code ec):

The code-branch

#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS

should start with:

ec = std::make_error_code(std::errc::not_supported);

b/libstdc++-v3/src/filesystem/path.cc:

- path::compare(const path p) const noexcept:

Shouldn't the implementation of this noexcept function not try to
create copies of path objects? Couldn't _Cmpt just hold references to
_M_pathname?

- Daniel

Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

[Daniel Krügler]

2015-05-01 20:22 GMT+02:00 Jonathan Wakely jwak...@redhat.com:
 On 01/05/15 19:03 +0200, Daniel Krügler wrote:

 b/libstdc++-v3/src/filesystem/path.cc:

 - path::compare(const path p) const noexcept:

 Shouldn't the implementation of this noexcept function not try to
 create copies of path objects? Couldn't _Cmpt just hold references to
 _M_pathname?

 All your other comments are definitely correct and I'll make the
 relevant fixes soon, but I'm not sure what you mean here, could you
 clarify?

My remembrance of the difference in noexcept qualifications of

int  compare(const path p) const noexcept;
int  compare(const string_type s) const;
int  compare(const value_type* s) const;

is that the latter are allowed to allocate memory to be implemented as
the standard writes the corresponding functions for std::basic_string:

int compare(const basic_string str) const noexcept;
int compare(const charT* s) const;

Returns: compare(basic_string(s)).

But if I read your implementation of path::compare(const path p)
correctly it *also* may allocate memory by copying _M_pathname into a
_Cmpt object. I was wondering whether for this comparison there exists
real need to *copy* _M_pathname (potentially exceeding the memory
limits). Wouldn't it be possible to define a _CmptRef type that for
the purpose of implementing compare(const path p) just refers to
references of the _M_pathname and therefore doesn't need to allocate
any dynamic storage? (I should have spoken of a new type _CmptRef and
not of your existing _Cmpt).

 I think it would be possible to implement a path like:

Actually I was not (yet) suggesting to change your API of path, I was
only wondering whether given the existing ABI compare(const path p)
could be implementable without need of additional dynamic memory. This
was more a kind of louder thinking, I have not fully thought whether
this not possible without changing your currently suggested ABI.

- Daniel

Re: [PATCH] [libstdc++] Add uniform container erasure.

[Daniel Krügler]

2015-04-30 16:44 GMT+02:00 Ed Smith-Rowland 3dw...@verizon.net:

 And make_array, which isn't in the working paper yet, so I'd prefer to
 leave that part out for now.

 D'oh!  Sorry about that..  Removed.

 The Doxygen @headername command tells users which header they are
 supposed to include, rather than this one. Since there is no
 erase_if header that's wrong. I'd just omit the @headername.

 Done.

 This file doesn't really seem like a .tcc to me, it isn't providing
 definitions of templates declared elsewhere (specifically in an
 erase_if.h header).

 Maybe we want an experimental/bits/ directory for this sort of thing
 (which I could also use for the filesystem headers I'm about to
 commit) but in the meanwhile I think just experimental/erase_if.h is a
 better name.

 Done. (I didn't make experimental/bits - I'll move erase_if.h after you add
 the bits directory).

 OK for trunk with those changes (remove make_array, rename erase_if.tcc)

 Rebuilt, retested and committed as 222630.
 Altered patch attached.

Shouldn't the one-liner forwarding function templates be declared as inline?

- Daniel

Re: [Patch, libstdc++/65420] Use constexpr variables as regex_constans flags

[Daniel Krügler]

2015-03-15 9:09 GMT+01:00 Tim Shen timshe...@gmail.com:
 Did a little bit refectoring on regex_constants, so that users won't
 be polluted too much (they are not enum types anymore).

Your implementation choice is an interesting approach. I believe that
a strict reading of the library specification does not allow that
form, because you are using as bitmask type a class type that is not
std::bitset:

[bitmask.types]:
Each bitmask type can be implemented as an enumerated type that
overloads certain operators, as an integer type, or as a bitset
(20.6).

One could argue that this restriction to this specific set of types
could be considered as a Standard Library defect, but no-one has yet
submitted one ;-), so it depends on the decision of the maintainers
here whether it would be better to follow that strict reading of the
Standard or not.

What I would consider as more controversial are the following things:

a) The class takes advantage of a deprecated rule to implicitly
declare a copy-assignment operator (because it has a user-declared
copy-constructor). I suggest to fix that and add a defaulted one
before at some future point this bitmask type is no longer
copy-assignable.

b) Basically no operation is marked as noexcept. This is
user-observable and seems like an unfortunate outcome.

c) The presence of a non-explicit conversion to bool allows users to
unintentionally write code like

std::regex_constants::syntax_option_type a = ..;
[..]
int x = a + 3; // Oops

The presence of this function also *seemingly* allows to implicitly
convert syntax_option_type to any integer type:

int x = a; // Oops

I suggest to make this conversion function explicit.

d) One could consider to mark the mutable operations
(syntax_option_type operator=(syntax_option_type)) as constexpr in
C++14 mode, but that is just an idea, not a required functionality.

- Daniel

Re: [Patch, libstdc++/63920] Fix regex_constants::match_not_null behavior

[Daniel Krügler]

2014-11-19 19:42 GMT+01:00 Tim Shen tims...@google.com:
 On Wed, Nov 19, 2014 at 8:16 AM, Paolo Carlini paolo.carl...@oracle.com 
 wrote:
 Good. To be clear, not having carefully analyzed whatsoever, my point was
 more about changing _M_end too, to non-const, than about not touching
 _M_begin. Would that make sense?

 Currently we never mutate _M_end. I *believe* that we still won't in
 the future, since _M_end is not as volatile as _M_begin.

I agree with Tim here, why shouldn't the const member and the
non-const member coexist?

- Daniel

Re: [patch] Support embedded zeros in sub_match comparisons (DR 2217)

[Daniel Krügler]

2014-11-13 23:30 GMT+01:00 Tim Shen tims...@google.com:
 On Thu, Nov 13, 2014 at 2:11 PM, Daniel Krügler
 daniel.krueg...@gmail.com wrote:
 +  typedef typename sub_match_Bi_iter::string_type string_type;

 Use _String_type instead of string_type? I'm not 100% sure of this.

I thought about this first, but withdraw that for two reasons: The
name string_type is not protected (it is an official typedef of
sub_match) and we use exactly the same approach elsewhere, e.g. see
around line 1318, 1346, 1398, 1426:

  templatetypename _Bi_iter
inline bool
operator==(typename iterator_traits_Bi_iter::value_type const __lhs,
   const sub_match_Bi_iter __rhs)
{
  typedef typename sub_match_Bi_iter::string_type string_type;
  return __rhs.compare(string_type(1, __lhs)) == 0;
}

So I followed for consistency reasons.

- Daniel

Re: [patch] Make std::vectorbool meet C++11 allocator requirements.

[Daniel Krügler]

2014-10-31 21:49 GMT+01:00 Jonathan Wakely jwak...@redhat.com:
 There's no better time to fix evil vectorbool than Halloween.

Great - so you removed vectorbool?;-)

- Daniel

Re: sort_heap complexity guarantee

[Daniel Krügler]

2014-10-07 23:11 GMT+02:00 François Dumont frs.dum...@gmail.com:
 On 06/10/2014 23:05, Daniel Krügler wrote:
 François, could you please submit a corresponding LWG issue by sending
 an email using the recipe described here:

 http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue

 ?

 I just did requesting to use 2N log(N).

 And is it ok to commit those ?

Looks fine to me - Thanks!

- Daniel

Re: sort_heap complexity guarantee

[Daniel Krügler]

2014-10-06 23:00 GMT+02:00 François Dumont frs.dum...@gmail.com:
 On 05/10/2014 22:54, Marc Glisse wrote:

 On Sun, 5 Oct 2014, François Dumont wrote:

I took a look at PR 61217 regarding pop_heap complexity guarantee.
 Looks like we have no test to check complexity of our algos so I start
 writing some starting with the heap operations. I found no issue with
 make_heap, push_heap and pop_heap despite what the bug report is saying
 however the attached testcase for sort_heap is failing.

Standard is saying std::sort_heap shall use less than N * log(N)
 comparisons but with my test using 1000 random values the test is showing:

 8687 comparisons on 6907.76 max allowed

Is this a known issue of sort_heap ? Do you confirm that the test is
 valid ?

 I would first look for confirmation that the standard didn't just forget a
 big-O or something. I would expect an implementation as n calls to pop_heap
 to be legal, and if pop_heap makes 2*log(n) comparisons, that naively sums
 to too much. And I don't expect the standard to contain an advanced
 amortized analysis or anything like that...

 Good point, with n calls to pop_heap it means that limit must be 2*log(1) +
 2*log(2) +... + 2*log(n) which is 2*log(n!) and  which is also necessarily 
 2*n*log(n). I guess Standard comittee has forgotten the factor 2 in the
 limit so this is what I am using as limit in the final test, unless someone
 prefer the stricter 2*log(n!) ?

François, could you please submit a corresponding LWG issue by sending
an email using the recipe described here:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue

?

Thanks,

- Daniel

Re: [Patch] Patch set for regex instantiation

[Daniel Krügler]

2014-06-29 20:47 GMT+02:00 Tim Shen timshe...@gmail.com:
 On Sun, Jun 29, 2014 at 10:18 AM, Jonathan Wakely jwak...@redhat.com wrote:
 Alternatively, we could just make them local statics instead of member
 data and still remove the duplciation (see attached).

 This is a good idea. Can we use constexpr for the functions/static variables?

Not so for local statics within constexpr functions, but you could
have constexpr static data members, yes.

- Daniel

Re: [patch] libstdc++/61374 fix string_view conversion and update to latest draft

[Daniel Krügler]

2014-06-01 19:24 GMT+02:00 Jonathan Wakely jwak...@redhat.com:
 Tested x86_64-linux, committed to trunk.

 This should probably go on the 4.9 branch too, although we could leave
 the old default cosntructor semantics and just fix the conversion
 operator.

Looking at the comparison functions of basic_string_view I noticed
that these are not constexpr (nor seem to be other functions such as
find()).

- Daniel

Re: [patch] simplify bits/uses_allocator.h

[Daniel Krügler]

2014-06-02 0:35 GMT+02:00 Jonathan Wakely jwak...@redhat.com:
 2014-06-01  Jonathan Wakely  jwak...@redhat.com

 * include/bits/uses_allocator.h (__uses_allocator_helper): Simplify.
 (__uses_allocator_arg): Remove unused type.
 (__uses_alloc0): Turn into a trivial type.
 (__uses_alloc): Add missing template parameter in primary template.
 (__uses_alloc_impl): Rename to __uses_alloc_t.

Some of the changes remove the explicit access-specifier (public) from
base classes, such as

: public false_type
=
: false_type

In the affected examples this does not introduce a change of meaning
(because the classes are declared as structs), but my understanding
had been in the past that base class access specifiers should always
been provided in gcc code bases to make the code robust against
potential refactoring.

Is this simply an incorrect understanding of mine that is not based by
the gcc coding styles? I thought that Paolo taught me the
explicit-access-style, but I might err.

- Daniel

Re: [patch] simplify bits/uses_allocator.h

[Daniel Krügler]

2014-06-02 0:50 GMT+02:00 Jonathan Wakely jwak...@redhat.com:
 On 02/06/14 00:46 +0200, Daniel Krügler wrote:

 Some of the changes remove the explicit access-specifier (public) from
 base classes, such as

 : public false_type
 =
 : false_type

 In the affected examples this does not introduce a change of meaning
 (because the classes are declared as structs), but my understanding
 had been in the past that base class access specifiers should always
 been provided in gcc code bases to make the code robust against
 potential refactoring.

 Is this simply an incorrect understanding of mine that is not based by
 the gcc coding styles? I thought that Paolo taught me the
 explicit-access-style, but I might err.

 I consider them to be redundant clutter, but I didn't realise we had
 such a rule, so I'm happy to put the access-specifiers back.

My formulation was intentionally tentative, because I never searched
for that coding rule. Maybe Paolo could help to clarify.

- Daniel

Re: [PATCH, libstdc++/61166] overflow when parse number in std::duration operator

[Daniel Krügler]

2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland 3dw...@verizon.net:
 Make the machinery in bits/parse_number.h unsigned long long.
 I had actually noticed this a while back but we were in stage 4. Then I
 forgot.. :-/

 Built and tested on x84_64-linux.

 OK?

I understand the reason why the corresponding static members value got
type unsigned long long, but why did the template parameter _Base also
require the same update?

Another question: Presumably value indded requires no uglification,
but what about the member valid? I would expect that this is no name
reserved by the library.

- Daniel



-- 


SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154