This is a missing piece of the C++20 header.
It would be good to move the code into the compiled library, so that we
don't need in . It could also use spanstream in C++20,
to avoid memory allocations. That can be changed at a later date.
libstdc++-v3/ChangeLog:
* include/std/chrono (__
This partially reverts commit 561078480ffb5adb68577276c6b23e4ee7b39272.
If we avoid all debug mode checks when erasing elements then we fail to
invalidate safe iterators to the removed elements. This reverts the
recent changes in r12-4083 and r12-4233, restoring the debug checking.
libstdc++-v3/C
This adds an inline wrapper for std::terminate that doesn't add the
declaration of std::terminate to namespace std. This allows the
library to terminate without including all of .
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h: Remove unused header.
* include/bits/c++c
The header doesn't need the stream and
streambuf iterators, so don't include the whole of .
libstdc++-v3/ChangeLog:
PR libstdc++/92546
* include/bits/ranges_algobase.h: Replace with a
subset of the headers it includes.
Tested powerpc64le-linux. Committed to trunk.
comm
Add a #error directive to ensure that the definitions are not compiled
as C++17, which would prevent them being emitted.
libstdc++-v3/ChangeLog:
PR libstdc++/98725
* src/c++11/limits.cc: Fail if __cpp_inline_variables is
defined.
Tested powerpc64le-linux. Committed to tru
This is a step towards restoring support for incomplete types in
unordered containers (PR 53339).
We do not need to instantiate the node type to get its value_type
member, because we know that the value type is the first template
parameter. We can deduce that template argument using a custom trait
On 09/10/21 00:59 +0100, Jonathan Wakely wrote:
This is a step towards restoring support for incomplete types in
unordered containers (PR 53339).
We do not need to instantiate the node type to get its value_type
member, because we know that the value type is the first template
parameter. We can
Since r12-435 the _GLIBCXX_USE_INT128 macro is never defined, so all
uses of it in the testsuite are wrong. The tests should be checking
__SIZEOF_INT128__ instead.
Also add some tests for an INT_3 type, which were missing.
Tested powerpc64le-linux. Committed to trunk.
commit 29a9de9b40277af98515
None of these vstring specializations depend on libc support for
wchar_t, so can be enabled unconditionally now that char_traits
is always available.
libstdc++-v3/ChangeLog:
PR libstdc++/98725
* include/ext/rc_string_base.h [!_GLIBCXX_USE_WCHAR_T]
(__rc_string_base): Defin
None of these traits depend on libc support for wchar_t, so they should
be defined unconditionally. The wchar_t type is always defined in C++.
libstdc++-v3/ChangeLog:
PR libstdc++/98725
* include/c_global/cstddef [!_GLIBCXX_USE_WCHAR_T]
(__byte_operand): Define specializat
The wstring and wstring_view typedefs should be enabled even if
isn't supported, because char_traits works
unconditionally. Similarly, the std::hash specializations for wide
strings do not depend on support.
Although the primary template works OK for std::char_traits in
the absence of support,
This fixes a FAIL when --disable-wchar_t is used.
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_filebuf/close/81256.cc: Moved to...
* testsuite/27_io/basic_filebuf/close/wchar_t/81256.cc: ...here.
---
.../testsuite/27_io/basic_filebuf/close/{ => wchar_t}/81256.cc| 0
1 file
These tests fail for a --disable-wchar_t build.
Tested powerpc64le-linux and x86_64-linux, including a --disable-wchar_t
build. Pushed to trunk.
libstdc++-v3/ChangeLog:
* testsuite/22_locale/conversions/buffer/1.cc: Check
_GLIBCXX_USE_WCHAR_T.
* testsuite/22_locale/conver
The wchar_t type is defined unconditionally for C++, so there is no
reason for std::wstring_convert and std::wbuffer_convert to be disabled
when is not usable. It should be possible to use those class
templates with char16_t and char32_t even if wchar_t conversions don't
work.
libstdc++-v3/Change
We don't need to have support in order to delete overloads
for inserting wide characters into narrow streams.
libstdc++-v3/ChangeLog:
PR libstdc++/98725
* include/std/ostream (operator<<(basic_ostream&, wchar_t))
(operator<<(basic_ostream&, const wchar_t*)): Always
Now that std::wstring and other specializations for wchar_t are defined
unconditionally, many checks for _GLIBCXX_USE_WCHAR_T in the testsuite
are unnecessary and can be removed. Tests for iostreams, locales, regex
and filesystem::path still need to be guarded by _GLIBCXX_USE_WCHAR_T
because those
On Fri, 15 Jan 2021, 19:47 Jonathan Wakely, wrote:
>
>
> On Fri, 15 Jan 2021, 16:19 Alexandre Oliva, wrote:
>
>> On Jan 15, 2021, Jonathan Wakely wrote:
>>
>> > On Thu, 14 Jan 2021, 22:22 Alexandre Oliva, wrote:
>> >> ... it is definitely the case that the target currently defines
>> wchar_t,
This enables lightweight checks for the __glibcxx_requires_valid_range
and __glibcxx_requires_string_len macros when _GLIBCXX_ASSERTIONS is
defined. By using __builtin_object_size we can check whether the end of
the range is part of the same object as the start of the range, and
detect problems l
The end() function needs to consider whether the underlying vector is
empty, not whether the match_results object is empty. That's because the
underlying vector will always contain at least three elements for a
match_results object that is "ready". It contains three extra elements
which are stored
This adds some debug assertions to basic_regex. They don't actually
diagnose the error in the PR yet, but I have another patch to make them
more effective.
Also change the __glibcxx_assert(false) consistency checks to include a
string literal that tells the user a bit more about why the process
ab
This test uses std::is_integral to decide whether we are testing an
integral or floating-point type. But that fails for __int128 because
is_integral<__int128> is false in strict modes. By using
numeric_limits::is_integer instead we get the right answer for all types
that have a numeric_limits speci
We know that if __is_contiguous_iterator is true then we have a pointer
or a __normal_iterator that wraps a pointer, so we don't need to use
std::__to_address.
libstdc++-v3/ChangeLog:
* include/bits/regex.h (basic_regex::assign(Iter, Iter)): Avoid
std::__to_address by using poitne
On 08/10/21 12:23 +0100, Jonathan Wakely wrote:
This adds an inline wrapper for std::terminate that doesn't add the
declaration of std::terminate to namespace std. This allows the
library to terminate without including all of .
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h:
On Fri, 20 Aug 2021 at 21:19, Paul Keir wrote:
>
> Hi,
>
> The current compare_three_way implementation makes provision for constant
> evaluation contexts (avoiding reinterpret_cast etc.), but the approach fails
> with Clang; when it compares two const volatile void pointers: "comparison
> betwe
On Mon, 11 Oct 2021 at 20:48, Jonathan Wakely wrote:
>
> On Fri, 20 Aug 2021 at 21:19, Paul Keir wrote:
> >
> > Hi,
> >
> > The current compare_three_way implementation makes provision for constant
> > evaluation contexts (avoiding reinterpret_cast etc.), but the approach
> > fails with Clang; w
This adds deleted overloads so that the errors for invalid uses of
std::advance and std::distance are easier to understand (see for example
PR 102181).
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator_base_funcs.h (__advance): Add
deleted overload to improve diagnostics.
The r12-3022 commit only fixed the case where an array is the last
element of the tuple. This fixes the other cases too. We can just define
the move constructor as defaulted, which does the right thing. Changing
the move constructor to be trivial would be an ABI break, but since the
last base class
Also restore the test for 'a < a' that was removed by r12-2537 because
it is ill-formed. We still want to test operator< for tuple, we just
need to not use std::nullptr_t in that tuple type.
libstdc++-v3/ChangeLog:
* testsuite/20_util/tuple/comparison_operators/overloaded.cc:
Rest
On 11/10/21 20:38 +0100, Jonathan Wakely wrote:
On 08/10/21 12:23 +0100, Jonathan Wakely wrote:
This adds an inline wrapper for std::terminate that doesn't add the
declaration of std::terminate to namespace std. This allows the
library to terminate without including all of .
libstdc++-v3/Change
When creating a path from a pair of non-contiguous iterators we pass the
iterators to _S_convert(Iter, Iter). That function passes the iterators
to __string_from_range to get a contiguous sequence of characters, and
then calls _S_convert(const C*, const C*) to perform the encoding
conversions. If t
Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.
Use std::contiguous_iterator in the __effective_range(const Source&)
overload, to allow returning a basic_string_view
On 13/10/21 20:41 +0100, Jonathan Wakely wrote:
Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.
Use std::contiguous_iterator in the __effective_range(const Source&
libstdc++-v3/ChangeLog:
* testsuite/27_io/filesystem/path/construct/102592.C: Moved to...
* testsuite/27_io/filesystem/path/construct/102592.cc: ...here.
* testsuite/28_regex/match_results/102667.C: Moved to...
* testsuite/28_regex/match_results/102667.cc: ...here.
On 13/10/21 21:19 +0100, Jonathan Wakely wrote:
On 13/10/21 20:41 +0100, Jonathan Wakely wrote:
Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.
Use std::contiguou
libstdc++-v3/ChangeLog:
* testsuite/20_util/is_layout_compatible/version.cc: Check
correct macro.
Tested powerpc64le-linux. Committed to trunk.
commit 6e3bfd60e87303b32bf2284ea4e79078f488bc95
Author: Jonathan Wakely
Date: Thu Oct 14 00:33:49 2021
libstdc++: Fix test for f
This implements the changes in P2231R1 which make std::optional fully
constexpr in C++20.
libstdc++-v3/ChangeLog:
* include/bits/stl_construct.h (_Construct): Use
std::construct_at when constant evaluated.
* include/std/optional (_Storage, _Optional_payload, optional):
On Wed, 13 Oct 2021 at 18:10, François Dumont via Libstdc++
wrote:
>
> Hi
>
> libstdc++: [_GLIBCXX_DEBUG] Implement unordered container merge
>
> The _GLIBCXX_DEBUG unordered containers need a dedicated merge
> implementation
> so that any existing iterator on the transfered nodes i
The out-of-class definitions of the static constants are redundant if
the __cpp_inline_variables feature is supported, so use that macro to
decide whether to define them or not.
libstdc++-v3/ChangeLog:
* include/bits/regex.h: Check __cpp_inline_variables instead of
__cplusplus.
T
On 13/10/21 20:41 +0100, Jonathan Wakely wrote:
Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.
Use std::contiguous_iterator in the __effective_range(const Source&
On Thu, 14 Oct 2021 at 18:11, François Dumont wrote:
>
> Hi
>
> On a related subject I am waiting for some feedback on:
>
> https://gcc.gnu.org/pipermail/libstdc++/2021-August/053005.html
I'm concerned that this adds too much overhead for the
_GLIBCXX_ASSERTIONS case. It adds function calls
Since r12-4065 std::basic_string is always nothrow-move-constructible,
so filesystem::path is too.
That also means that path::_S_convert(T) is noexcept when returning its
argument, because T is either a basci_string or basic_string_view, and
will be moved into the return value.
libstdc++-v3/Chang
libstdc++-v3/ChangeLog:
* include/std/variant (__variant::__get(in_place_index_t, U&&)):
Rename to __get_n and remove first argument. Replace pair of
overloads with a single function using 'if constexpr'.
(__variant::__get(Variant&&)): Adjust to use __get_n.
Tested
On Fri, 15 Oct 2021 at 06:19, François Dumont wrote:
>
> On 14/10/21 7:43 pm, Jonathan Wakely wrote:
> > On Thu, 14 Oct 2021 at 18:11, François Dumont wrote:
> >> Hi
> >>
> >> On a related subject I am waiting for some feedback on:
> >>
> >> https://gcc.gnu.org/pipermail/libstdc++/2021-Augus
These functions aren't used, and accessing the storage as a void* isn't
compatible with C++20 constexpr requirements anyway, so we're unlikely
to ever start using them in future.
libstdc++-v3/ChangeLog:
* include/std/variant (_Variant_storage::_M_storage()): Remove.
(__detail::__v
The __variant_construct_by_index helper function sets the new index
before constructing the new object. This means that if the construction
throws then the exception needs to be caught, so the index can be reset
to variant_npos, and then the exception rethrown. This means callers are
responsible fo
This implements the changes in P2231R1 which make std::variant fully
constexpr in C++20.
We need to replace placement new with std::construct_at, but that isn't
defined for C++17. Use std::_Construct instead, which forwards to
std::construct_at in C++20 mode (since the related changes to make
std:
libstdc++-v3/ChangeLog:
PR libstdc++/101263
* include/std/ranges (__cached): New wrapper struct.
(__non_propagating_cache): Use __cached for contained value.
(__non_propagating_cache::_M_emplace_deref): Add constexpr. Use
std::construct_at instead of placeme
A recently approved change for the C++23 working draft.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (__cpp_lib_string_resize_and_overwrite):
Define for C++23.
(basic_string::resize_and_overwrite): Declare.
* include/bits/basic_string.tcc (basic_string::re
THis fixes teh following error seen with Clang:
error: function '_S_convert>' with deduced
return type cannot be used before it is defined
return string_type(_S_convert(std::u8string_view(__str)));
^
libstdc++-v3/ChangeLog:
* include/bits/fs_path.h
On Sat, 16 Oct 2021, 14:49 François Dumont via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Hi
>
> Here is the new proposal. My only concern is that we are also using
> hash or equal_to functors in the guard destructor.
>
Can we catch any exception there, invalidate all iterators, and not r
libstdc++-v3/ChangeLog:
PR libstdc++/102825
* include/bits/mofunc_impl.h (move_only_function): Remove
invalid base initializer.
* testsuite/20_util/move_only_function/cons.cc: Instantiate
constructors to check bodies.
Tested powerpc64le-linux. Committed to
On Tue, 19 Oct 2021 at 13:18, Patrick Palka via Libstdc++
wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (iota_view::_Iterator): Befriend iota_view.
> (iota_view::_Sentinel): Likewise.
> (iota_view::iota_view): Add three overloads each taking an
> itera
libstdc++-v3/ChangeLog:
* include/bits/stl_stack.h (stack(Iterator, Iterator)): Remove
non-deducible template parameter from deduction guide.
* testsuite/23_containers/stack/deduction.cc: Check new C++23
deduction guides.
Tested powerpc64le-linux. Committed to trun
Another new addition to the C++23 working draft.
The new member functions of std::optional are only defined for C++23,
but the new members of _Optional_payload_base are defined for C++20 so
that they can be used in non-propagating-cache in . The
_Optional_payload_base::_M_construct member can also
This more clearly expresses the intent (a completely unused, trivial
type) than using char. It's also consistent with the unions in
std::optional.
libstdc++-v3/ChangeLog:
* include/std/variant (_Uninitialized): Use an empty struct
for the unused union member, instead of char.
Tes
In r12-826 I tried to remove some redundant steps from the doxygen
build, but they are needed when configure is run as a relative path. The
use of pwd is to resolve the relative path to an absolute one.
libstdc++-v3/ChangeLog:
* doc/Makefile.am (stamp-html-doxygen, stamp-html-doxygen)
Currently this function only returns a non-zero value for /dev/random
and /dev/urandom. When a hardware instruction such as RDRAND is in use
it should (in theory) be perfectly random and produce 32 bits of entropy
in each 32-bit result. Add a helper function to identify the source of
randomness fro
The ISA-3.0 instruction set includes DARN ("deliver a random number")
which can be used similar to the existing support for RDRAND and RDSEED.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (USE_DARN): Define.
(__ppc_darn): New function to use POWER9 DARN instruction.
(Whic
On Tue, 19 Oct 2021, 19:33 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
>
Yes, thanks.
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (iota_view::operator+): Adjust definition
> as p
On Tue, 19 Oct 2021, 19:31 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
Yes, thanks.
(The branches don't have P2325R3.)
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (basic_istream_view::_M_object): V
On Tue, 19 Oct 2021, 19:30 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
>
Yes, thanks.
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_util.h
> (__detail::__uses_nonqualification_point
gcc/ChangeLog:
* doc/extend.texi (Basic PowerPC Built-in Functions): Fix typo.
Committed as obvious.
commit c6a1fdd6dde3a95997731c8339d70970aca67594
Author: Jonathan Wakely
Date: Tue Oct 19 20:37:53 2021
doc: Fix typo in name of PowerPC __builtin_cpu_supports built-in
On Tue, 19 Oct 2021 at 15:35, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This patch also reverts the r11-3504 workaround since it's made obsolete
> by this resolution.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
>
OK, thanks.
> libstdc++-v3/ChangeLog:
On Wed, 20 Oct 2021 at 06:48, Tim Song wrote:
>
> On Tue, Oct 19, 2021 at 9:05 AM Jonathan Wakely via Gcc-patches
> wrote:
> >
> > +constexpr bool
> > +test_copy_elision()
> > +{
> > + return true;
> > +}
> > +
> > +static_assert( t
On 19/10/21 17:47 +0100, Jonathan Wakely wrote:
The ISA-3.0 instruction set includes DARN ("deliver a random number")
which can be used similar to the existing support for RDRAND and RDSEED.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (USE_DARN): Define.
(__ppc_darn): New func
The documentation on asm statements suggests asm is always a GNU
extension, but it's been part of ISO C++ since the first standard.
The documentation of -fno-asm is wrong for C++ as it states that it only
affects typeof, but actually it affects typeof and asm (despite asm
being part of ISO C++).
On 20/10/21 10:12 +0100, Jonathan Wakely wrote:
On 19/10/21 17:47 +0100, Jonathan Wakely wrote:
The ISA-3.0 instruction set includes DARN ("deliver a random number")
which can be used similar to the existing support for RDRAND and RDSEED.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (
On Wed, 20 Oct 2021 at 18:10, Martin Liška wrote:
> On 10/20/21 18:59, Jonathan Wakely via Gcc wrote:
> > On Wed, 20 Oct 2021 at 17:40, Joseph Myers wrote:
> >
> >> On Wed, 20 Oct 2021, Jonathan Wakely via Gcc wrote:
> >>
> >>> https://gcc.gnu.org/install/ says:
> >>>
> >>> "There are also some ol
On Wed, 20 Oct 2021 at 19:17, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and 11 after
> a while?
Yes for both, thanks.
On Wed, 20 Oct 2021 at 18:44, Jeff Law wrote:
> On 10/20/2021 6:28 AM, Jonathan Wakely via Gcc-patches wrote:
> > The documentation on asm statements suggests asm is always a GNU
> > extension, but it's been part of ISO C++ since the first standard.
> >
> > The do
On Wed, 20 Oct 2021 at 18:01, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and branches
> after a while?
Yes for all.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_base.h (viewable_range): Adjust as per
> LWG 3481.
> * testsu
On Wed, 20 Oct 2021 at 18:03, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and branches
> after a while?
Yes for all.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (join_view::__iter_cat::_S_iter_cat): Adjust
> criteri
On Wed, 20 Oct 2021 at 18:04, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
I thought I'd already done this one, maybe I have it in a local Git stash.
OK for all branches, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include
On Wed, 20 Oct 2021 at 09:42, Jonathan Wakely wrote:
>
> On Wed, 20 Oct 2021 at 06:48, Tim Song wrote:
> >
> > On Tue, Oct 19, 2021 at 9:05 AM Jonathan Wakely via Gcc-patches
> > wrote:
> > >
> > > +constexpr bool
> > >
The constraints on transform and and_then can cause errors when checking
satisfaction. The constraints that were present in R6 of the paper were
moved for he final F8 revision, and so should have been included in the
implementation.
libstdc++-v3/ChangeLog:
PR libstdc++/102863
* in
On 21/10/21 01:23 +0100, Jonathan Wakely wrote:
The constraints on transform and and_then can cause errors when checking
satisfaction. The constraints that were present in R6 of the paper were
moved for he final F8 revision, and so should have been included in the
Bah, I meant "removed for the
If the listen call fails then 'goto fail' will jump to that label and
use freeaddrinfo again. Set the pointer to null to prevent that.
libcody/ChangeLog:
* netserver.cc (ListenInet6): Set pointer to null after
deallocation.
---
libcody/netserver.cc | 1 +
1 file changed, 1 insert
The allocated memory is not freed when returning early due to an error.
c++tools/ChangeLog:
* resolver.cc (module_resolver::read_tuple_file): Use unique_ptr
to ensure memory is freed before returning.
---
c++tools/resolver.cc | 14 --
1 file changed, 8 insertions(+),
Oops, this patch and the next one were only meant for gcc-patches, not the
libstdc++ list as well - sorry!
On Thu, 21 Oct 2021 at 14:27, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> If the listen call fails then 'goto fail' will jump to that label and
> use freeaddrinfo again.
On Thu, 21 Oct 2021 at 15:38, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look ok for trunk/11/10?
>
Yes to all, thanks.
> PR libstdc++/102358
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_iterator.h (__niter_base)
On Thu, 21 Oct 2021 at 15:41, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11/10?
>
Yes for trunk.
I'm undecided whether we want to make this breaking change on the branches.
> libstdc++-v3/ChangeLog:
>
> * in
On Tue, 19 Oct 2021 at 13:20, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This implements P1739R4 along with the resolution for LWG 3407 which
> corrects the paper's wording.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
Yes, thanks.
> libstdc++-v3/ChangeL
On Thu, 21 Oct 2021 at 17:52, François Dumont wrote:
> I eventually would like to propose a different approach.
>
> I am adding a hook in normal implementation to let the _GLIBCXX_DEBUG code
> know when a node is being extracted. This way invalidation is only done by
> comparing nodes, no need to
On Thu, 21 Oct 2021 at 20:38, Jason Merrill wrote:
> On 10/21/21 09:28, Jonathan Wakely wrote:
> > #else
> > buffer = xmalloc (stat.st_size);
> > if (!buffer)
> > return -errno;
> > + struct Deleter { void operator()(void* p) const { free(p); } };
> > + std::unique_ptr guard;
>
>
I messed up the CC to gcc-patches for this ...
-- Forwarded message -
From: Jonathan Wakely via Libstdc++
Date: Thu, 21 Oct 2021 at 22:56
Subject: [committed] libstdc++: Suppress Doxygen docs for more
implementation details
To: ,
Tested x86_64-linux, committed to trunk.
libstd
I messed up the CC to gcc-patches for this ...
-- Forwarded message -
From: Jonathan Wakely via Libstdc++
Date: Thu, 21 Oct 2021 at 22:57
Subject: [committed] libstdc++: Add Doxygen comments to contents of
To: ,
Tested x86_64-linux, committed to trunk.
libstdc++-v3/ChangeLog:
I messed up the CC to gcc-patches for this.
And I forgot to mention in the commit msg that the reason I started looking
at stdheader.cc in the first place was to fix a use-after-free bug in the
old code:
-// come on, gdb, find `p' already...
-const char* p = longheader.substr(start).c_str
std::make_any should be constrained so it can only be called if the
construction of the return value would be valid.
Tested x86_64-linux, committed to trunk.
I plan to backport this too.
libstdc++-v3/ChangeLog:
PR libstdc++/102894
* include/std/any (make_any): Add SFINAE const
On Fri, 22 Oct 2021, 23:28 Gerald Pfeifer, wrote:
> It turns out my link checker does catch broken links under
> gcc.gnu.org/install/ - fixed thusly.
>
> (That makes it all the more puzzling how the issue you fixed last
> week did not arise, Jonathan.)
>
It didn't give a 404, there was a page at
On Sat, 23 Oct 2021, 00:43 Jonathan Wakely, wrote:
>
>
> On Fri, 22 Oct 2021, 23:28 Gerald Pfeifer, wrote:
>
>> It turns out my link checker does catch broken links under
>> gcc.gnu.org/install/ - fixed thusly.
>>
>> (That makes it all the more puzzling how the issue you fixed last
>> week did n
On Mon, 25 Oct 2021 at 12:55, Rainer Orth wrote:
>
> 17_intro/names.cc and experimental/names.cc currently FAIL on Solaris
>
> FAIL: 17_intro/names.cc (test for excess errors)
> FAIL: experimental/names.cc (test for excess errors)
>
> Excess errors:
> /usr/include/sys/timespec_util.h:22: error: ex
On Mon, 25 Oct 2021 at 13:09, Rainer Orth wrote:
>
> 28_regex/basic_regex/84110.cc currently FAILs on Solaris:
>
> FAIL: 28_regex/basic_regex/84110.cc (test for excess errors)
> UNRESOLVED: 28_regex/basic_regex/84110.cc compilation failed to produce
> executable
>
> Excess errors:
> /vol/gcc/src/h
On Tue, 26 Oct 2021 at 14:36, Jakub Jelinek wrote:
> On Tue, Oct 26, 2021 at 03:21:55PM +0200, Richard Biener wrote:
> > On Tue, 26 Oct 2021, Jakub Jelinek wrote:
> >
> > > On Tue, Oct 26, 2021 at 03:13:29PM +0200, Richard Biener wrote:
> > > > try
> > > > auto c = ...;
> > > > signed char c2
On Tue, 26 Oct 2021 at 20:40, Jakub Jelinek wrote:
> On Tue, Oct 26, 2021 at 08:35:40PM +0100, Jonathan Wakely wrote:
> > We can change __cmp_cat::type if that would result in better code. I
> picked
> > signed char because we only need two bits, and preferably have a signed
> > type as it simplif
On Mon, 12 Jul 2021 at 14:41, Eli Zaretskii via Gcc wrote:
>
> > Cc: g...@gcc.gnu.org, gcc-patches@gcc.gnu.org, jos...@codesourcery.com
> > From: Martin Liška
> > Date: Mon, 12 Jul 2021 15:25:47 +0200
> >
> > Let's make it a separate sub-thread where we can discuss motivation why
> > do I want mo
On Mon, 12 Jul 2021 at 14:53, Jonathan Wakely wrote:
> For me, these items are enough justification to switch away from
> texinfo, which produces crap HTML pages with crap anchors. You can't
> find out the anchors without inspecting (and searching) the HTML
> source. That's utterly stupid. And even
On Mon, 12 Jul 2021 at 15:13, Eli Zaretskii wrote:
>
> > From: Jonathan Wakely
> > Date: Mon, 12 Jul 2021 14:53:44 +0100
> > Cc: Martin Liška ,
> > "g...@gcc.gnu.org" , gcc-patches
> > ,
> > "Joseph S. Myers"
> >
> > For me, these items are enough justification to switch away from
>
On Mon, 12 Jul 2021 at 15:52, Jonathan Wakely wrote:
>
> On Mon, 12 Jul 2021 at 15:13, Eli Zaretskii wrote:
> >
> > > From: Jonathan Wakely
> > > This is a problem with texinfo too.
> >
> > Not for someone who already knows Texinfo. We are talking about
> > switching away of it, so I'm thinking
On Mon, 12 Jul 2021 at 15:52, Jonathan Wakely wrote:
>
> On Mon, 12 Jul 2021 at 15:13, Eli Zaretskii wrote:
> > I get it that you dislike the HTML produced by Texinfo, but without
> > some examples of such bad HTML it is impossible to know what exactly
> > do you dislike and why.
> >
> > > You ca
On Mon, 12 Jul 2021 at 17:01, Gavin Smith wrote:
>
> On Mon, Jul 12, 2021 at 4:04 PM Jonathan Wakely via Gcc
> wrote:
> > GNU Hello has the same problem with its docs:
> > https://www.gnu.org/software/hello/manual/hello.html#index-_002dg
> > That URL is garbage because of the URL-encoded %2d char
1701 - 1800 of 3694 matches
Mail list logo
