On Wed, 19 Oct 2022 at 13:59, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch adds the easy part of , and
> changes for extended floats.
> In particular, for the first one only overloads where the _Float* has
> the same format as float/double/long double and for the latter two
> everything
On Thu, 27 Oct 2022 at 09:00, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch on top of
> https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> adds std::{,b}float16_t support for std::to_chars.
> When precision is specified (or for std::bfloat16_t for hex mode even if not),
> I
On Tue, 1 Nov 2022 at 12:18, Jakub Jelinek wrote:
>
> On Fri, Oct 28, 2022 at 12:52:44PM -0400, Patrick Palka wrote:
> > > The following patch on top of
> > > https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> > > adds std::{,b}float16_t support for std::to_chars.
> > > When precis
On Tue, 1 Nov 2022 at 09:36, Jakub Jelinek wrote:
>
> Hi!
>
> On top of the
> https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> https://gcc.gnu.org/pipermail/libstdc++/2022-October/054886.html
> the following patch adds std::from_chars support, similarly to the
> previous std::to_
On Mon, 31 Oct 2022 at 20:33, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
We should update https://gcc.gnu.org/gcc-13/changes.html#libstdcxx again soon.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (as_rvalue_vie
On Mon, 31 Oct 2022 at 17:05, Jonathan Wakely wrote:
>
> On Mon, 31 Oct 2022 at 17:03, Eric Botcazou wrote:
> >
> > > I suppose we could use memcmp on the as variable itself, to inspect
> > > the actual stored padding rather than the returned copy of it.
> >
> > Yes, that's probably the only safe
This will just confuse most users, the separate tarballs haven't existed
for years (as already noted elsewhere in install.texi).
OK for trunk?
-- >8 --
gcc/ChangeLog:
* doc/install.texi: Remove anachronism about separate source
tarballs.
---
gcc/doc/install.texi | 4 +---
1 fil
On Wed, 2 Nov 2022 at 09:39, Jakub Jelinek wrote:
>
> Hi!
>
> Jon pointed out that we have TODO: _Bfloat16 in .
> Right now _S_fp_fmt() returns _Binary16 for _Float16, __fp16 as well
> as __bf16 and it actually works because we don't have a special handling
> of _Binary16. So, either we could jus
On Tue, 1 Nov 2022 at 21:30, Patrick Palka via Libstdc++
wrote:
>
> The fallback implementation of floating-point std::from_chars for e.g.
> float80 just calls the C library's strtod family of functions. In case
> of overflow of the parsed result, the behavior of these functions is
> rigidly spec
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
The warning is wrong here, the qualifier serves a purpose and is not
ignored (c.f. PR c++/107492).
libstdc++-v3/ChangeLog:
* include/std/variant (__variant::_Multi_array::__untag_result):
Use pragma to suppress warning.
---
li
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
Hui Xie pointed out that we don't need a dummy member in the union,
because all constructors always initialize either _M_val or _M_unex.
We still need the _M_void member of the expected
specialization, because the constructor has to initialize
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
We don't need these 'unused' members because they're never used, and a
union with a single variant member is fine.
libstdc++-v3/ChangeLog:
* libsupc++/eh_globals.cc (constant_init::unused): Remove.
* src/c++11/system_error.cc (
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is needed to support a move-only output iterator when the input
iterators are specializations of __normal_iterator.
libstdc++-v3/ChangeLog:
* include/bits/ranges_algobase.h (__detail::__copy_or_move):
Move output iterator.
On Wed, 2 Nov 2022 at 13:42, Patrick Palka via Libstdc++
wrote:
>
> IIUC such variables should be declared inline to avoid potential ODR
> violations since they're otherwise considered to be distinct (internal
> linkage) entities across TUs.
>
> The changes inside the regex_constants and execution
Tested powerpc64le-linux, pushed to trunk. Needs backporting.
-- >8 --
When I changed std::thread and std::async to avoid unnecessary move
construction of temporaries, I introduced a regression where types with
an explicit copy constructor could not be passed to std::thread or
std::async. The fix
Tested powerpc64le-linux, pushed to trunk. Worth backporting.
-- >8 --
Currently we fail to notice integer overflow when parsing a
back-reference expression, or when converting the parsed result from
long to int. This changes the result to be int, so no conversion is
needed, and uses the overflow
Tested powerpc64le-linux, pushed to trunk. Needs backporting.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/105678
* doc/xml/manual/using.xml: Document -lstdc++_libbacktrace
requirement for using std::stacktrace. Also adjust -frtti and
-fexceptions to document non
On Tue, 23 Aug 2022 at 02:35, Patrick Palka via Libstdc++
wrote:
>
> P2321R2 adds new conditionally explicit constructors to std::tuple which
> we'll concisely implement in a subsequent patch using explicit(bool), like
> in our C++20 std::pair implementation. But before we can do that, this
> pat
On Tue, 23 Aug 2022 at 02:36, Patrick Palka via Libstdc++
wrote:
> --- a/libstdc++-v3/include/bits/stl_pair.h
> +++ b/libstdc++-v3/include/bits/stl_pair.h
> @@ -212,6 +212,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> swap(second, __p.second);
>}
>
> +#if __cplusplus > 202002L
> +
On Tue, 23 Aug 2022 at 14:44, Patrick Palka wrote:
>
> On Tue, 23 Aug 2022, Jonathan Wakely wrote:
>
> > On Tue, 23 Aug 2022 at 02:35, Patrick Palka via Libstdc++
> > wrote:
> > >
> > > P2321R2 adds new conditionally explicit constructors to std::tuple which
> > > we'll concisely implement in a s
Tested powerpc64le-linux, pushed to trunk. Backport to gcc-12 needed.
-- >8 --
The optimization for the common case of std::visit forgot to handle the
edge case of passing zero variants to a non-void visitor and converting
the result to void.
libstdc++-v3/ChangeLog:
PR libstdc++/106589
On Mon, 22 Aug 2022 at 19:15, Will Hawkins wrote:
>
> Until now operator+(char*, string) and operator+(string, char*) had
> different performance characteristics. The former required a single
> memory allocation and the latter required two. This patch makes the
> performance equal.
If you don't ha
On Wed, 24 Aug 2022 at 07:18, Will Hawkins wrote:
>
> On Tue, Aug 23, 2022 at 12:33 PM Jonathan Wakely wrote:
> >
> > On Mon, 22 Aug 2022 at 19:15, Will Hawkins wrote:
> > >
> > > Until now operator+(char*, string) and operator+(string, char*) had
> > > different performance characteristics. The
On Tue, 23 Aug 2022 at 02:38, Patrick Palka via Libstdc++
wrote:
>
> Tested on 86_64-pc-linux-gnu, does this look OK for trunk?
As discussed privately, please remove the #include (which is
not needed, and adds declarations to the global namespace that we
don't need).
OK with that change, thanks
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This LWG issue was closed as NAD, as it was just a bug in an
implementation, not a defect in the standard. Libstdc++ never had that
bug and always worked for the problem case. Add a test to ensure we
don't regress.
The problem occurs when abs i
On Wed, 24 Aug 2022 at 07:17, Will Hawkins wrote:
>
> Until now operator+(char*, string) and operator+(string, char*) had
> different performance characteristics. The former required a single
> memory allocation and the latter required two. This patch makes the
> performance equal.
>
> libstdc++-v3
Tested powerpc64le-linux, pushed to trunk.
No backport needed as the regression is only on trunk.
-- >8 --
The recent change to split out the cold path of std::stable_sort caused
a regression for some Qt code. The problem is that the library now adds
a value of type ptrdiff_t to the iterator, wh
On Wed, 24 Aug 2022 at 18:00, Patrick Palka via Libstdc++
wrote:
>
> On Wed, 24 Aug 2022, Patrick Palka wrote:
>
> > r13-2159-g72886fcc626953 introduced some testsuite regressions in C++23
> > mode:
> >
> > FAIL: 20_util/pair/requirements/explicit_instantiation/1.cc (test for
> > excess errors)
On Wed, 24 Aug 2022 at 23:39, Alexandre Oliva wrote:
>
> On Aug 24, 2022, Jonathan Wakely via Gcc-patches
> wrote:
>
> >* include/bits/basic_string.h (operator+(const string&,
> > const char*)):
> >Remove naive implementat
On Wed, 24 Aug 2022 at 23:47, Jonathan Wakely wrote:
>
> On Wed, 24 Aug 2022 at 23:39, Alexandre Oliva wrote:
> >
> > On Aug 24, 2022, Jonathan Wakely via Gcc-patches
> > wrote:
> >
> > >* include/bits/basic_string.h (op
On Fri, 26 Aug 2022, 02:06 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/20_util/logical_traits/requirements/base_classes.cc:
> New test.
> ---
> .../requirements/base_
On Sun, 14 Aug 2022 at 16:34, François Dumont via Libstdc++
wrote:
>
> I think we can add those checks.
>
> Note that I wonder if it was needed as in basic_string_view I see usages
> of __attribute__((__nonnull__)). But running the test I saw no impact
> even after I try to apply this attribute to
On Fri, 26 Aug 2022 at 14:45, Patrick Palka via Libstdc++
wrote:
>
> On Wed, 24 Aug 2022, Patrick Palka wrote:
>
> > The internal type-level logical operations __and_ and __or_ are
> > currently quite slow to compile for a couple of reasons:
> >
> > 1. They are drop-in replacements for std::con/
While looking into LWG 3741 I came up with this small change to
chrono::abs, which reduces how much work the compiler does to compile
it, but makes the code less clear. The current implementation is very
easy to understand, and compiling chrono::abs probably isn't a hotspot
in anybody's build. Is t
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
Ideally this wouldn't be needed, because eventually these pointers all
get passed to either the basic_string_view(const CharT*) constructor, or
to basic_string_view::find(const CharT*), both of which already have the
attribute. But for that to w
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This removes the redundant operator=(E) from std::error_code and
std::error_condition. Without that overload, assignment from a custom
type will use the templated constructor to create a temporary and then
use the trivial copy assignment operato
On Thu, 25 Aug 2022 at 16:40, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (zip_view::_Iterator::operator<): Remove.
> (zip_view::_Iterator::operator>): Remove.
On Thu, 25 Aug 2022 at 16:40, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (zip_view::_Iterator): Befriend
> zip_transform_view.
> (__detail::__range_ite
On Tue, 23 Aug 2022 at 02:38, Patrick Palka via Libstdc++
wrote:
> +template
> + constexpr void
> + __tuple_for_each(_Fp&& __f, _Tuple&& __tuple)
> + {
> + std::apply([&](_Ts&&... __elts) {
> + (std::__invoke(__f, std::forward<_Ts>(__elts)), ...);
> + }, std:
I plan to commit this after testing finishes, probably on Monday.
Basic testing on powerpc64le-linux is clean, but I'm still running debug
mode and other variations of tests.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (basic_string): Add nodiscard
attribute t
On Wed, 31 Aug 2022 at 05:38, François Dumont wrote:
>
> If I got your point correctly here is this patch again with just the
> change on '0' becoming 'nullptr' in assertions.
>
> libstdc++: [_GLIBCXX_DEBUG] Review nullptr assertion diagnostics
>
> Review null string checks to show:
>
On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Yes, thanks for adding this.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/20_util/logical_traits/requirements/short_circuit.cc: New
> test.
> ---
> .../requir
On Wed, 31 Aug 2022 at 06:05, François Dumont wrote:
>
> After a second thought here is an even cleaner version. No more function
> rename, current pretty_print is fine.
>
> libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
>
>Add _GLIBCXX_DEBUG_BACKTRACE macro to activat
On Fri, 26 Aug 2022 at 21:05, Jonathan Wakely wrote:
>
> On Tue, 23 Aug 2022 at 02:38, Patrick Palka via Libstdc++
> wrote:
> > +template
> > + constexpr void
> > + __tuple_for_each(_Fp&& __f, _Tuple&& __tuple)
> > + {
> > + std::apply([&](_Ts&&... __elts) {
> > +
On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> +constexpr
> +_Iterator(__as_sentinel, iterator_t<_Base> __first, iterator_t<_Base>
> __last)
> +{
> + if constexpr (!bidirectional_range<_Base>)
>
On Wed, 31 Aug 2022 at 14:30, Patrick Palka wrote:
>
> On Wed, 31 Aug 2022, Jonathan Wakely wrote:
>
> > On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
> > wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> >
> > > +constexpr
> > > +_Iterator(_
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/20_util/reference_wrapper/invoke-2.cc: Improve
comments.
* testsuite/20_util/reference_wrapper/invoke-3.cc: Likewise.
* testsuite/20_util/reference_wrapper/invoke.cc: Likewise.
---
Tested x86_64-linux, pushed to trunk.
-- >8 --
This isn't required by the standard, but there's an LWG issue suggesting
to add it.
Also use __invoke_result instead of result_of, to match the spec in
recent standards.
libstdc++-v3/ChangeLog:
* include/bits/refwrap.h (reference_wrapper::
On Wed, 31 Aug 2022 at 20:33, François Dumont wrote:
>
> On 31/08/22 12:11, Jonathan Wakely wrote:
> > On Wed, 31 Aug 2022 at 06:05, François Dumont wrote:
> >> After a second thought here is an even cleaner version. No more function
> >> rename, current pretty_print is fine.
> >>
> >> libs
On Wed, 31 Aug 2022 at 20:27, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
I missed this testsuite fix in the libstdc++ commit.
Tested x86_64-linux, pushed to trunk.
-- >8 --
std::string now has [[nodiscard]] attributes on most members, causing
-Wunused-result warnings for this test.
gcc/testsuite/ChangeLog:
PR testsuite/106795
* g++.dg/tree-ssa/empty
Tested powerpc64le-linux, pushed to trunk.
This is the first in a series of patches to optimize compile time for
the contents of .
-- >8 --
Improve compile times by avoiding unnecessary class template
instantiations.
__is_array_known_bounds and __is_array_unknown_bounds can be defined
without i
On Mon, 29 Aug 2022 at 11:31, Gerald Pfeifer wrote:
>
> On Wed, 24 Aug 2022, Jonathan Wakely wrote:
> >> a broken link points to
> >>
> >> An introduction to GCC by Brian J. Gough.
> >> . http://www.network-theory.co.uk/gcc/intro/
> > There are much more recent archived copies like
> > https://
On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (__detail::__unarize): Define.
> (adjacent_view::_Iterator): Befriend adjacent_transform_view.
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
PR c++/99968 is fixed since GCC 12.1 so we can remove the workaround.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_scoped_enum): Remove workaround.
---
libstdc++-v3/include/std/type_traits | 11 +--
1 file changed, 1
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This avoids having to instantiate a class template that just uses the
same built-in anyway.
None of the corresponding class templates have any type-completeness
static assertions, so we're not losing any diagnostics by using the
built-ins direc
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
We can replace some class template helpers with alias templates, which
are cheaper to instantiate.
For example, replace the __is_copy_constructible_impl class template
with an alias template that uses just evaluates the __is_constructible
built
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This avoids having to instantiate a class template when we can detect
the true cases easily with a partial specialization.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_lvalue_reference_v)
(is_rvalue_reference_v, is_ref
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
We only use the __is_referenceable helper in three places now:
add_pointer, add_lvalue_reference, and add_rvalue_reference. But lots of
other traits depend on add_[lr]value_reference, and decay depends on
add_pointer, so removing the instantiati
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
Define partial specializations of std::decay and its __decay_selector
helper so that remove_reference, is_array and is_function are not
instantiated for every type, and remove_extent is not instantiated for
arrays.
libstdc++-v3/ChangeLog:
Tested x86_64-linux, pushed to trunk.
-- >8 --
Clang doesn't yet implement the C++20 change that makes 'typename'
optional here.
libstdc++-v3/ChangeLog:
* include/std/ranges (adjacent_transform_view::_Iterator): Add
typename keyword before dependent qualified-id.
---
libstdc++-
On Fri, 2 Sep 2022, 14:35 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> On Fri, 2 Sep 2022, Patrick Palka wrote:
>
> > r13-2230-g390f94eee1ae69 redefined the internal logical operator traits
> > __and_, __or_ and __not as alias templates that directly resolve to
> > true_type or f
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This defines the is_xxx_constructible_v and is_xxx_assignable_v variable
templates by using the built-ins directly. The actual logic for each one
is the same as the corresponding class template, but way using the
variable template doesn't need t
On Fri, 2 Sept 2022 at 17:39, Patrick Palka via Libstdc++
wrote:
>
> Now that these internal type traits are again class templates, it's
> better to derive from the trait's ::type (which is either false_type or
> true_type) instead of from the trait itself, for sake of a shallower
> inheritance ch
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_trivial_v, is_trivially_copyable_v)
(is_standard_layout_v, is_pod_v, is_literal_type_v): Use
built-in instead of class template.
(is_same_v): Add partial spec
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/type_traits (__success_type, __failure_type): Move
definitions later in the file.
---
libstdc++-v3/include/std/type_traits | 25 +
1 file changed, 13 insertions(+), 12 de
On Tue, 6 Sept 2022 at 02:07, Will Hawkins wrote:
>
> Confirming that patch 1 of 2 *does* fix the failing tests here (x86-64).
>
> Will
>
> PS: Please tell me if emails like this are helpful or not. Just trying to
> help!
Thanks. I wasn't even seeing the failing tests, due to errors from GDB:
D
Thanks for the patch. Comments below.
On Sun, 4 Sept 2022 at 19:48, Philipp Fent via Libstdc++
wrote:
>
> Signed-off-by: Philipp Fent
> ---
> libstdc++-v3/python/libstdcxx/v6/printers.py | 37 +++
> .../libstdc++-prettyprinters/debug.cc | 5 +++
> .../libstdc++-pretty
On Wed, 7 Sept 2022 at 01:46, Patrick Palka via Libstdc++
wrote:
>
> Instead of defining is_reference in terms of is_lvalue_reference
> and is_rvalue_reference, just define it directly.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Yes, thanks (I already did this for the std::is
On Wed, 7 Sept 2022 at 01:46, Patrick Palka via Libstdc++
wrote:
>
> Instead of defining these in terms of a helper class template
> and the relatively expensive __remove_cv_t, just declare four
> explicit specializations of the main template, one for each choice
> of cv-quals.
>
> Tested on x86_6
On Wed, 7 Sept 2022 at 02:45, Jason Merrill via Libstdc++
wrote:
>
> An email discussion of optimizing EH led me to wonder why we weren't doing
> this already. Not that this change affects EH at all.
>
> Tested x86_64-pc-linux-gnu. Does this seem worthwhile?
Yes, I think so. If there's a fast p
Here's a complete patch that combines the various incremental patches
that have been going around. I'm testing this now.
Please take a look.
commit 4a0a8ec5bc2a890a1568f99eace666e9f72d
Author: Thomas Rodgers
Date: Thu Aug 25 11:11:40 2022
libstdc++: Clear padding bits in atomic compare
Tested powerpc64le-linux. OK for trunk?
-- >8 --
The check_trait_type function is used for a number of different type
traits that have different requirements on their arguments. For example,
__is_constructible allows arrays of unknown bound even if the array
element is an incomplete type, but __i
On Wed, 7 Sept 2022 at 18:03, François Dumont via Libstdc++
wrote:
>
> libstdc++: Use glibc >= 2.33 mallinfo2 function
>
> mallinfo started to be deprecated which makes performance tests failed
> to build, just
> adopt mallinfo2.
>
> libstdcxx-v3/ChangeLog:
>
> * testsuite/util/testsuite_
Tested powerpc64le-linux, pushed to trunk.
Backports to gcc-11 and gcc-12 needed too.
-- >8 --
This file is missing the GCC Runtime Library Exception text in the
licence header. That is unintentional, and it should have been present.
libstdc++-v3/ChangeLog:
* include/std/barrier: Add m
On Thu, 8 Sept 2022 at 06:03, François Dumont wrote:
>
> libstdc++: glibc mallinfo deprecated, use mallinfo2 when version =>
> 2.33
>
> glibc mallinfo is now deprecated resulting in make check-performance
> failure. When glibc => 2.33 prefer mallinfo2.
>
> libstdcxx-v3/ChangeLo
On Wed, 7 Sept 2022 at 16:11, Jason Merrill wrote:
>
> On 9/7/22 08:18, Jonathan Wakely wrote:
> > @@ -12080,23 +12098,37 @@ finish_trait_expr (location_t loc, cp_trait_kind
> > kind, tree type1, tree type2)
> > case CPTK_HAS_TRIVIAL_COPY:
> > case CPTK_HAS_TRIVIAL_DESTRUCTOR:
> >
On Thu, 8 Sept 2022 at 17:12, Jason Merrill wrote:
>
> On 9/8/22 08:56, Jonathan Wakely wrote:
> > On Wed, 7 Sept 2022 at 16:11, Jason Merrill wrote:
> >>
> >> On 9/7/22 08:18, Jonathan Wakely wrote:
> >>> @@ -12080,23 +12098,37 @@ finish_trait_expr (location_t loc,
> >>> cp_trait_kind kind, tree
On Thu, 8 Sep 2022, 18:51 François Dumont via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> On 05/09/22 20:30, Will Hawkins wrote:
> > Based on Jonathan's work, here is a patch for the implementation of
> operator+
> > on std::string that makes sure we always use the best allocation
> strategy.
> >
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
These are all trivial bit-twiddling operations that don't need the
overhead of a function call in unoptimized code.
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/c_global/cstddef (byte): Add always_inline attribute
to all operator overload
Pushed to wwwdocs.
---
htdocs/gcc-12/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index c6dae27a..2cb5a654 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -988,7 +988,7 @@ funct
On Fri, 9 Sep 2022, 18:25 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> make_unsigned_t can't give us the unsigned version of an integer-class
> difference type, so use __make_unsigned_like_t / __to_unsigned_like
> instead.
>
OK, thanks
> PR libstdc++/106766
>
> libstd
On Fri, 9 Sep 2022, 18:25 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> PR libstdc++/106798
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (adjacent_view::_Iterator::_Iterator): Fix
> typo.
> * testsuite/std/ranges/adaptors/adjacent/1.cc (test
On Fri, 9 Sep 2022, 18:27 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this series look OK for trunk?
>
All three are OK, thanks.
> PR libstdc++/106803
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (views::_ZipTransfo
On Fri, 9 Sept 2022 at 20:01, Thomas Rodgers wrote:
>
> s/__weak/__is_weak/g perhaps?
Yes, that'll do. Fixed by the attached, with a test to avoid it happening again.
Tested x86_64-linux, pushed to trunk.
>
> On Fri, Sep 9, 2022 at 11:46 AM Iain Sandoe via Libstdc++
> wrote:
>>
>>
>>
>> >
On Thu, 8 Sept 2022 at 18:51, François Dumont via Libstdc++
wrote:
>
> On 05/09/22 20:30, Will Hawkins wrote:
> > Based on Jonathan's work, here is a patch for the implementation of
> > operator+
> > on std::string that makes sure we always use the best allocation strategy.
> >
> > I have attempt
On Mon, 12 Sept 2022 at 10:16, Jakub Jelinek wrote:
>
> On Wed, Aug 31, 2022 at 11:38:58AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, Aug 10, 2022 at 01:27:51PM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > On Wed, Jul 27, 2022 at 11:33:29AM +0200, Jakub Jelinek via Gcc-patch
This typo has gone unnoticed for 15 years. I had to check whether it
was supposed to say __float128 or _Float128, but based on the commit
that added it, the answer was obviously __float128.
Committed as obvious.
-- >8 --
gcc/ChangeLog:
* doc/extend.texi (Floating Types): Fix "_float128
On Mon, 12 Sept 2022 at 11:55, Daniel Krügler wrote:
>
> 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_co
On Mon, 12 Sep 2022, 17:46 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Although PR106320 only affected the 10 and 11 branches, and the testcase
> from there was already correctly accepted on trunk and the 12 branch, we
> should also add the testcase to 12/trunk for inter-branch
On Mon, 12 Sept 2022 at 18:40, Patrick Palka via Libstdc++
wrote:
>
> I noticed compiling e.g. std/ranges/adaptors/join.cc with
> -D_GLIBCXX_DEBUG -Wsystem-headers -Wall gives the warning:
>
> gcc/libstdc++-v3/include/debug/safe_iterator.h:477:9: warning: suggest
> parentheses around ‘&&’ withi
On Mon, 12 Sept 2022 at 17:46, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
I briefly wondered whether we could just use a union there and provide
the special members to init/copy/destroy it properly, but we already
use in so it's proba
On Sun, 24 Apr 2022 at 16:51, Philipp Fent via Libstdc++
wrote:
>
> Re-using the std::span printer, this now shows the contents of the
> initializer list instead of the pointer and length members.
Nice, I've pushed this to trunk. Thanks!
>
> Signed-off-by: Philipp Fent
> ---
> libstdc++-v3/py
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This change was LWG 3117.
The test is copied from 20_util/function/cons/deduction.cc
libstdc++-v3/ChangeLog:
PR libstdc++/105375
* include/std/future (packaged_task): Add deduction guides.
* testsuite/30_threads/packag
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/ptr_traits.h (__cpp_lib_constexpr_memory): Define
conditionally.
* include/bits/unique_ptr.h (__cpp_lib_constexpr_memory):
Define for C++23.
(default_delete, default
Pushed to wwwdocs.
---
htdocs/gcc-12/changes.html | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 4f904bfd..78b7b05f 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -467,11 +467,13 @@
I was going to push this patch to "fix" our C++20 constexpr string and
vector so they depend on __cpp_constexpr_dynamic_alloc. But then I
realised that Clang supports that since 10.0.0 and I don't think we need
to bother supporting anything older than that for C++20 mode (Clang 9
users can still us
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This DR was approved at the February 2022 plenary.
libstdc++-v3/ChangeLog:
* include/bits/fs_path.h (hash): Define.
* testsuite/27_io/filesystem/path/nonmember/hash_value.cc:
Check std::hash specialization.
---
libstdc
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This DR was approved at the February 2022 plenary.
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_atomic.h (atomic): Add
constructor for constant initialization from nullptr_t.
* testsuite/20_util/shared_ptr/atomic/a
1201 - 1300 of 3694 matches
Mail list logo
