Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

2022-12-12 Thread Stephan Bergmann via Gcc-patches
On 12/12/2022 12:18, Jonathan Wakely wrote: If Clang already treats __is_signed as a conditionally-active built-in, it should do the same for __is_unsigned. Wasn't aware of that special handling of __is_signed. Filed "Also allow __is_unsigned to be used as

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

2022-12-12 Thread Jonathan Wakely via Gcc-patches
On Mon, 12 Dec 2022 at 11:18, Jonathan Wakely wrote: > > On Mon, 12 Dec 2022 at 07:12, Stephan Bergmann via Libstdc++ > wrote: > > > > On 11/21/22 21:43, Jonathan Wakely via Libstdc++ wrote: > > > + static constexpr bool __is_unsigned > > > + = __and_v, > > > + is_unsigne

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

2022-12-12 Thread Jonathan Wakely via Gcc-patches
On Mon, 12 Dec 2022 at 07:12, Stephan Bergmann via Libstdc++ wrote: > > On 11/21/22 21:43, Jonathan Wakely via Libstdc++ wrote: > > + static constexpr bool __is_unsigned > > + = __and_v, > > + is_unsigned>; > > Using `__is_unsigned` as an identifier here causes compilatio

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

2022-12-11 Thread Stephan Bergmann via Gcc-patches
On 11/21/22 21:43, Jonathan Wakely via Libstdc++ wrote: + static constexpr bool __is_unsigned + = __and_v, + is_unsigned>; Using `__is_unsigned` as an identifier here causes compilation issues with Clang, which predefines that as a builtin predicate.

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

2022-12-06 Thread Jonathan Wakely via Gcc-patches
I've pushed this to trunk. Tested x86_64-linux. On Mon, 21 Nov 2022 at 20:44, Jonathan Wakely via Libstdc++ wrote: > > While finishing the time zone support for C++20, I noticed that the > chrono::hh_mm_ss type is surprisingly large: 40 bytes. That's because > we use duration for each of the four

[PATCH] libstdc++: Make chrono::hh_mm_ss more compact

2022-11-21 Thread Jonathan Wakely via Gcc-patches
While finishing the time zone support for C++20, I noticed that the chrono::hh_mm_ss type is surprisingly large: 40 bytes. That's because we use duration for each of the four members, _M_h, _M_m, _M_s and _M_ss. This is very wasteful. The patch below reduces it to 16 bytes (or less for some targets