| Message ID | CAFk2RUZfDmbZn=50_26KjtXzqNiZxj-Oi++kQoo4+DXZ9y6v=w@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 18/12/16 13:33 +0200, Ville Voutilainen wrote: >Andrzej Krzemienski pointed this out in a discussion related to any and tags. >Our two-element tuple specialization doesn't make the perfect-forwarding >constructor and the allocator constructor properly mutually exclusive; this >patch fixes that. > >Tested on Linux-x64, ok for trunk, gcc-6 and gcc-5? gcc-6-branch is frozen, so not there. OK for trunk and gcc-5-branch. Should this be reported as a defect in the standard?
On 19 December 2016 at 12:19, Jonathan Wakely <jwakely@redhat.com> wrote: > On 18/12/16 13:33 +0200, Ville Voutilainen wrote: >> >> Andrzej Krzemienski pointed this out in a discussion related to any and >> tags. >> Our two-element tuple specialization doesn't make the perfect-forwarding >> constructor and the allocator constructor properly mutually exclusive; >> this >> patch fixes that. >> >> Tested on Linux-x64, ok for trunk, gcc-6 and gcc-5? > > > gcc-6-branch is frozen, so not there. Not now, but when that branch reopens, presumably then? > Should this be reported as a defect in the standard? I don't think so, the standard doesn't specify a two-argument specialization and the variadic signature specified doesn't run into this problem. We can certainly give the other vendors a heads-up in case their implementations suffer from the same problem but the standard itself is not defective.
On 19/12/16 14:34 +0200, Ville Voutilainen wrote: >On 19 December 2016 at 12:19, Jonathan Wakely <jwakely@redhat.com> wrote: >> On 18/12/16 13:33 +0200, Ville Voutilainen wrote: >>> >>> Andrzej Krzemienski pointed this out in a discussion related to any and >>> tags. >>> Our two-element tuple specialization doesn't make the perfect-forwarding >>> constructor and the allocator constructor properly mutually exclusive; >>> this >>> patch fixes that. >>> >>> Tested on Linux-x64, ok for trunk, gcc-6 and gcc-5? >> >> >> gcc-6-branch is frozen, so not there. > >Not now, but when that branch reopens, presumably then? Yes please, for the 6.4 release. >> Should this be reported as a defect in the standard? > >I don't think so, the standard doesn't specify a two-argument >specialization and the variadic >signature specified doesn't run into this problem. We can certainly >give the other vendors a heads-up >in case their implementations suffer from the same problem but the >standard itself is not defective. Ah of course, the 2-argument specialization is only implied by the "only if sizeof...(Types) == 2" comments but not actually specified.
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple index 13e0bf8..9dbdd8d 100644 --- a/libstdc++-v3/include/std/tuple +++ b/libstdc++-v3/include/std/tuple @@ -951,7 +951,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION enable_if<_TMC::template _MoveConstructibleTuple<_U1, _U2>() && _TMC::template - _ImplicitlyMoveConvertibleTuple<_U1, _U2>(), + _ImplicitlyMoveConvertibleTuple<_U1, _U2>() + && !is_same<typename decay<_U1>::type, + allocator_arg_t>::value, bool>::type = true> constexpr tuple(_U1&& __a1, _U2&& __a2) : _Inherited(std::forward<_U1>(__a1), std::forward<_U2>(__a2)) { } @@ -960,7 +962,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION enable_if<_TMC::template _MoveConstructibleTuple<_U1, _U2>() && !_TMC::template - _ImplicitlyMoveConvertibleTuple<_U1, _U2>(), + _ImplicitlyMoveConvertibleTuple<_U1, _U2>() + && !is_same<typename decay<_U1>::type, + allocator_arg_t>::value, bool>::type = false> explicit constexpr tuple(_U1&& __a1, _U2&& __a2) : _Inherited(std::forward<_U1>(__a1), std::forward<_U2>(__a2)) { } diff --git a/libstdc++-v3/testsuite/20_util/tuple/cons/allocator_with_any.cc b/libstdc++-v3/testsuite/20_util/tuple/cons/allocator_with_any.cc new file mode 100644 index 0000000..9f86c93 --- /dev/null +++ b/libstdc++-v3/testsuite/20_util/tuple/cons/allocator_with_any.cc @@ -0,0 +1,42 @@ +// { dg-do run { target c++14 } } + +// Copyright (C) 2016 Free Software Foundation, Inc. +// +// This file is part of the GNU ISO C++ Library. This library is free +// software; you can redistribute it and/or modify it under the +// terms of the GNU General Public License as published by the +// Free Software Foundation; either version 3, or (at your option) +// any later version. + +// This library is distributed in the hope that it will be useful, +// but WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +// GNU General Public License for more details. + +// You should have received a copy of the GNU General Public License along +// with this library; see the file COPYING3. If not see +// <http://www.gnu.org/licenses/>. + + +// NOTE: This makes use of the fact that we know how moveable +// is implemented on tuple. If the implementation changed +// this test may begin to fail. + +#include <tuple> +#include <experimental/any> +#include <testsuite_hooks.h> + +using std::experimental::any; + +void test01() +{ + std::tuple<any, any> t(std::allocator_arg, + std::allocator<any>{}); + VERIFY(std::get<0>(t).empty()); + VERIFY(std::get<1>(t).empty()); +} + +int main() +{ + test01(); +} diff --git a/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc b/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc index 5bcf576..7da61e5 100644 --- a/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc +++ b/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc @@ -17,7 +17,7 @@ // { dg-options "-fno-show-column" } // { dg-do compile { target c++14 } } -// { dg-error "in range" "" { target *-*-* } 1280 } +// { dg-error "in range" "" { target *-*-* } 1284 } #include <tuple>
Andrzej Krzemienski pointed this out in a discussion related to any and tags. Our two-element tuple specialization doesn't make the perfect-forwarding constructor and the allocator constructor properly mutually exclusive; this patch fixes that. Tested on Linux-x64, ok for trunk, gcc-6 and gcc-5? 2016-12-18 Ville Voutilainen <ville.voutilainen@gmail.com> Make the perfect-forwarding constructor of a two-element tuple sfinae away when the first argument is an allocator_arg. * include/std/tuple (tuple(_U1&&, _U2&&)): Constrain. * testsuite/20_util/tuple/cons/allocator_with_any.cc: New. * testsuite/20_util/tuple/element_access/get_neg.cc: Adjust.