On Wed, 24 Jul 2024 at 22:51, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Any reason not to do this? I don't think the assertions are useful to
> catch implementation bugs where we access the contained value without
> checking it - we should use tests for that.
Looks good to me.
> The
On Wed, 3 Jul 2024 at 18:33, Jonathan Wakely wrote:
>
> On Thu, 27 Jun 2024 at 11:52, Jonathan Wakely wrote:
> >
> > This refactoring to use RAII doesn't seem to make any difference in
> > benchmarks, although the generated code for some std::vector operations
> > seems to be slightly larger.
On Tue, 7 May 2024 at 16:47, Jonathan Wakely wrote:
>
> I don't think using a macro for these really saves us much, we can do
> this to avoid duplication instead. And now it's not a big, multi-line
> macro that's a pain to edit.
>
> Any objections?
No, that's beautiful, ship it.
On Thu, 2 May 2024 at 20:25, Ken Matsui wrote:
> > There was some discussion of how to name the built-ins back in
> > https://gcc.gnu.org/pipermail/gcc-patches/2007-March/thread.html#212171
> > but __builtin wasn't discussed.
> >
> > Apparently this naming convention follows the MSVC precedent:
>
On Thu, 11 Apr 2024 at 20:22, Jonathan Wakely wrote:
>
> I'm considering this late patch for gcc-14 to workaround an issue
> discovered by a recent Clang change.
>
> I'm not yet sure if Clang is right to require these symbols. It's not
> really clear, because always_inline isn't part of the
On Fri, 12 Jan 2024 at 00:16, Jonathan Wakely wrote:
>
> I'd like to commit this to trunk for GCC 14. Please take a look.
Without looking at it in excruciating detail, it's pretty much along
the lines of what I have always envisioned
to be a powerful combination of concepts and if-constexpr. My
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
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
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
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,
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
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 st
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
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
>
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 Sun, 18 Apr 2021 at 13:49, Richard Kenner wrote:
>
> > Depends on the use cases. Not in military surveillance. And certainly not
> > at Lawrence Livermore National Laboratory. At Boeing could be the same, but
> > I'm not sure. Before 2011, rather than building things from scratch,
> >
On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote:
> I do not see people really intending to fork. It explains why detractors
> have gone berserk.
I appreciate your colorful exaggerations, but I should point out that
the libstdc++
maintainer has stated his intention to fork, in unambigous
On Fri, 16 Apr 2021 at 19:01, Jason Merrill wrote:
>
> On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc
> wrote:
> > > Sent: Saturday, April 17, 2021 at 1:03 AM
> > > From: "Ville Voutilainen"
> > > To: "Christopher Dime
On Fri, 16 Apr 2021 at 16:22, Christopher Dimech wrote:
> Many do not contribute because they do not have time, resources or support.
Yes? And? Even if GCC detaches itself from FSF, those who can contribute will
continue to contribute. And those who talk about contributing but
don't contribute
On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote:
> > The "small minority of developers" you speak of sure
> > seems to consist of developers who are not in the minority
> > considering how much they _actually contribute_ to the project.
>
> Due to their being paid for the work. Have no
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.
Huge apologies for mis-sending this to gcc-patches,
my email client makes suggestions when I attempt
to send to a gcc list. :D
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
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
>However, the FSF does NOT control nor own the GNU project. That appears
to be a very common misperception.
>The FSF offers various pro-bono services to the GNU project, among them
guarding some GNU assets for the GNU project, but the GNU project is an
independent (unincorporated) organization,
uently active than me.
I am, Yours Most Sincerely,
Ville Voutilainen
an occasional libstdc++ contributor
a less-frequently occasional g++ contributor
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
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
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
---
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
On Fri, 27 Nov 2020 at 11:54, Liu Hao via Libstdc++
wrote:
> As you can see, qualified names in C++ can grow up to ~100 characters quite
> frequently. This may
> deteriorate when `typename` and `template` are sometimes required. I don't
> think there is
> practically a set of rules which
On Fri, 27 Nov 2020 at 10:16, Richard Biener via Libstdc++
wrote:
> > Why not change this to:
> >
> > > if (present)
> > > ptr = gfc_build_conditional_assign_expr (
> > > block, present, ptr, nullarg);
> > >
> >
> > I think
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
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
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
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-
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{};
> >^
for correct visitors and ill-formed for incorrect
visitors.
2020-10-16 Ville Voutilainen
PR libstdc++/97449
* include/std/variant
(__gen_vtable_impl<>::_S_apply_single_alt):
Diagnose visitor return type mismatches here..
(__gen_vtable_impl::_S_apply):
..not here.
diff
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
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 ::t
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.
>
. This seems like a worthy incremental
improvement to me.
2020-09-29 Ville Voutilainen
PR libstdc++/95904
* include/std/variant (__same_types): New.
(__check_visitor_result): Likewise.
(__check_visitor_results): Likewise.
(visit(_Visitor&&, _Variants&
On Tue, 22 Sep 2020 at 19:46, Jonathan Wakely via Libstdc++
wrote:
>
> On 22/09/20 12:25 -0400, Rich Felker wrote:
> >Is there really a reason to want a nonstandard macro like this to do
> >something that's already trivial to do in the base language and has a
> >standard idiom (sizeof x / sizeof
On Tue, 22 Sep 2020 at 01:07, Jonathan Wakely via Libstdc++
wrote:
> ># define array_length(arr)(std:size(arr))
>
> C++ programmers will not accept a macro for this.
..in other words, the C++17 version of it needs to be an inline
function that returns std::size of an array,
not a macro. All
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;
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 unmodifie
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
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 expressi
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 d
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-ass
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-
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
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
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__ attrib
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_str
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 } }
> >
revealed some additional things to tweak. OK for trunk
and GCC 10?
2020-06-27 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
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
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
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,
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
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
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 jus
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,
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 chang
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
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-
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&&
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
> > aut
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
>
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
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
> >
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 { d
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 pla
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
On Fri, 6 Mar 2020 at 11:52, Andreas Krebbel wrote:
> > Hmm, what system does not have ENOSYS but has ENOTSUP? Meaning the
> > !defined ENOSYS
> > bit?
> >
> None that I know about. It is just to make sure the compare afterwards
> operates on defined inputs.
Ah, I see, indeed. This dance is
On Fri, 6 Mar 2020 at 10:41, Andreas Krebbel wrote:
>
> zTPF uses the same numeric value for ENOSYS and ENOTSUP.
>
> Ok for mainline?
>
> libstdc++-v3/ChangeLog:
>
> 2020-03-06 Andreas Krebbel
>
> * src/c++11/system_error.cc: Omit the ENOTSUP case statement if it
> would match
On Tue, 25 Feb 2020 at 15:36, Jonathan Wakely wrote:
> I think what I'd really like to do is get rid of __memmove entirely.
> We already have code that does the explicit assignment in a loop, for
> the cases where we can't use __builtin_memmove because the type is not
> trivially copyable.
>
> We
This shebang adds library tests for all cases of parenthesized aggregate
initialization that I could find. Tested locally on Linux-x64, going to
test with full suite on Linux-PPC64, OK for trunk if tests pass?
2020-02-23 Ville Voutilainen
Library-side tests for parenthesized aggregate
On Wed, 20 Nov 2019 at 12:16, Christophe Lyon
wrote:
>
> On Wed, 20 Nov 2019 at 11:10, Ville Voutilainen
> wrote:
> >
> > On Wed, 20 Nov 2019 at 11:47, Christophe Lyon
> > wrote:
> > >
> > > On Thu, 14 Nov 2019 at 16:55, Jonathan Wakely wrote:
&
On Wed, 20 Nov 2019 at 11:47, Christophe Lyon
wrote:
>
> On Thu, 14 Nov 2019 at 16:55, Jonathan Wakely wrote:
> >
> > On 09/11/19 02:07 +, Smith-Rowland, Edward M wrote:
> > >Here is the part of C++20 p1032 Misc constexpr bits.
> > >
> > >Tested on x86_64-linux. OK?
> >
> > OK for trunk,
On Mon, 18 Nov 2019 at 23:41, François Dumont wrote:
> > Also, is
> > this ABI-compatible
> > for our unordered containers?
> >
> IMHO, yes it is.
>
> In hashtable_policy.h _H1 was the user hash which I renamed in _Hash,
> the same template name that for unordered containers.
>
> _H2 was always
On Sun, 17 Nov 2019 at 23:15, François Dumont wrote:
>
> H1 used to be a reference to the user Hash, now _Hashtable and unordered
> types agree on the same Hash type which is more intuitive.
>
> I also chose to not support anymore a stateful ranged hash functor. We
> only use _Mod_range_hashing
On Fri, 15 Nov 2019 at 22:16, Smith-Rowland, Edward M
wrote:
>
> Pretty self-explanatory.
LGTM. Jonathan still needs to ack it.
On Sat, 6 Jul 2019 at 06:12, Ed Smith-Rowland via libstdc++
wrote:
> By my reckoning, you have a constexpr source array, an output array that
> is initialized as it must be for constexpr.?? You have to have a
> deterministic result after the copy.?? In the local array version the
> actual
1 - 100 of 631 matches
Mail list logo
