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 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 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 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 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 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
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/
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 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.
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 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 } }
> >
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 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
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
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 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-
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 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
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
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, 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{};
> >^
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
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 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.
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 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 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
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 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.
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, 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 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
601 - 632 of 632 matches
Mail list logo
