On 26/11/16 14:47 +0200, Ville Voutilainen wrote:
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -287,6 +287,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
swap(array<_Tp, _Nm>& __one, array<_Tp, _Nm>& __two)
noexcept(noexcept(__one.swap(__two)))
{ __one.swap(_
On 26/11/16 14:47 +0200, Ville Voutilainen wrote:
Updated patches attached, and tested with the full testsuite on Linux-PPC64.
Both patches are OK for trunk with the minor tweaks noted below.
Thanks.
diff --git a/libstdc++-v3/include/bits/stl_pair.h
b/libstdc++-v3/include/bits/stl_pair.h
in
On 22 November 2016 at 17:06, Jonathan Wakely wrote:
>> so I can certainly change all these swaps to use operator! rather than
>> __not_. Is the
>> patch otherwise ok for trunk? What about the tuple part?
>
>
> Yes, OK changing the top-level __not_s to operator!
> I haven't reviewed the tuple part
On 22/11/16 16:59 +0200, Ville Voutilainen wrote:
On 22 November 2016 at 15:36, Jonathan Wakely wrote:
+#if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or
gnu++11
+ template
+inline
+typename enable_if<__not_<__and_<__is_swappable<_T1>,
+
On 22 November 2016 at 15:36, Jonathan Wakely wrote:
>> +#if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or
>> gnu++11
>> + template
>> +inline
>> +typename enable_if<__not_<__and_<__is_swappable<_T1>,
>> +__is_swappable<_T2>>>::value>::
On 17/11/16 23:38 +0200, Ville Voutilainen wrote:
@@ -478,6 +478,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
swap(pair<_T1, _T2>& __x, pair<_T1, _T2>& __y)
noexcept(noexcept(__x.swap(__y)))
{ __x.swap(__y); }
+
+#if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or gnu++11
+
On 18 November 2016 at 15:54, Jonathan Wakely wrote:
> I agree, but if we'd just refused to support such undefined behaviour
> in stage 1 we wouldn't now be in a position of saying we can't change
> it in stage 3.
I want to support the code that the previous attempt breaks. I don't
think I can do
On 17/11/16 23:38 +0200, Ville Voutilainen wrote:
The first patch does everything but the container adaptor parts (which
are wrong in the p/r) and the tuple part (which is icky). The second
part does the tuple parts, and needs some serious RFC. I know
it's ugly as sin, but it works. I don't think
The first patch does everything but the container adaptor parts (which
are wrong in the p/r) and the tuple part (which is icky). The second
part does the tuple parts, and needs some serious RFC. I know
it's ugly as sin, but it works. I don't think we should try to teach
our tuple to give the right
