On 29 October 2017 at 00:57, Ville Voutilainen
wrote:
> 2017-10-29 Ville Voutilainen
>
> Implement LWG 2485
The full testsuite passes on Linux-PPC64. The debug mode tests for
array have been run manually
on Linux-x64.
On 15 July 2017 at 18:48, Jonathan Wakely wrote:
> WG21 just approved this change as a DR for C++17, so that class
> template argument deduction works when using std::adopt_lock with a
> std::scoped_lock.
>
> * include/std/mutex (scoped_lock): Reorder std::adopt_lock_t
> parameter
>
On 18 July 2017 at 16:31, Jonathan Wakely wrote:
> This is quite a huge change, so I'd like to wait and see if anyone
> else has any opinion on it.
>
> Personally I think it's necessary (assuming I understand the PR
> correctly) and so if nobody objects I think we should go with this
> change for
On 26 July 2017 at 21:14, Paolo Carlini wrote:
> Hi again,
>
> On 26/07/2017 16:27, Paolo Carlini wrote:
>>
>> Hi,
>>
>> On 26/07/2017 16:21, Andreas Schwab wrote:
>>>
>>> ERROR: 27_io/basic_fstream/53984.cc: unknown dg option:
>>> dg-require-file-io 18 {} for " dg-require-file-io 18 "" "
>>
>> Sh
On 31 July 2017 at 16:25, Marek Polacek wrote:
> The documentation of std::stack says that the underlying container must
> support
> pop_front, but that is wrong, it meant to say pop_back, so this patch fixes
> that.
Indeed, the documentation has a copy-pasto originating from bits/stl_queue.h.
>Good point. "gnutools" might be more accurate, but people might object
>to adding 10 extra characters for "gnutools::".
>Naming is important, especially for a whole namespace (not just a
>single type) so I do think it's worth spending time getting it right.
>But I could live with gtl as long as
2017-08-29 Ville Voutilainen
Make taking the address of an overloaded function a non-deduced context
cp/
* pt.c (unify_overload_resolution_failure): Return unify_success
instead of unify_invalid.
testsuite/
* g++.dg/overload/template6.C: New.
diff --git a/gcc/cp
On 30 August 2017 at 01:19, Ville Voutilainen
wrote:
> 2017-08-29 Ville Voutilainen
>
> Make taking the address of an overloaded function a non-deduced context
>
> cp/
>
> * pt.c (unify_overload_resolution_failure): Return unify_success
>
On 30 August 2017 at 01:25, Ville Voutilainen
wrote:
> On 30 August 2017 at 01:19, Ville Voutilainen
> wrote:
>> 2017-08-29 Ville Voutilainen
>>
>> Make taking the address of an overloaded function a non-deduced context
>>
>> cp/
>>
>&g
On 30 August 2017 at 19:07, Jason Merrill wrote:
> Please also remove the error. OK with that change.
Here's a new and much improved version as discussed on IRC. Tested on
Linux-PPC64.
Ok for trunk?
2017-08-30 Ville Voutilainen
Make taking the address of an overloaded functi
On 7 September 2017 at 17:18, Jonathan Wakely wrote:
> Does anybody object to this change? Is getting a #error still useful,
> given the existence of __has_include and __cpp_lib macros?
I wholeheartedly agree with this change. And I should point out that
vast amounts of optional's implementation
Tested on Linux-x64, not tested with the full suite yet.
2017-05-09 Ville Voutilainen
gcc/
PR c++/80682
* cp/method.c (is_trivially_xible): Reject void types.
testsuite/
PR c++/80682
* g++.dg/ext/is_trivially_constructible1.C: Add tests for void target.
diff --git a
On 9 May 2017 at 16:12, Marc Glisse wrote:
> On Tue, 9 May 2017, Ville Voutilainen wrote:
>
>> Tested on Linux-x64, not tested with the full suite yet.
>>
>> 2017-05-09 Ville Voutilainen
>>
>>gcc/
>>
>>PR c++/80682
>>
On 9 May 2017 at 16:25, Jakub Jelinek wrote:
>> >> 2017-05-09 Ville Voutilainen
>> >>
>> >>gcc/
>> >>
>> >>PR c++/80682
>> >>* cp/method.c (is_trivially_xible): Reject void types.
>
> No cp/ in cp/Chan
On 9 May 2017 at 17:14, Nathan Sidwell wrote:
> On 05/09/2017 08:06 AM, Ville Voutilainen wrote:
>>
>> Tested on Linux-x64, not tested with the full suite yet.
>>
>> 2017-05-09 Ville Voutilainen
>>
>> gcc/
>>
>> PR c++/80682
>
On 10 May 2017 at 09:57, Ville Voutilainen wrote:
> On 9 May 2017 at 17:14, Nathan Sidwell wrote:
>> On 05/09/2017 08:06 AM, Ville Voutilainen wrote:
>>>
>>> Tested on Linux-x64, not tested with the full suite yet.
>>>
>>> 2017-05-09 Ville Vout
On 10 May 2017 at 14:40, Nathan Sidwell wrote:
>>> Full testsuite run is clean. Is it ok to backport this change to
>>> gcc-6? (And gcc-7, too)
>>
>>
>> ..and gcc-5. Backporting everywhere allows library implementations
>> including libc++ to
>> just use the intrinsic, without using std::is_constr
would
welcome any help fixing that problem.
2017-05-12 Ville Voutilainen
c-family/
Implement new C++ intrinsics __is_assignable and __is_constructible.
* c-common.c (__is_assignable, __is_constructible): New.
* c-common.h (RID_IS_ASSIGNABLE, RID_IS_CONSTRUCTIBLE): Likewise.
On 12 May 2017 at 14:06, Daniel Krügler wrote:
> 2017-05-12 12:39 GMT+02:00 Ville Voutilainen :
>> I have tested this with the full suite on Linux-PPC64. It works otherwise
>> fine,
>> but there's one snag: 20_util/unique_ptr/specialized_algorithms/swap_cxx17.cc
>&
On 12 May 2017 at 14:15, Ville Voutilainen wrote:
> On 12 May 2017 at 14:06, Daniel Krügler wrote:
>> Your description sounds remotely similar to me to the current problem
>> of __is_trivially_constructible intrinsic, which seems to instantiate
>> the copy constructor defi
full testsuite.
Jonathan, ok for trunk?
2017-05-17 Ville Voutilainen
c-family/
Implement new C++ intrinsics __is_assignable and __is_constructible.
* c-common.c (__is_assignable, __is_constructible): New.
* c-common.h (RID_IS_ASSIGNABLE, RID_IS_CONSTRUCTIBLE): Likewise.
Tested on Linux-x64, running full suite on Linux-ppc64. It seems fitting
to put the test into the library tests, we don't have separate tests
on the front-end side for __is_constructible, so I think adding such
would be a separate job.
2017-05-25 Ville Voutilainen
cp/
PR c++/
On 28 May 2017 at 23:29, Tim Song wrote:
> libstdc++ has a to_chars implementation already. Assuming that the
> locale issue isn't a problem, can that be reused?
Maybe, but that implementation hasn't landed yet. The patch has been circulated
but I don't see it having been committed.
On 1 June 2017 at 18:13, Jonathan Wakely wrote:
> On 30/05/17 02:16 -0700, Tim Shen via libstdc++ wrote:
>>
>> diff --git a/libstdc++-v3/include/std/variant
>> b/libstdc++-v3/include/std/variant
>> index b9824a5182c..f81b815af09 100644
>> --- a/libstdc++-v3/include/std/variant
>> +++ b/libstdc++-v
On 1 June 2017 at 18:29, Jonathan Wakely wrote:
>> They all seem to be shortcuts for something::value, so it seems to me
>> logical to have
>> them all be _v.
>
>
> The _v suffixes in the standard are there to distinguish std::foo from
> std::foo_v, but we don't have that problem.
Wouldn't necess
On 1 June 2017 at 19:03, Jonathan Wakely wrote:
> On 01/06/17 18:43 +0300, Ville Voutilainen wrote:
>>
>> On 1 June 2017 at 18:29, Jonathan Wakely wrote:
>>>>
>>>> They all seem to be shortcuts for something::value, so it seems to me
>>>> logic
Tested on Linux-x64.
The issue doesn't have a proposed resolution yet, so we can certainly wait
with this, but I have an inkling that this implementation is what the proposed
resolution must say. :)
2016-12-20 Ville Voutilainen
Implement 2801, Default-constructibility of uniqu
tantially copied from an existing file, or should it just
> be 2016? (Not that it really matters, as I don't think we should have
Should just be 2016, fixed.
2016-12-29 Ville Voutilainen
Implement 2801, Default-constructibility of unique_ptr.
* include/bits/unique_ptr.h (__uniq
On 29 December 2016 at 21:57, Ville Voutilainen
wrote:
>> Instead of repeating this condition half a dozen times, we could put
>> it in the __uniq_ptr_impl class template and reuse it, as in the
>> attached patch (and similarly for the unique_ptr specialization).
>> W
Tested on Linux-x64.
2017-01-09 Ville Voutilainen
Reduce the size of variant, it doesn't need an index of
type size_t internally.
* include/std/variant (parse_numbers.h): New include.
(__select_index): New.
(_Variant_storage::_M_reset_impl): Use
_index_typ
Cleanups based on review; there's no longer any public typedefs added
to variant,
and the test is greatly simpler with much less trickery.
2017-01-11 Ville Voutilainen
Reduce the size of variant, it doesn't need an index of
type size_t internally.
* include/s
would need to be allocated.
2017-01-13 Ville Voutilainen
PR libstdc++/78389
* include/bits/list.tcc (merge(list&&)):
Adjust list sizes if the comparator throws.
(merge(list&&, _StrictWeakOrdering)): Likewise.
* testsuite/23_containers/list/operations/78389.
On 13 January 2017 at 08:01, Tim Song wrote:
> On Thu, Jan 12, 2017 at 8:11 PM, Ville Voutilainen
> wrote:
>> This patch doesn't try to fix the reported sort() issue, because
>> a) it would require undoing a throwing move operation, which
>> is impossible.
>>
On 13 January 2017 at 09:51, Tim Song wrote:
>>> Wait, what throwing move? list::sort should be all splicing and no
>>> moving, unless I missed something.
>>
>> It operates based on merge, which moves elements from one list to
>> another using a throwing
>> comparator. Undoing that operation is fa
On 13 January 2017 at 09:56, Ville Voutilainen
wrote:
>> problem with just going through all of them and splicing the contents
>> (if any) back to *this?
>
> Well, in addition to the computational complexity of it, not knowing
> which elements should be spliced
> back wher
On 13 January 2017 at 10:02, Tim Song wrote:
> On Fri, Jan 13, 2017 at 3:00 AM, Ville Voutilainen
> wrote:
>> On 13 January 2017 at 09:56, Ville Voutilainen
>> wrote:
>>>> problem with just going through all of them and splicing the contents
>>>>
On 13 January 2017 at 10:09, Ville Voutilainen
wrote:
>>> Ah, I think I see what you're saying. Just splice them back in any
>>> order. Ok, I'll give that a spin.
>>
>> Right, list::sort doesn't promise strong exception safety, so
>> &qu
On 13 January 2017 at 10:27, Ville Voutilainen
wrote:
> On 13 January 2017 at 10:09, Ville Voutilainen
> wrote:
>>>> Ah, I think I see what you're saying. Just splice them back in any
>>>> order. Ok, I'll give that a spin.
>>>
>>> Rig
On 13 January 2017 at 10:29, Ville Voutilainen
wrote:
> ..and yes, sigh, that patch has whitespace damage in it. I have
> already fixed that, so that'll be corrected before
> committing.
..as well as replacing those asserts with VERIFY.
Update patch with splices for __carry added. Hopefully this resolves
the remaining concerns that we had.
diff --git a/libstdc++-v3/include/bits/list.tcc
b/libstdc++-v3/include/bits/list.tcc
index c4f397f..9ba403c 100644
--- a/libstdc++-v3/include/bits/list.tcc
+++ b/libstdc++-v3/include/bits/list.
On 15 January 2017 at 18:42, Tim Song wrote:
> On rereading the patch today, the size calculation for merge() appears
> to be backwards. [__first2, __last2) consists of the nodes not
> transferred into *this, so the new size of __x should be __dist while
> this->size() should be incremented by (__
On 15 January 2017 at 19:01, Ville Voutilainen
wrote:
> On 15 January 2017 at 18:42, Tim Song wrote:
>> On rereading the patch today, the size calculation for merge() appears
>> to be backwards. [__first2, __last2) consists of the nodes not
>> transferred into *this, s
On 15 January 2017 at 19:07, Ville Voutilainen
wrote:
> On 15 January 2017 at 19:01, Ville Voutilainen
> wrote:
>> On 15 January 2017 at 18:42, Tim Song wrote:
>>> On rereading the patch today, the size calculation for merge() appears
>>> to be backwards. [__fi
On 15 January 2017 at 19:22, Ville Voutilainen
wrote:
> Hmm, and yeah, your test uses a different throw-after number, so I
> should change the tests to do the same. :)
In other words, like in the attached patch.
diff --git a/libstdc++-v3/testsuite/23_containers/list/operations/78389
is for std::experimental::optional as well.
2017-01-20 Ville Voutilainen
Make poisoned hashes SFINAE away the call operator
of the hash.
* include/bits/functional_hash.h
(__poison_hash::__enable_hash_call): New.
* include/bits/unique_ptr.h (__unique_ptr_hash_call_base): New.
On 20 January 2017 at 17:21, Jonathan Wakely wrote:
> This part for std::unique_ptr is the only part that isn't C++17-only,
> so this is the part I'm most nervous about. Given that we're in stage
> 4 and this isn't even fixing something in Bugzilla (even if it is a
> real bug), would it be possibl
On 20 January 2017 at 17:27, Ville Voutilainen
wrote:
> On 20 January 2017 at 17:21, Jonathan Wakely wrote:
>> This part for std::unique_ptr is the only part that isn't C++17-only,
>> so this is the part I'm most nervous about. Given that we're in stage
>> 4
present.
2017-01-22 Ville Voutilainen
PR libstdc++/78420
* include/bits/stl_function.h (): New include in C++11 mode
and above.
(greater<_Tp*>): New specialization in C++11 mode and above.
(less<_Tp*>): Likewise.
(greater_equal<_Tp*>): Likewise.
On 22 January 2017 at 17:57, Tim Song wrote:
> On Sun, Jan 22, 2017 at 10:42 AM, Ville Voutilainen
> wrote:
>> + _GLIBCXX14_CONSTEXPR
>> + bool
>> + operator()(_Tp* __x, _Tp* __y) const
>> + { return uintptr_t(__x) > uintptr_t(__y); }
On 24 January 2017 at 14:05, Jonathan Wakely wrote:
> I've just committed this, and then noticed that we don't do the same
> optimization for basic_string unless the char_type is char. Presumably
> this is so that we do call basic_string::compare() and so call any
> user-defined traits_type::eq()
On 24 January 2017 at 16:16, Jonathan Wakely wrote:
>> We do want it for basic_string as well, I think. And while I doubt
>> your interpretation
>> of the standard is pedantically correct, I also think that the
>> standard is broken if it
>> doesn't allow this optimization, and the standard should
On 24 January 2017 at 16:46, Ville Voutilainen
wrote:
> On 24 January 2017 at 16:16, Jonathan Wakely wrote:
>>> We do want it for basic_string as well, I think. And while I doubt
>>> your interpretation
>>> of the standard is pedantically correct, I also think that
I ran the tests for g++.dg/init thus far. Does this patch make sense?
2017-03-20 Ville Voutilainen
gcc/
PR c++/35878
* cp/init.c (build_new_1): Don't do a null check for
a placement new.
testsuite/
PR c++/35878
* testsuite/g++.dg/init/placement6.C: New.
On 20 March 2017 at 04:27, Jason Merrill wrote:
> On Sun, Mar 19, 2017 at 6:19 PM, Ville Voutilainen
> wrote:
>> I ran the tests for g++.dg/init thus far. Does this patch make sense?
>
> The condition needs to be a lot more specific: DR 1748 only applies to
> the no
also conveniently let's me provide a ChangeLog that reads like a
Real Front-End
Developer would've written it. :) New tests re-tested on Linux-x64,
running full suite
on Linux-PPC64.
2017-03-21 Ville Voutilainen
gcc/
PR c++/35878
* cp/init.c (non_allocating_fn
On 21 March 2017 at 02:36, Ville Voutilainen
wrote:
> On 21 March 2017 at 01:44, Jason Merrill wrote:
>>> It looks strange to me. Why not change the definition of check_new instead
>>> of changing the condition that uses it?
>>
>> Agreed. Also, let's fa
On 21 March 2017 at 02:43, Ville Voutilainen
wrote:
> Hmm. I should either rename that function or flip its logic. Now it's
> a bit backwards. :) I'll flip its logic.
In other words, see attached.
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index dc5a5f7..a6be32e 100644
--- a/gcc
On 21 March 2017 at 02:46, Ville Voutilainen
wrote:
> On 21 March 2017 at 02:43, Ville Voutilainen
> wrote:
>> Hmm. I should either rename that function or flip its logic. Now it's
>> a bit backwards. :) I'll flip its logic.
>
> In other words, see attached
On 21 March 2017 at 08:48, Jakub Jelinek wrote:
> Formatting etc. nits:
>
>> 2017-03-21 Ville Voutilainen
>>
>> gcc/
>>
>> PR c++/35878
>
> This should go into gcc/cp/ ChangeLog
>
>> * cp/init.c (std_placement_new_fn_p): New.
On 21 March 2017 at 08:55, Ville Voutilainen
wrote:
>>> +// { dg-options "-O2 --std=gnu++11" }
>>
>> -O2 -std=gnu++11 is enough, no need for double dash --std=gnu++11.
>>
>>> +// { dg-do compile }
>>> +// { dg-final { scan-ass
On 21 March 2017 at 09:17, Jakub Jelinek wrote:
> I've tested in the mean time the following patch with both gcc from yesterday
> where
> pr35878_3.C fails as expected, and with the latest cc1plus where
> it succeeds both with -m32 and -m64. Scanning the tree dump has the
> advantage that you te
le separately. However, that's a topic for another day,
as mentioned.
Tested on Linux-x64.
2017-03-27 Ville Voutilainen
Slight cleanup of tuple constraints.
* include/std/tuple (tuple(const _Elements&...)): Strike
the unnecessary sizeof... test.
(tuple(_UEleme
Tested on Linux-x64.
2017-03-29 Ville Voutilainen
Adjust optional's pretty printer for LWG 2900.
* python/libstdcxx/v6/printers.py (StdExpOptionalPrinter::__init__):
Look at the nested payload in case of non-experimental optional.
diff --git a/libstdc++-v3/python/libstdc
Tested on Linux-x64.
2017-04-02 Ville Voutilainen
Implement std::is_aggregate.
* include/std/type_traits (is_aggregate): New.
* testsuite/20_util/is_aggregate/requirements/explicit_instantiation.cc:
New.
* testsuite/20_util/is_aggregate/requirements/typedefs.cc: Likewise
Tested on Linux-x64.
2017-04-02 Ville Voutilainen
PR libstdc++/79141
* include/bits/stl_pair.h (__wrap_nonesuch): New.
(operator=(typename conditional<
__and_,
is_copy_assignable<_T2>>::value,
const pair&, const __wrap_nonesuch&>::type)): C
On 2 April 2017 at 08:35, Jakub Jelinek wrote:
>> + remove_cv_t<_Tp>
>> + )>
>
> Any reason for the wrapping?
No, it's just a result of a nocturnal copy-paste-job of the existing
code for has_unique_object_representations.
> Also, shouldn't there be also:
>
> /// is_aggregate_v
> t
On 2 April 2017 at 14:08, Jakub Jelinek wrote:
> On Sun, Apr 02, 2017 at 12:24:16PM +0300, Ville Voutilainen wrote:
>> On 2 April 2017 at 08:35, Jakub Jelinek wrote:
>> >> + remove_cv_t<_Tp>
>> >> + )>
>> >
>> > Any reason f
On 2 April 2017 at 02:45, Ville Voutilainen wrote:
> Tested on Linux-x64.
For what it's worth, here's a saner changelog that uses the signatures
that were originally in place. The patch
passes the full testsuite on Linux-PPC64 without regressions.
2017-04-02 Ville Voutilai
On 5 April 2017 at 00:29, Bernd Edlinger wrote:
>> The new test doesn't really belong in the libstdc++, does it?
>>
>> If this is a bug in the front-end then a reduced version of the test
>> belongs in the g++ testsuite.
>>
>
> Yes, I moved the test case to the g++.dg/lto branch, where it
> fortun
Tested on Linux-x64.
2017-01-30 Ville Voutilainen
Implement LWG 2825, LWG 2756 breaks class template argument
deduction for optional.
* include/std/optional: Add a deduction guide.
* testsuite/20_util/optional/cons/deduction_guide.cc: New.
diff --git a/libstdc++-v3/include/std
On 31 January 2017 at 00:06, Tim Song wrote:
> On Mon, Jan 30, 2017 at 9:36 PM Jonathan Wakely wrote:
>>
>> On 30/01/17 13:28 +, Jonathan Wakely wrote:
>> >On 30/01/17 13:47 +0200, Ville Voutilainen wrote:
>> >>Tested on Linux-x64.
>> >
>>
On 31 January 2017 at 00:41, Ville Voutilainen
wrote:
> On 31 January 2017 at 00:06, Tim Song wrote:
>> On Mon, Jan 30, 2017 at 9:36 PM Jonathan Wakely wrote:
>>>
>>> On 30/01/17 13:28 +, Jonathan Wakely wrote:
>>> >On 30/01/17 13:47 +0200, Ville Vouti
Currently, clang rejects all attempts to visit a libstdc++ variant:
https://godbolt.org/g/kSmBTg
While gcc doesn't reject such code, that seems like an access checking
bug. This patch makes the offending _M_u member accessible for the rest
of the code.
2017-02-07 Ville Voutilainen
F
On 7 February 2017 at 22:00, Ville Voutilainen
wrote:
> Currently, clang rejects all attempts to visit a libstdc++ variant:
> https://godbolt.org/g/kSmBTg
>
> While gcc doesn't reject such code, that seems like an access checking
> bug. This patch makes the offending _M_u m
On 14 February 2017 at 23:22, Dinka Ranns wrote:
> C++17 GB50 resolution
> * libstdc++-v3/include/std/chrono:
Pardon me for not noticing this while looking at the earlier versions
of this patch, but these should
not include the libstdc++-v3 prefix, so it should be
* include/std/c
optional's comparisons to actually
work like the comparisons of the underlying type.
Tested on Linux-x64.
2017-02-19 Ville Voutilainen
Make optional's comparisons be two-parameter templates.
* include/std/optional
(operator==(const optional<_Tp>&, const optional&l
Tested on Linux-x64.
2017-03-12 Ville Voutilainen
Implement LWG 2806, Base class of bad_optional_access.
* include/std/optional (bad_optional_access):
Derive from std::exception.
(bad_optional_access::bad_optional_access): Adjust.
(bad_optional_access::what): New
All branches tested on Linux-x64.
Changelogs for trunk, gcc-6-branch, gcc-5-branch (the last two are identical, as
are probably their patches).
2017-03-13 Ville Voutilainen
PR libstdc++/80034
* include/bits/list.tcc (merge(list&&)): Use const for the size_t
in the cat
Tested on Linux-x64.
2017-03-16 Ville Voutilainen
Implement LWG 2857, {variant,optional,any}::emplace should
return the constructed value.
* include/std/any (any_cast(any*)): Forward-declare.
(emplace(_Args&&...)): Change the return type and
return a referenc
On 16 March 2017 at 00:31, Jonathan Wakely wrote:
>> emplace(_Args&&... __args)
>> {
>> __do_emplace<_Decay<_ValueType>>
>> (std::forward<_Args>(__args)...);
>> + return *(std::any_cast<_Decay<_ValueType>>(this));
>
>
> Can we avoid the branch in any_cast to che
On 16 March 2017 at 15:02, Jonathan Wakely wrote:
> Richi reported a GCC 7 regression for a testcase from Cython that
> boils down to:
>
> void
> test01(int* first, int* last)
> {
> extern bool cmp(int, int);
> // PR libstdc++/80064
> // This is undefined, because [alg.sorting] requires the tem
Tested on Linux-x64.
2017-03-17 Ville Voutilainen
Implement LWG 2900, The copy and move constructors
of optional are not constexpr.
* include/std/optional (_Optional_payload): New.
(_Optional_base): Remove the bool parameter.
(_Optional_base<_Tp, false>):
Tested on Linux-PPC64.
2016-04-04 Ville Voutilainen
PR libstdc++/70437
* include/bits/stl_pair.h (_ConstructiblePair,
_ImplicitlyConvertiblePair, _MoveConstructiblePair,
_ImplicitlyMoveConvertiblePair): Add shortcut conditions
for same-type cases.
* testsuite/20_util
And yes, -ENOPATCH.
On 4 April 2016 at 21:42, Ville Voutilainen wrote:
> Tested on Linux-PPC64.
>
> 2016-04-04 Ville Voutilainen
>
> PR libstdc++/70437
> * include/bits/stl_pair.h (_ConstructiblePair,
> _ImplicitlyConvertiblePair, _
On 5 April 2016 at 13:53, Jonathan Wakely wrote:
> I wonder if we want an __is_samey trait that checks if two decayed
> types are the same.
If such checks become more common, then yes. For now, perhaps not.
> More seriously, a comment might be useful to explain that although
> these "concepts" r
t the library, where applicable. Such things can be
added with subsequent patches.
2016-09-12 Ville Voutilainen
Implement C++17 string searchers.
* include/std/functional: (unordered_map, vector): New includes
in C++17 mode.
(array, bits/stl_algo.h): Likewise.
(default_sea
On 12 September 2016 at 13:41, Jonathan Wakely wrote:
>> + template
>> +struct __is_std_equal_to : std::false_type { };
>> +
>> + template<>
>> +struct __is_std_equal_to> : std::true_type { };
>
>
> Is there a reason I didn't use an alias template or variable template here?
>
> template
On 12 September 2016 at 18:30, Jonathan Wakely wrote:
> On 12 September 2016 at 12:00, Ville Voutilainen wrote:
>> I didn't change any of those parts in the patch, I intentionally
>> avoided such changes.
>
> OK. I wrote a more detailed reply that will have to wait unt
On 12 September 2016 at 18:49, Jonathan Wakely wrote:
>>> Is there a reason I didn't use an alias template or variable template
>>> here?
>>>
>>> template
>>>using __is_std_equal_to = is_same, _Pred>;
>>>
>>> That avoids defining a new class template.
>>
>>
>> I don't know whether that's a pr
es.
2016-09-13 Ville Voutilainen
Implement P0040R3, Extending memory management tools.
* include/bits/stl_uninitialized.h (utility): New include
in C++17 mode.
(uninitialized_default_construct): New.
(uninitialized_default_construct_n): Likewise.
(uninitialized_
Tested on Linux-x64.
2016-09-19 Ville Voutilainen
PR libstdc++/77619
* include/bits/stl_construct.h: (_Construct_novalue): New.
(_Destroy_n_aux, _Destroy_n): New.
* include/bits/stl_uninitialized.h: (type_traits):
New include in C++11 mode
On 21 September 2016 at 12:31, Jonathan Wakely wrote:
> On 06/09/16 09:00 +0300, Ville Voutilainen wrote:
>>
>>PR libstdc++/77288
>>* include/std/optional (__is_optional_impl, __is_optional): Remove.
>>(__converts_from_optional, __assigns_from_optional
This problem is not introduced by the latest patch, but it's something that
we should look at anyway. There's been recent discussion about what
assignments do with variants that hold references. Consider this:
#include
int main()
{
float f1 = 1.0f, f2 = 2.0f;
std::variant v1(f1);
v1 =
On 22 September 2016 at 11:55, Christophe Lyon
wrote:
> The new test 77288.cc fails on old arm targets (armv5t):
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/20_util/optional/77288.cc:
> In function 'void test01()':
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/20_ut
On 22 September 2016 at 12:37, Christophe Lyon
wrote:
>> Does the attached patch fix the problem?
>
> Yes, thanks!
Here be the changelog. Jonathan, ok for trunk? Patch attached again
for convenience.
2016-09-22 Ville Voutilainen
Fix tests on old arm platforms
On 22 September 2016 at 13:03, Jonathan Wakely wrote:
> On 22/09/16 01:49 -0700, Tim Shen wrote:
>>
>> Done. When writing the initial version, I was trying to save as much
>> qualifications as possible (as long as the semantic doesn't change)
>> for readability, but that might not be a good idea.
On 21 September 2016 at 13:33, Jonathan Wakely wrote:
> This patch predates my testsuite changes, so this should now be
> { dg-do compile { target c++11 } }
> Otherwise OK for trunk, thanks.
So, this has been applied to trunk, and also applies cleanly to the
gcc-6 branch, and we need
to backport
Tested on Linux-x64.
2016-09-25 Ville Voutilainen
PR libstdc++/77717
* testsuite/21_strings/basic_string_view/operations/compare/char/1.cc:
Fix an out-of-bounds access.
diff --git
a/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/compare/char/1.cc
b/libstdc++-v3
Tested on Linux-x64.
2016-09-26 Ville Voutilainen
PR libstdc++/77727
* include/std/optional (optional(const optional<_Up>&)):
Default-initialize the base and use emplace.
(optional(optional<_Up>&&)): Likewise.
* testsuite/20_util/optional/cons/777
On 27 September 2016 at 03:16, Christophe Lyon
wrote:
> 20_util/declval/requirements/1_neg.cc (test for errors, line 2263)
> 20_util/declval/requirements/1_neg.cc (test for excess errors)
> 20_util/make_signed/requirements/typedefs_neg.cc (test for errors, line
> 1928)
> 20_util/make_si
301 - 400 of 632 matches
Mail list logo
