On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> + // Defined as a template to work around PR libstdc++/116440.
> + template
> + constexpr explicit(!__convertible())
> + tuple(const _Elements&... __elements)
I don't understand how a constructor template declared like thi
On Fri, 14 Mar 2025 at 00:04, Ville Voutilainen
wrote:
>
> On Fri, 14 Mar 2025 at 00:03, Ville Voutilainen
> wrote:
> >
> > On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > > > Do we also want to constraint the tuple(const _Elements&...)
>
On Thu, 13 Mar 2025 at 23:28, Patrick Palka wrote:
> > Oh, never mind. The pack is just deduced as an empty pack.
>
> Yep that's my understanding, though I don't know where in the standard
> this is specified, a quick Ctrl+F is failing me.
I'll go with https://eel.is/c++draft/temp.variadic#9, and
On Fri, 14 Mar 2025 at 00:03, Ville Voutilainen
wrote:
>
> On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > > Do we also want to constraint the tuple(const _Elements&...)
> > > constructor with requires sizeof...(_Elements) >= 1, which is present
> >
On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > Do we also want to constraint the tuple(const _Elements&...)
> > constructor with requires sizeof...(_Elements) >= 1, which is present
> > on the C++17 version?
>
> Oh we don't need that constraint, because we have an explicit
> specializati
On Thu, 13 Mar 2025 at 23:14, Patrick Palka wrote:
> Ah, I just realized the C++17 tuple impl already defines the
> tuple(const _Elements&...) constructor as a template in order to
> constrain it! So this patch arguably makes the C++20 constructor
> set more consistent with the C++17 impl, and so
On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
wrote:
>
> On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > + // Defined as a template to work around PR libstdc++/116440.
> > + template
> > + constexpr explicit(!__convertible())
> >
On Sat, 16 Nov 2024 at 01:12, Jason Merrill wrote:
>
> Does this seem like an interesting direction?
>
> -- 8< --
>
> A problem with coexistence of module std and the library headers is that
> import and then #include tends to break (PR99000). But even with that
> fixed, it might be useful to be
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 cu
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. Mayb
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 standa
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 g
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 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 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
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
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 a
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{};
> >^
formed 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 he
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 neste
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&&, _Variant
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 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 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 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__ a
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/2
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 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 rea
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 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 changes the c
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?
202
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
> 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
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 {
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 on
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 don
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 E
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, tha
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 an
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 iterator
On Thu, 27 Jun 2019 at 19:55, Ed Smith-Rowland via libstdc++
wrote:
> > I don't think this will work in a constant expression:
> >
> > ?? /// Assign @p __new_val to @p __obj and return its previous value.
> > ?? template
> > +?? _GLIBCXX20_CONSTEXPR
> > ?? inline _Tp
> > ?? exchange(_
On Thu, 20 Jun 2019 at 20:49, Antony Polukhin wrote:
>
> чт, 6 июн. 2019 г. в 15:19, Jonathan Wakely :
> > I'm removing some of these assertions again, because they are either
> > reundant or wrong.
>
> Thanks for cleaning up!
>
>
> In attachment there is an additional patch for type traits harden
On Mon, 10 Jun 2019 at 02:53, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> Darn it, I had those constexpr lib patches in tree.
> Attached are what I just committed to gcc-9 and passes there. Those
> std::copy didn't really add anything anyway.
They added a test that *i++ = *j++ works, and that
On Mon, 10 Jun 2019 at 01:03, Rainer Orth wrote:
>
> Hi Ed,
>
> >>> I had supplied the option for gnu++2a by hand and they passed.?? They
> >>> were not UNSUPPORTED.
> >>>
> >>> I just added the dg-options (at very top) and reran the testsuite
> >>> without fancy tricks (except for gnu++2a).
> >>>
1 - 100 of 632 matches
Mail list logo
