On Mon, 27 Sept 2021 at 15:11, Thomas Rodgers wrote:
>
> From: Thomas Rodgers
>
> Now with checks for __has_builtin(__builtin_clear_padding)
>
> This change implements P0528 which requires that padding bits not
> participate in atomic compare exchange operations. All arguments to the
> generic te
On Wed, 29 Sept 2021 at 13:13, Jonathan Wakely wrote:
> We repeat this *a lot*. When I started work on this I defined a
> non-member function in the __atomic_impl namespace:
I've attached my incomplete patch from when I was working on this.
diff --cc libstdc++-v3/include/bits/atomic_base.h
index 7
Introduce a new _M_compile function which does the common work needed by
all constructors and assignment. Call that directly to avoid multiple
levels of constructor delegation or calls to basic_regex::assign
overloads.
For assignment, there is no need to construct a std::basic_string if we
already
When the input sequence contains a _CharT(0) character, the strchr call
in _Scanner<_CharT>::_M_scan_normal() will search for '\0' and so return
a pointer to the terminating null at the end of the string. This makes
the scanner think it's found a special character. Because it doesn't
match any of t
The standard says that it is invalid for more than one grammar element
to be set in a value of type regex_constants::syntax_option_type. This
adds a check in the regex compiler andthrows an exception if an invalid
value is used.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* i
This implements LWG 2503, which allows ^ and $ to match line terminator
characters, rather than only matching the beginning and end of the
entire input. The multiline option is only valid for ECMAScript, but
for other grammars we ignore it rather than throwing an exception.
This is related to PR l
ChangeLog:
* MAINTAINERS: Add myself to DCO section.
Committed to trunk.
commit cd5448f6c534c0d386f6b561ab903ffd5d3884b2
Author: Jonathan Wakely
Date: Wed Sep 29 21:00:30 2021
MAINTAINERS: Add myself to DCO section
ChangeLog:
* MAINTAINERS: Add myself to
Tested x86_64-linux, committed to trunk.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/stack/deduction.cc: Fix typo.
---
libstdc++-v3/testsuite/23_containers/stack/deduction.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/23_containers/st
Tested powerpc64le-linux, pushed to trunk.
The std::begin and std::end overloads for std::valarray are defined in
terms of std::addressof(v[0]) which is undefined for an empty valarray.
libstdc++-v3/ChangeLog:
PR libstdc++/103022
* include/std/valarray (begin, end): Do not deref
Tested powerpc64le-linux, pushed to trunk.
In PR libstdc++/103013 Tim Song pointed out that we could reorder the
constraints of this constructor. That's worth doing just to reduce the
work the compiler has to do during overload resolution, even if it isn't
needed to make the code in the PR work.
Tested powerpc64le-linux, pushed to trunk.
The new 25_algorithms/move/constexpr.cc test fails in debug mode,
because the debug assertions use the non-constexpr overloads in
.
libstdc++-v3/ChangeLog:
* include/debug/stl_iterator.h (__valid_range): Add constexpr
for C++20. Qualify
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* include/std/valarray (valarray::valarray()): Add noexcept.
(valarray::operator[]): Likewise.
---
libstdc++-v3/include/std/valarray | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib
These functions have been deprecated since C++11, and were removed in
C++17. The proposal P0323 wants to reuse the name std::unexpected for a
class template, so we will need to stop defining the current function
for C++23 anyway.
This marks them as deprecated for C++11 and up, to warn users they w
Any feedback from POWER maintainers about this? I'd like to push it soon if
there's nothing wrong with it.
On Wed, 20 Oct 2021 at 14:00, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> On 20/10/21 10:12 +0100, Jonathan Wakely wrote:
> >On 19/10/21 17:47 +0100, Jonathan Wakely wrot
On Wed, 3 Nov 2021 at 15:01, Jonathan Wakely wrote:
> Any feedback from POWER maintainers about this? I'd like to push it soon
> if there's nothing wrong with it.
>
With the updated patch attached again this time ...
> On Wed, 20 Oct 2021 at 14:00, Jonathan Wakely via Libstdc++ <
> libstd...@g
The standard does not require const-correct comparisons in list::sort.
Tested powerpc64le-linux, committed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/66742
* include/bits/list.tcc (list::sort): Use mutable iterators for
comparisons.
* include/bits/stl_list.h
Tested powerpc64le-linux, pushed to trunk.
Prior to r12-4447 (implementing P2231R1 constexpr changes) we didn't
construct the correct member of the union in __variant_construct_single,
we just plopped an object in the memory occupied by the union:
void* __storage = std::addressof(__lhs._M_u);
Tested powerpc64le-linux, pushed to trunk.
By defining additional partial specializations of _Nth_type we can
reduce the number of recursive instantiations needed to get from N to 0.
We can also use _Nth_type in variant_alternative, to take advantage of
that new optimization.
By adding a static_
Tested powerpc64le-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* include/std/variant (__detail::__variant::__emplace): New
function template.
(_Copy_assign_base::operator=): Reorder conditions to match
bulleted list of effects in the standard. Use __emplace in
On Wed, 27 Oct 2021 at 09:27, Jay Feldblum via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> From: yfeldblum
>
> The stdout stream is reserved for output intentionally produced by the
> application. Assertion failures and other forms of logging must be
> emitted to stderr, not to stdout.
>
> It is
On Thu, 4 Nov 2021 at 12:42, Richard Biener via Gcc wrote:
>
> On Thu, Nov 4, 2021 at 12:57 PM Segher Boessenkool
> wrote:
> >
> > On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches
> > wrote:
> > > On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> > > Gcc-patc
Tested powerpc64le-linux, committed to trunk.
This reduces the number of class template instantiations needed for code
using tuples, by reusing _Nth_type in tuple_element and specializing
tuple_size_v for tuple, pair and array (and const-qualified versions of
them).
Also define the _Nth_type pri
Tested powerpc64le-linux, committed to trunk.
Currently std::variant uses __index_of to find the first
occurence of a type in a pack, and __exactly_once to check
that there is no other occurrence.
We can reuse the __find_uniq_type_in_pack() function for
both tasks, and remove the recursive templ
On Wed, 3 Nov 2021 at 00:20, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> These functions have been deprecated since C++11, and were removed in
> C++17. The proposal P0323 wants to reuse the name std::unexpected for a
> class template, so we will need to stop defining the curren
Tested x86_64-linux, committed to trunk. Backport to gcc-11 to follow,
and maybe to other branches too.
Since std::tuple started using [[no_unique_address]] the tuple
member of std::unique_ptr has two _M_head_impl subobjects, in
different base classes. That means this printer code is ambiguous:
On Thu, 4 Nov 2021 at 11:30, Jonathan Wakely wrote:
>
>
> On Wed, 27 Oct 2021 at 09:27, Jay Feldblum via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> From: yfeldblum
>>
>> The stdout stream is reserved for output intentionally produced by the
>> application. Assertion failures and other form
On Fri, 5 Nov 2021 at 09:35, Richard Biener via Gcc wrote:
> So just contribute updated dejagnu packages to CentOS 7 "backports" or
> whatever means exists there?
Yes, we could add a newer dejagnu to EPEL.
Tested x86-linux, in C++17 and C++20 modes, with GDB 10 and GDB 12.
Pushed to trunk.
For some reason the type printer for std::string doesn't work in C++20
mode, so std::basic_string, allocator is
printed out in full rather than being shown as std::string. It's
probably related to the fact that t
On Thu, 4 Nov 2021 at 20:44, Bill Schmidt wrote:
> For posterity: This was discussed briefly on IRC, and Segher approved
> with some
> simplifications and a request to implement a fail/retry check.
>
>
Here's what I have now. No more assembler check in configure, and it uses
the 64-bit __builtin_
On Fri, 5 Nov 2021 at 13:20, Bill Schmidt wrote:
>
> On 11/5/21 7:44 AM, Jonathan Wakely wrote:
> > On Thu, 4 Nov 2021 at 20:44, Bill Schmidt wrote: For posterity: This
> was discussed briefly on IRC, and Segher approved with some simplifications
> and a request to implement a fail/retry check. H
Tested x86+64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (__x86_rdrand, __x86_rdseed): Add
[[unlikely]] attribute.
---
libstdc++-v3/src/c++11/random.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/src/c++11/rando
This adds additional "getentropy" and "arc4random" tokens to
std::random_device. The former is supported on Glibc and OpenBSD (and
apparently wasm), and the latter is supported on various BSDs.
I'm trying to test this on OpenBSD but I can't bootstrap GCC using the
system clang.
libstdc++-v3/Chan
Oops sorry - this is NOT committed yet. I won't push it until I've tested
it on at least one BSD, preferably OpenBSD so I can test parts of the new
code.
On Fri, 5 Nov 2021 at 18:21, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This adds additional "getentropy" and "arc4random
On Fri, 5 Nov 2021 at 21:19, Patrick Palka wrote:
> On Thu, Nov 4, 2021 at 2:34 PM Jonathan Wakely via Libstdc++
> wrote:
> >
> > Tested powerpc64le-linux, committed to trunk.
> >
> >
> > This reduces the number of class template instantiations needed for code
> > using tuples, by reusing _Nth_t
On Mon, 1 Nov 2021 at 13:27, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested powerpc64le-linux, pushed to trunk.
>
>
> The std::begin and std::end overloads for std::valarray are defined in
> terms of std::addressof(v[0]) which is undefined for an empty valarray.
>
> libstdc
OK, thanks.
On Fri, 5 Nov 2021 at 21:46, Thomas Rodgers via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
>
>
On Thu, 4 Nov 2021 at 21:04, Iain Sandoe wrote:
> Well, I did try to CC it to this list ..
>
> > Begin forwarded message:
> >
> > From: Iain Sandoe via Gcc-patches
> > Subject: [PATCH 2/4] libstdc++: Adjust build of PCH files accounting
> configured host support.
> > Date: 4 November 2021 at 20:0
On Fri, 5 Nov 2021 at 21:51, Jonathan Wakely via Libstdc++
wrote:
>
> OK, thanks.
Actually, we should really have a test to verify it can be called on a
const object. Please add something when you commit, it can be dumb and
simple, it just needs to verify that it can be called.
>
>
> On Fri, 5
OK for wwwdocs?
---
htdocs/projects/cxx-status.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 0ff9e94d..d2d6eab4 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@
Tested x86_64-linux, committed to trunk.
It's possible that independent reads from /dev/random and /dev/urandom
could produce the same value by chance. Retry if that happens. The
chances of it happening twice are miniscule.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/random_d
Tested x86_64-linux, and Iain Sandoe tested the arc4random code on
darwin too. Pushed to trunk.
This adds additional "getentropy" and "arc4random" tokens to
std::random_device. The former is supported on Glibc and OpenBSD (and
apparently wasm), and the latter is supported on various BSDs.
libstd
On Thu, 25 Mar 2021 at 11:38, Jonathan Wakely wrote:
> On 25/03/21 08:00 -0300, Alexandre Oliva wrote:
> >On Mar 24, 2021, Jonathan Wakely wrote:
> >
> >> Does vxworks provide any platform-specific source of randomness, like
> >> Linux getrandom(2) or BSD arc4random(3) or Windows rand_s? If yes,
Tested powerpc64le-linux, pushed to trunk.
We need to use the 64-bit DARN to detect failure without bias, but it's
not available in 32-bit mode.
libstdc++-v3/ChangeLog:
PR libstdc++/103146
* src/c++11/random.cc: Check __powerpc64__ not __powerpc__.
---
libstdc++-v3/src/c++11/ra
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/random_device/cons/token.cc:
Print results of random_device_available checks.
---
.../26_numerics/random/random_device/cons/token.cc | 7 +++
1 file changed, 7 insertions(+)
On Fri, 5 Nov 2021 at 18:22, Jonathan Wakely wrote:
> Oops sorry - this is NOT committed yet. I won't push it until I've tested
> it on at least one BSD, preferably OpenBSD so I can test parts of the new
> code.
>
It got tested on darwin, and has been pushed to trunk now.
>
>
> On Fri, 5 Nov 2
On Mon, 8 Nov 2021 at 21:36, François Dumont wrote:
> Yet another version this time with only 1 guard implementation. The
> predicate to invalidate the safe iterators has been externalized.
>
> Ok to commit ?
>
I like this version a lot - thanks for persisting with it.
OK to commit, thanks.
A
Now that GCC is compiled as C++11 there is no need to keep the C++03
implementation of gnu::unique_ptr.
This removes the unique-ptr.h header and replaces it with in
system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY.
Uses of gnu::unique_ptr and gnu::move can be replaced with
std
On Tue, 9 Nov 2021 at 18:09, Thomas Rodgers wrote:
> Revised patch attached.
>
OK for trunk and gcc-11, thanks.
> On Fri, Nov 5, 2021 at 4:46 PM Jonathan Wakely
> wrote:
>
>> On Fri, 5 Nov 2021 at 21:51, Jonathan Wakely via Libstdc++
>> wrote:
>> >
>> > OK, thanks.
>>
>> Actually, we should
On Wed, 10 Nov 2021, 05:45 François Dumont, wrote:
> I can't see any clue on how my commit can have had an impact on below code.
>
Agreed.
> I don't think libstdc++ hash table has any relation with gcc hash table.
>
Correct, it's totally unrelated. And "section type conflict" can't be
caused
On Wed, 10 Nov 2021 at 05:47, François Dumont wrote:
> On 09/11/21 5:25 pm, Jonathan Wakely wrote:
>
>
>
> On Mon, 8 Nov 2021 at 21:36, François Dumont wrote:
>
>> Yet another version this time with only 1 guard implementation. The
>> predicate to invalidate the safe iterators has been externali
On Tue, 9 Nov 2021 at 16:25, Jonathan Wakely wrote:
>
>
> On Mon, 8 Nov 2021 at 21:36, François Dumont wrote:
>
>> Yet another version this time with only 1 guard implementation. The
>> predicate to invalidate the safe iterators has been externalized.
>>
>> Ok to commit ?
>>
>
> I like this vers
Tested powerpc64le-linux, glibc 2.17 and 2.34, pushed to trunk.
We also want something like this for musl-based targets. And Florian has
suggested we should also disable the weak symbols for libstdc++.a, but
those need more work.
...
Since Glibc 2.34 all pthreads symbols are defined directly in
Tested powerpc64le-linux, pushed to trunk.
The headers for the C library are not under our control, so we
can't prevent them from including . Change the PR 49745 test
to only include the C++ library headers, not the ones.
To ensure isn't included automatically we need to use
no_pch to disable
Tested x86_64-linux, pushed to trunk.
This function only exists to avoid an error in the debug mode vector, so
doesn't need to be public.
libstdc++-v3/ChangeLog:
* include/bits/stl_bvector.h (vector::data()): Give
protected access, and delete for C++11 and later.
---
libstdc++-
Tested x86_64-linux, pushed to trunk.
Calling the placement version of ::operator new "implicitly creates
objects in the returned region of storage" as per [intro.object]. This
allows the returned memory to be used as storage for implicit-lifetime
types (including arrays) without additional actio
On Wed, 10 Nov 2021 at 11:55, Jonathan Wakely wrote:
>
>
> On Tue, 9 Nov 2021 at 16:25, Jonathan Wakely wrote:
>
>>
>>
>> On Mon, 8 Nov 2021 at 21:36, François Dumont
>> wrote:
>>
>>> Yet another version this time with only 1 guard implementation. The
>>> predicate to invalidate the safe iterat
On Thu, 11 Nov 2021 at 21:33, François Dumont wrote:
> On 11/11/21 9:41 pm, Jonathan Wakely wrote:
>
>
>
> On Wed, 10 Nov 2021 at 11:55, Jonathan Wakely wrote:
>
>>
>>
>> On Tue, 9 Nov 2021 at 16:25, Jonathan Wakely wrote:
>>
>>>
>>>
>>> On Mon, 8 Nov 2021 at 21:36, François Dumont
>>> wrote:
Pushed to wwwdocs.
---
htdocs/gcc-12/changes.html | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 19947f90..5f12fb42 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@
This replaces the printf used by failed debug assertions with fprintf,
so we can write to stderr.
To avoid including the assert function is moved into the
library. To avoid programs using a vague linkage definition of the old
inline function, the function is renamed. Code compiled with old
versio
On Fri, 12 Nov 2021, 20:24 Hans-Peter Nilsson via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Since r12-5056-g3439657b0286, there has been a regression in
> test results; an additional 100 FAILs running the g++ and
> libstdc++ testsuite on cris-elf, a newlib target. The
> failures are linker err
The tests are just the two small examples from the proposal, so more
tests are definitely needed. They can wait for stage 3 though. Tested
powerpc64le-linux, pushed to trunk.
This implements the header, as proposed for C++23 by P0448R4.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Ad
On Sat, 13 Nov 2021 at 13:19, François Dumont via Libstdc++
wrote:
>
> libstdc++: [_GLIBCXX_DEBUG] Remove _Safe_container<>::_M_safe()
>
> Container code cleanup to get rid of _Safe_container<>::_M_safe()
> and just
> _Safe:: calls which use normal inheritance. Also remove several
>
Not committed yet ...
This feature is present in the C++23 draft. The ARM EABI requires that
the type_info::operator== function can be defined out-of-line (and
suggests that should be the default). With this patch, we fail to
conform to that in C++23 mode. I think we might want to move the logic
On Sun, 14 Nov 2021 at 13:31, François Dumont via Libstdc++
wrote:
>
> libstdc++: Unordered containers merge re-use hash code.
>
> When merging between 2 unordered containers with same hasher we can
> re-use
> the cached hash code if any.
Instead of introducing the _ReuseOrComputeH
On Mon, 15 Nov 2021 at 06:00, François Dumont wrote:
>
> On 15/11/21 12:25 am, Jonathan Wakely wrote:
> > On Sun, 14 Nov 2021 at 13:31, François Dumont via Libstdc++
> > wrote:
> >> libstdc++: Unordered containers merge re-use hash code.
> >>
> >> When merging between 2 unordered conta
Add the header and a new libstdc++_libbacktrace.a library
that provides the implementation. For now, the new library is only built
if --enable-libstdcxx-backtrace=yes is used. As with the Filesystem TS,
the new library is only provided as a static archive.
This should be improved during stage 3.
On Tue, 16 Nov 2021 at 08:01, Florian Weimer wrote:
>
> * Patrick Palka via Libstdc:
>
> > This copies the fast_float library[1] into the compiled-in library
> > sources. We're going to use this library in our floating-point
> > std::from_chars implementation for faster and more portable parsing o
On Tue, 16 Nov 2021 at 00:36, Patrick Palka wrote:
>
> The only source change is a speedup to pow5Factor.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
On Tue, 16 Nov 2021 at 09:46, Florian Weimer via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> * Jonathan Wakely:
>
> > On Tue, 16 Nov 2021 at 08:01, Florian Weimer wrote:
> >>
> >> * Patrick Palka via Libstdc:
> >>
> >> > This copies the fast_float library[1] into the compiled-in library
> >> > sou
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string/allocator/71964.cc: Fix
typo.
* testsuite/23_containers/set/allocator/71964.cc: Likewise.
---
.../testsuite/21_strings/basic_string/allocator/71964.cc| 2 +-
libstdc
Tested x86_64-linux, pushed to trunk.
I fixed some undefined behaviour in string tests in r238609, but I only
fixed the narrow char versions. This applies the same fixes to the
wchar_t ones. These problems were found when testing a patch to make
std::basic_string usable in constexpr.
libstdc++-v
Tested x86_64-linux, committed to trunk.
These swap overloads are non-standard, but are needed to make swap work
for vector::reference rvalues. They don't need to be called
explicitly, only via ADL, so hide them from normal lookup. This is what
I've proposed as the resolution to LWG 3638.
libstdc
From: Michael de Lang
Tested x86_64-linux, committed to trunk.
This is only supported for the cxx11 ABI, not for COW strings.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (basic_string, operator""s): Add
constexpr for C++20.
(basic_string::basic_string(basic_s
Oops, the subject line was not supposed to say 2/2 for this commit, and I
was not supposed to have Michael de Lang as the author ... I messed up my
git send-email and git cherry-pick commands!
Sorry Michael, I originally tried to use your tests from
https://github.com/Oipo/gcc/ but as noted in htt
Tested powerpc64le-linux, pushed to trunk.
Some tests fail when run with -D_GLIBCXX_USE_CXX11_ABI or -stdgnu++20.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (operator<=>): Use constexpr
unconditionally.
* testsuite/21_strings/basic_string/modifiers/constexpr.c
This macro has been obsolete for years, and C++0x features are no longer
experimental or liable to be removed.
gcc/ChangeLog:
* doc/cpp.texi (Common Predefined Macros): Update documentation
for the __GXX_EXPERIMENTAL_CXX0X__ macro.
OK for trunk and release branches?
commit 6704
On 18/05/21 13:58 +0200, Bernd Edlinger wrote:
On 5/18/21 1:55 PM, Bernd Edlinger wrote:
On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
libstdc++-v3/ChangeLog:
* include/std/thread (jthread::_S_create): Fix static assert
message.
* testsuite/30_threads
This adds new warning flags, enabled by default: -Wc++11-extensions,
-Wc++14-extensions, -Wc++17-extensions, and -Wc++20-extensions. The
names of the flags are copied from Clang, which already has similar
options.
No new diagnostics are added, but the new OPT_Wxxx variables are used to
control exi
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for trunk?
commit a7dc19cdc0c5d3762bb90d12ebd82a05d0013246
Author: Jonathan Wakely
Date: Wed May 19 17:37:00 2021
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for trunk?
Jakub also pointed out we already have some similar diagno
On 19/05/21 12:40 -0400, Eric Gallager wrote:
Thank you for doing this! One thing I'm wondering about, is that I'm
pretty sure clang also allows at least some of these to be used with
plain C as well, for example for things like the old use of "auto" in
C conflicting with the newer C++11 meaning
On 19/05/21 17:50 +0100, Jonathan Wakely wrote:
On 19/05/21 12:40 -0400, Eric Gallager wrote:
Thank you for doing this! One thing I'm wondering about, is that I'm
pretty sure clang also allows at least some of these to be used with
plain C as well, for example for things like the old use of "aut
On 19/05/21 12:53 -0400, Marek Polacek wrote:
On Wed, May 19, 2021 at 05:39:24PM +0100, Jonathan Wakely via Gcc-patches wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x
On 19/05/21 14:03 -0400, Marek Polacek wrote:
On Wed, May 19, 2021 at 11:51:54AM -0600, Martin Sebor via Gcc-patches wrote:
On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
> Jakub pointed out I'd forgotten the spaces before the opening parens
> for function calls. The att
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tes
On 19/05/21 20:55 +0100, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch
On 19/05/21 16:08 -0400, Jason Merrill wrote:
On 5/19/21 4:05 PM, Jonathan Wakely wrote:
On 19/05/21 20:55 +0100, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out
On 19/05/21 11:51 -0600, Martin Sebor wrote:
On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for
On 19/05/21 11:51 -0600, Martin Sebor wrote:
On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for
Also add dg-shouldfail to ignore failures due to ulimit.
gcc/testsuite/ChangeLog:
PR testsuite/100655
* g++.dg/tsan/pthread_cond_clockwait.C: Use libstdc++ macro to
check for availability of pthread_cond_clockwait. Add
dg-shouldfail.
Tested x86_64-linux (glibc 2.2
On 19/05/21 16:05 -0400, Jason Merrill wrote:
On 5/19/21 3:55 PM, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out I'd forgotten the spaces before the opening pare
On 20/05/21 13:50 +0100, Jonathan Wakely wrote:
Also add dg-shouldfail to ignore failures due to ulimit.
gcc/testsuite/ChangeLog:
PR testsuite/100655
* g++.dg/tsan/pthread_cond_clockwait.C: Use libstdc++ macro to
check for availability of pthread_cond_clockwait. Add
On 18/05/21 15:52 -0400, Patrick Palka via Libstdc++ wrote:
This implements the P0896 changes to reverse_view's member types
value_type, difference_type and reference in C++20 mode, which fixes
problems taking the reverse_iterator of an iterator with a non-integral
difference_type (such as iota_v
On 06/05/21 22:03 +0200, François Dumont via Libstdc++ wrote:
Hi
Considering your feedback on backtrace in debug mode is going to
take me some time so here is another one.
Compared to latest submission I've added a _Hash_arg_t partial
specialization for std::hash<>. It is not strictl
On Thu, 20 May 2021, 19:35 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/yes/yes
Thanks.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/100690
> * include/std/ranges (iota_view::_Sentinel::_M
On 20/05/21 11:25 -0600, Martin Sebor wrote:
On 5/20/21 6:56 AM, Jonathan Wakely wrote:
On 19/05/21 16:05 -0400, Jason Merrill wrote:
On 5/19/21 3:55 PM, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100,
On 20/05/21 12:34 -0400, Jason Merrill wrote:
On 5/20/21 8:56 AM, Jonathan Wakely wrote:
On 19/05/21 16:05 -0400, Jason Merrill wrote:
On 5/19/21 3:55 PM, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100,
On 19/05/21 23:52 +0100, Jonathan Wakely wrote:
On 19/05/21 16:08 -0400, Jason Merrill wrote:
On 5/19/21 4:05 PM, Jonathan Wakely wrote:
Oh, also we have https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93769
which points out a problem with the current wording. Not a very
important one, but still .
The current implementation of compile-time precondition checks causes
compilation to fail by calling a non-constexpr function declared at
block scope. This breaks the CUDA compiler, which wraps some libstdc++
headers in a pragma that declares everything as a __host__ __device__
function, but others
libstdc++-v3/ChangeLog:
* include/bits/random.tcc (__representable_as_double)
(__p1_representable_as_double): Add "" to static asserts.
Tested powerpc64le-linux. Committed to trunk.
commit 64ba45c76e831914764b70207d69a06f800b43a4
Author: Jonathan Wakely
Date: Thu May 20 21:12:
1501 - 1600 of 3694 matches
Mail list logo
