On Fri, 14 Apr 2023 at 07:03, Patrick Palka via Libstdc++
wrote:
>
> This also implements the approved follow-up LWG issues 3765, 3766, 3769,
> 3770, 3811, 3850, 3853, 3862 and 3872.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Hooray! THANK YOU!
No comments on the patch itsel
On Thu, 23 Mar 2023 at 12:53, Ken Matsui wrote:
> > DCO sign-off is indeed more light-weight, and sure, it's becoming more
> > common
> > since it's relatively new as an option.
>
> Thank you!
>
> To add a DCO sign-off, do I need to bump up the subject line to [PATCH v2]?
No. The format of the
On Thu, 23 Mar 2023 at 12:18, Ken Matsui via Libstdc++
wrote:
>
> Thank you so much for your review!
>
> This is my first time contributing to GCC, so I do not have a GCC
> copyright assignment. I googled those two ways, but I am still
> confused... Is it correct that the DCO sign-off has been get
On Thu, 17 Nov 2022 at 11:57, Daniel Krügler via Libstdc++
wrote:
> > 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.
Looks like someone's crunching to make a stage3 dea
Well, is_xible is not is_xible_p because it doesn't need to be both is_*
and *_p. But xes_from_temporary is less obviously a question, so
xes_from_temporary_p would imho be a better name.
On Fri, Jul 15, 2022, 18:33 Marek Polacek via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> On Thu, Jul 14, 202
On Wed, 8 Dec 2021 at 19:27, Jonathan Wakely via Libstdc++
wrote:
> After resolving a PEBKAC issue, here's an incremental diff that
> preserves the old behaviour for the existing @GLIBCXX_3.4.11 symbol,
> but adds a new @@GLIBCXX_3.4.30 symbol that supports cancellation via
> __forced_unwind.
>
>
On Fri, 26 Nov 2021 at 14:29, Jonathan Wakely via Libstdc++
wrote:
>
> I've bored of having to do preprocessor checks before using
> is_constant_evaluated, so I've come up with this approach. Anybody got a
> better idea, or objections to this?
None here, I like this improvement.
On Fri, 1 Oct 2021 at 23:19, Jonathan Wakely via Libstdc++
wrote:
>
> This adds a non-standard extension to support initializing a
> std::jthread with a pointer to a member function that expects a
> stop_token to be added to the arguments. That use case is not supported
> by C++20, because the sto
On Wed, 22 Sept 2021 at 20:49, Antony Polukhin wrote:
>
> ср, 22 сент. 2021 г. в 20:23, Ville Voutilainen :
> >
> > On Wed, 22 Sept 2021 at 20:09, Antony Polukhin via Libstdc++
> > wrote:
> > >
> > > std::unique_ptr allows construction from std::unique_ptr of derived
> > > type as per [unique.ptr
On Wed, 22 Sept 2021 at 20:09, Antony Polukhin via Libstdc++
wrote:
>
> std::unique_ptr allows construction from std::unique_ptr of derived
> type as per [unique.ptr.single.asgn] and [unique.ptr.single.ctor]. If
> std::default_delete is used with std::unique_ptr, then after such
> construction a d
On Thu, 5 Aug 2021 at 17:21, Jonathan Wakely via Libstdc++
wrote:
>
> On 04/08/21 12:55 +0100, Jonathan Wakely wrote:
> >This adds [[nodiscard]] throughout , as proposed by P2377R0
> >(with some minor corrections).
> >
> >The attribute is added for all modes from C++11 up, using
> >[[__nodiscard__
On Thu, 5 Aug 2021 at 15:11, Christophe Lyon via Libstdc++
wrote:
>
> Hi Jonathan,
>
> On Wed, Aug 4, 2021 at 2:04 PM Jonathan Wakely via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
> > On 04/08/21 12:56 +0100, Jonathan Wakely wrote:
> > >... and container adaptors.
> > >
> > >This adds the
On Fri, 16 Apr 2021 at 13:13, Ville Voutilainen
wrote:
>
> The actual suggestion is at the end; skip straight to it if you wish.
..please disregard, that was a send-o, should've have been sent to the
patches mailing list.
The actual suggestion is at the end; skip straight to it if you wish.
>Im glad there are people like you on the project Eric, because you express
exactly what a lot of people see - even if a minority of people chose to
ignore it,
>To a lot of "non americans", the events on here appear as nothing
On Wed, 3 Mar 2021 at 19:25, Jonathan Wakely via Libstdc++
wrote:
> Oh, except that is_scalar is surprisingly expensive to instantiate
> (its defined in a really expensive way) and since we control all uses
I'll be more than happy to write you an __is_scalar for GCC 12. :P
On Tue, 2 Mar 2021 at 00:21, Thiago Macieira wrote:
> But the code I posted, if people are careful to use write like I did, would
> allow us to have the experimental "we're not sure this is right"
> implementation of atomic waits, latches, barriers and semaphores right now.
The code assumes that
On Mon, 1 Mar 2021 at 23:54, Thiago Macieira wrote:
> But your suggestion does work. We don't need to apply them to all macros, only
> those that are new in a given version, like __cpp_lib_atomic_wait or
> __cpp_lib_latch in this case. Alternatively, implementations can set the macro
> to a given
On Mon, 1 Mar 2021 at 21:44, Thiago Macieira wrote:
> But you can see someone doing:
>
> #if __cplusplus >= 202002L && __has_include()
> # include
> #else
> # error "Please upgrade your compiler & standard library"
> #endif
>
> and using in their inline code. And as you say, if they then mix D
On Mon, 1 Mar 2021 at 20:09, Thiago Macieira via Libstdc++
wrote:
>
> On Sunday, 28 February 2021 07:05:47 PST Hans-Peter Nilsson wrote:
> > On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> > > ints can be used in futexes. chars can't.
> >
> > Shouldn't that be an atomic type instead
libstdc++-v3/ChangeLog:
* testsuite/27_io/rvalue_streams.cc: Run the extraction to a char*
for C++17 and lower only.
diff --git a/libstdc++-v3/testsuite/27_io/rvalue_streams.cc b/libstdc++-v3/testsuite/27_io/rvalue_streams.cc
index ad4d11c7cf3..487aa4deedd 100644
--- a/
OK for trunk if full testsuite passes? Should we consider having some sort
of test that catches such omissions?
2020-11-30 Ville Voutilainen
gcc/
PR c++/98054
* cp/cxx-pretty-print.c (pp_cxx_trait_expression):
Add support for __is_nothrow_{assignable,constructible}.
diff --git
On Thu, 5 Nov 2020 at 21:52, Jonathan Wakely via Libstdc++
wrote:
>
> On 05/11/20 19:09 +, Jonathan Wakely wrote:
> >The relational operators for std::optional were using the wrong types
> >in the declval expressions used to constrain them. Instead of using
> >const lvalues they were using non
On Wed, 4 Nov 2020 at 10:46, Stephan Bergmann via Libstdc++
wrote:
> To me it looks like it boils down to disagreement between g++ and
> clang++ over
>
> > struct S { static constexpr int f() { return 0; } };
> > void f(S & s) { static_assert(s.f(), ""); }
>
> where I think Clang might be right in
On Sat, 24 Oct 2020 at 03:07, Marek Polacek wrote:
> > Ha, we have the same thing in is_trivially_xible, so I'll drive-by
> > change that one as well.
>
> Please. Thanks!
The tree is also on a separated line in is_trivially_xible and
is_nothrow_xible, but not
in is_xible. What do we think about
On Sat, 24 Oct 2020 at 03:00, Marek Polacek wrote:
> > + tree expr;
> > + expr = is_xible_helper (code, to, from, /*trivial*/false);
>
> tree expr = is_xible_helper (code, to, from, /*trivial*/false);
>
> would be nicer, otherwise the front-end changes look fine, thanks.
Ha, we have the same
On Sat, 24 Oct 2020 at 02:32, Ville Voutilainen
wrote:
> * method.c (__is_nothrow_xible): New.
..and this is is_nothrow_xible, without leading underscores.
Finishing testing on Linux-PPC64. Ok for trunk if tests pass?
2020-10-24 Ville Voutilainen
gcc/c-family/ChangeLog:
Implement __is_nothrow_{constructible,assignable}
* c-common.c (__is_nothrow_assignable): New.
(__is_nothrow_constructible): Likewise.
* c-common.h (RID_IS_NO
On Fri, 16 Oct 2020 at 13:02, Jonathan Wakely wrote:
>
> On 16/10/20 10:26 +0300, Ville Voutilainen via Libstdc++ wrote:
> >Tested on Linux-PPC64. I haven't tested this with clang yet,
> >Jonathan, can you help with that? The previous implementation
> >indeed made an if-constexpr branch invalid fo
On Sat, 17 Oct 2020 at 20:30, Stephan Bergmann wrote:
> Clang (with -std=c++17/20) now complains about
>
> > include/c++/11.0.0/variant:1032:10: error: no matching constructor for
> > initialization of 'std::__nonesuch'
> > return __nonesuch{};
> >^
Tested on Linux-PPC64. I haven't tested this with clang yet,
Jonathan, can you help with that? The previous implementation
indeed made an if-constexpr branch invalid for all instantiations
of that branch, this one doesn't - now we have just a dependent static_assert
which is well-formed for correct
On Sat, 10 Oct 2020 at 13:52, Jonathan Wakely wrote:
> index_sequence uses size_t not unsigned long. This parameter pack
> needs to be size_t... _Idxs, and the NTTP for __check_visitor_result
> should be size_t _Idx.
Fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=02cbd79e4728319e0887ad77
On Mon, 5 Oct 2020 at 01:15, Ville Voutilainen
wrote:
> The patch is borked, doesn't pass tests, fixing...
Unborked, ok for trunk if full testsuite passes?
2020-10-05 Ville Voutilainen
PR libstdc++/95904
* include/std/variant (__deduce_visit_result): Add a nested ::type.
(__gen_v
On Sat, 3 Oct 2020 at 01:14, Jonathan Wakely wrote:
> OK for trunk with those leading spaces switched to tab.
The patch is borked, doesn't pass tests, fixing...
On Tue, 29 Sep 2020 at 14:20, Jonathan Wakely wrote:
> I think this is what we want:
>
>template
> constexpr inline __same_types = (is_same_v<_Tp, _Types> && ...);
>
> is_same_v is very cheap, it uses the built-in directly, so you don't
> need to instantiate any class templates at all.
>
Not completely tested yet. This does fix the problem of converting
incompatible pointer-to-function types, and thus gets rid of the suggestion
that compiling the code with -fpermissive is a possibility. There
is a special-casing for visit() for visitation of a single variant, and there
we don't eve
On Mon, 14 Sep 2020 at 15:49, Glen Fernandes wrote:
>
> On Mon, Sep 14, 2020 at 5:52 AM Ville Voutilainen wrote:
> > On Mon, 14 Sep 2020 at 12:51, Ville Voutilainen
> > wrote:
> > > On Mon, 14 Sep 2020 at 09:18, Glen Fernandes
> > wrote:
> > > > Edit; Correct patch this time.
> > > >
> > > > Fix
On Mon, 14 Sep 2020 at 12:51, Ville Voutilainen
wrote:
>
> On Mon, 14 Sep 2020 at 09:18, Glen Fernandes via Libstdc++
> wrote:
> >
> > Edit; Correct patch this time.
> >
> > Fix overflow handling in align
>
> Should the test verify that space is unmodified when nullptr is returned?
..and same fo
On Mon, 14 Sep 2020 at 09:18, Glen Fernandes via Libstdc++
wrote:
>
> Edit; Correct patch this time.
>
> Fix overflow handling in align
Should the test verify that space is unmodified when nullptr is returned?
On Tue, 21 Jul 2020 at 22:39, Marek Polacek wrote:
> > Okay. I think it's remotely reasonable that a static_cast(42) would
> > work for an array, then.
> > And by a natural extension, that using the concrete type would also
> > work. That seems consistent,
> > but doesn't seem like it rises to the
On Tue, 21 Jul 2020 at 21:56, Marek Polacek wrote:
>
> On Tue, Jul 21, 2020 at 12:53:03PM +0300, Ville Voutilainen wrote:
> > On Tue, 21 Jul 2020 at 02:28, Marek Polacek wrote:
> > >
> > > P1975R0 tweaks the static_cast wording: it says that "An expression e can
> > > be
> > > explicitly convert
On Tue, 21 Jul 2020 at 02:28, Marek Polacek wrote:
>
> P1975R0 tweaks the static_cast wording: it says that "An expression e can be
> explicitly converted to a type T if [...] T is an aggregate type having a
> first
> element x and there is an implicit conversion sequence from e to the type of
>
On Wed, 1 Jul 2020 at 23:53, Jonathan Wakely wrote:
>
> On 01/07/20 23:32 +0300, Ville Voutilainen via Libstdc++ wrote:
> >On Wed, 1 Jul 2020 at 21:09, Ville Voutilainen
> > wrote:
> >> And sure, s/move-construction/move-assignment/.
> >
> >And with dg-options.
>
> OK for master and gcc-10, thanks
On Wed, 1 Jul 2020 at 21:09, Ville Voutilainen
wrote:
> And sure, s/move-construction/move-assignment/.
And with dg-options.
2020-07-01 Ville Voutilainen
PR libstdc++/91807
* include/std/variant
(_Copy_assign_base::operator=(const _Copy_assign_base&):
Do the move-assignment f
On Wed, 1 Jul 2020 at 20:46, Ville Voutilainen
wrote:
>
> Looks like just a small thinko. We construct a temporary and move-construct
> from it, but we should construct the temporary with the right index.
>
> OK for trunk and gcc-10 if full tests pass?
>
> 2020-07-01 Ville Voutilainen
>
> P
Looks like just a small thinko. We construct a temporary and move-construct
from it, but we should construct the temporary with the right index.
OK for trunk and gcc-10 if full tests pass?
2020-07-01 Ville Voutilainen
PR libstdc++/91807
* include/std/variant
(_Copy_assign_base::op
On Mon, 29 Jun 2020 at 00:16, Jonathan Wakely wrote:
> >Hmm, let's use dg-additional-options here too, and axe the pointless
> >-std=gnu++11.
>
> I agree the -std=gnu++11 isn't needed, but thre doesn't seem to be any
> advantage to dg-additional-options here. The reason I suggested it for
> th oth
On Sun, 28 Jun 2020 at 13:56, Ville Voutilainen
wrote:
>
> 2020-06-28 Ville Voutilainen
>
> Add a __nonnnull__ attribute to std::string's _CharT* constructor
> * include/bits/basic_string.h (string(_CharT*, const _Alloc&)):
> Add a __nonnull__ attribute.
> * testsuite/21_strings
2020-06-28 Ville Voutilainen
Add a __nonnnull__ attribute to std::string's _CharT* constructor
* include/bits/basic_string.h (string(_CharT*, const _Alloc&)):
Add a __nonnull__ attribute.
* testsuite/21_strings/basic_string/cons/char/nonnull.cc: New.
* testsuite/21_strings/b
On Sat, 27 Jun 2020 at 17:53, Ville Voutilainen
wrote:
>
> On Fri, 26 Jun 2020 at 21:20, Jonathan Wakely wrote:
> > For these three tests I think this would be slightly better:
> >
> > // { dg-additional-options "-Wno-deprecated" { target c++17 } }
> >
> > That way we only ignore the warning when
On Fri, 26 Jun 2020 at 21:20, Jonathan Wakely wrote:
> For these three tests I think this would be slightly better:
>
> // { dg-additional-options "-Wno-deprecated" { target c++17 } }
>
> That way we only ignore the warning when actually needed.
Sure thing. The test run revealed some additional t
On Fri, 26 Jun 2020 at 19:12, Ville Voutilainen
wrote:
>
> This patch also deprecates std::is_literal_type.
I forgot to ask, OK for trunk and GCC 10 if full suite testing passes?
The problematic compiler bug has been
gone since GCC 10, so we can just as well backport this there, but not further.
This patch also deprecates std::is_literal_type.
2020-06-26 Ville Voutilainen
PR libstdc++/95915
* include/std/type_traits (is_literal_type, is_literal_type_v):
Deprecate in C++17.
* include/std/variant (_Uninitialized):
Adjust the condition and the comment.
* testsuite
On Thu, 4 Jun 2020 at 14:41, Richard Biener wrote:
> Doesn't the placement new make the memory state of anything
> not explicitely initialized indeterminate? That is, isn't the
> testcase broken anyways since GCC can elide the memset
> when seeing the placement new?
Hmm, yes it does, and the tes
On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote:
>
> On Thu, 4 Jun 2020, Ville Voutilainen wrote:
>
> > On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
> >> Maybe create a buffer, fill it with some non-zero values (-1?), then call
> >> placement new, and read some value in the middle of the buffer
On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
> Maybe create a buffer, fill it with some non-zero values (-1?), then call
> placement new, and read some value in the middle of the buffer, possibly
> with some protection against optimizations? Ah, no, actual constructors
> are fine, it is only th
On Thu, 4 Jun 2020 at 10:22, Marc Glisse wrote:
> > So the change is correct. Can we test the change somehow?
>
> It passes the testsuite, and libc++ has been doing it this way for years.
> What I feared was some regression where it would yield worse code in some
> cases, or lose some property (n
On Thu, 4 Jun 2020 at 03:05, Ville Voutilainen
wrote:
> > > "noexcept" is a red herring, what matters is defaulted vs user-provided.
> > > In one case, we end up zero-initializing the whole buffer, and not in the
> > > other.
> >
> > Yes, I just came to that conclusion. This is value-init, so the
On Thu, 4 Jun 2020 at 02:20, Ville Voutilainen
wrote:
>
> On Thu, 4 Jun 2020 at 02:13, Marc Glisse wrote:
> >
> > On Thu, 4 Jun 2020, Ville Voutilainen wrote:
> >
> > > On Thu, 4 Jun 2020 at 01:52, Marc Glisse wrote:
> > >>
> > >> Hello,
> > >>
> > >> is there any drawback to the attached patch?
On Thu, 4 Jun 2020 at 02:13, Marc Glisse wrote:
>
> On Thu, 4 Jun 2020, Ville Voutilainen wrote:
>
> > On Thu, 4 Jun 2020 at 01:52, Marc Glisse wrote:
> >>
> >> Hello,
> >>
> >> is there any drawback to the attached patch? It changes the code generated
> >> for
> >
> > I don't get it. The noexce
On Thu, 4 Jun 2020 at 01:52, Marc Glisse wrote:
>
> Hello,
>
> is there any drawback to the attached patch? It changes the code generated for
I don't get it. The noexceptness of the defaulted default constructor
should be a computation
of the noexceptness of the subobjects, and that should boil d
On Mon, 11 May 2020 at 00:09, François Dumont via Libstdc++
wrote:
>
> I just committed this patch.
This was a commit-without-review. When the patch was originally
posted, the maintainer said
"Let's revisit it in a few weeks.". That's not the same as "OK when
stage1 reopens."
On Fri, 1 May 2020 at 21:15, Ville Voutilainen
wrote:
>
> Aggregate-paren-init breaks tuple and optional. This fixes the breakage.
> An LWG issue will be filed.
The previous approach was bogus. Here's a better one. Ok for master
and gcc-10 if
full testsuite run passes?
2020-05-02 Ville Voutilai
Aggregate-paren-init breaks tuple and optional. This fixes the breakage.
An LWG issue will be filed.
Full suite test run pending. Ok for master and gcc-10 if the full tests pass?
2020-05-01 Ville Voutilainen
PR libstdc++/94890
* include/std/optional (optional(_Up&&)): Add is_aggregate
On Tue, 21 Apr 2020 at 11:29, kamlesh kumar wrote:
>
> Added the fix for emplace.
>
> diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
> index 6b7e68f0e63..f35d90e548d 100644
> --- a/libstdc++-v3/include/std/any
> +++ b/libstdc++-v3/include/std/any
> @@ -178,30 +178,17 @@ _
On Tue, 21 Apr 2020 at 09:11, Ville Voutilainen
wrote:
>
> On Tue, 21 Apr 2020 at 04:10, kamlesh kumar wrote:
> >
> > Thank you for reviewing.
> > without _Decay to decay_t in the constructor which takes inplace_type_t,
> > cases like this fails
> > auto a = std::any(std::in_place_type, 5);
> >
On Tue, 21 Apr 2020 at 04:10, kamlesh kumar wrote:
>
> Thank you for reviewing.
> without _Decay to decay_t in the constructor which takes inplace_type_t,
> cases like this fails
> auto a = std::any(std::in_place_type, 5);
>
> for these constructors, standard does not say anything about
> not-sam
On Mon, 20 Apr 2020 at 21:09, Ville Voutilainen
wrote:
>
> On Sat, 18 Apr 2020 at 03:35, kamlesh kumar via Libstdc++
> wrote:
> >
> > On Fri, Apr 17, 2020, 10:59 PM kamlesh kumar
> > wrote:
> >
> > > Fixes all this.
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
> > > https://gcc.gnu.o
On Sat, 18 Apr 2020 at 03:35, kamlesh kumar via Libstdc++
wrote:
>
> On Fri, Apr 17, 2020, 10:59 PM kamlesh kumar
> wrote:
>
> > Fixes all this.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91630
> > https://gcc.gnu.org/bugzilla/show_bug.
On Tue, 17 Mar 2020 at 16:52, Ville Voutilainen
wrote:
>
> On Tue, 17 Mar 2020 at 16:42, Jason Merrill wrote:
> >
> > On 3/17/20 9:04 AM, Jonathan Wakely wrote:
> > > On 17/03/20 13:02 +, Jonathan Wakely wrote:
> > >> Shouldn't the test use { dg-do compile { target c++11 } } instead of:
> > >
On Tue, 17 Mar 2020 at 16:42, Jason Merrill wrote:
>
> On 3/17/20 9:04 AM, Jonathan Wakely wrote:
> > On 17/03/20 13:02 +, Jonathan Wakely wrote:
> >> Shouldn't the test use { dg-do compile { target c++11 } } instead of:
> >>
> >> +// { dg-do compile }
> >> +// { dg-options "-std=c++11" }
>
>
On Mon, 16 Mar 2020 at 23:25, Ville Voutilainen
wrote:
>
> Tested on Linux-PPC64.
>
> This ain't no regression. But it seems to hamper attempts to fix library
> regressions (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033).
It occurred to me that this can be done in one place.
2020-03-17
Tested on Linux-PPC64.
This ain't no regression. But it seems to hamper attempts to fix library
regressions (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033).
2020-03-16 Ville Voutilainen
gcc/
PR c++/94197
* cp/method.c (assignable_expr, constructible_expr): Push
a def
72 matches
Mail list logo
