This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: tuple move constructor
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 26 May 2016 19:49:25 +0200 (CEST)
- Subject: Re: tuple move constructor
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1604202233060 dot 21596 at laptop-mg dot saclay dot inria dot fr> <CAH6eHdRO6kfWqb5K_Nr5WYvHCJNNyQeKSN8VF5c-Ov32HOpU4g at mail dot gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1604211902320 dot 27091 at laptop-mg dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 02 dot 1605232038220 dot 30609 at laptop-mg dot saclay dot inria dot fr> <20160525135413 dot GI14158 at redhat dot com> <20160526153703 dot GE20700 at redhat dot com>
On Thu, 26 May 2016, Jonathan Wakely wrote:
On 25/05/16 14:54 +0100, Jonathan Wakely wrote:
On 23/05/16 20:39 +0200, Marc Glisse wrote:
Ping
(re-attaching, I just added a one-line comment before the tag class as
asked by Ville)
This is OK for trunk - thanks.
On second thoughts - does this change the passing conventions for
std::tuple if it gets a trivial move ctor?
Note that this part of the ABI is ill-defined
http://sourcerytools.com/pipermail/cxx-abi-dev/2016-February/002884.html
but yes, good catch, it does change the passing convention (by value), and
not just for weirdo types, it even changes for tuple<int>. It is clearly a
change in the right direction, not passing tuple<int> in a register is
weird, but yeah, compatibility :-(
I don't even want to think of trying to fix this issue in C++11 while
artificially preserving the non-triviality of tuple, the headache is not
worth it. I guess I'll open an entry in bugzilla with the ABI tag and let
it rot there...
Maybe we could
#if __cpp_concepts >= 201500
the alternative discussed with Ville
#endif
but that won't fix the fact that tuple<int> should be trivially move
constructible...
We could add __attribute__(non_trivial_for_purpose_of_passing_convention),
but I think abi_tag has already stretched enough the idea that gcc is
following the itanium abi.
Bah, forget this patch. Thanks for noticing early, that spares me the
trouble of reverting later.
--
Marc Glisse