This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: tuple move constructor
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 26 May 2016 18:56:33 +0100
- 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> <alpine dot DEB dot 2 dot 20 dot 1605261827060 dot 2019 at laptop-mg dot saclay dot inria dot fr>
On 26/05/16 19:49 +0200, Marc Glisse wrote:
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...
Please do.
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.
I have a dream of resurrecting the gnu-versioned-namespace config (and
bumping from std::__7 / libstdc++.so.7 to std::__8 / libstdc++.so.8)
so that people who don't want backwards compatibility can use that
mode, which would enable various nice optimizations that can't be made
in the default mode because of compatibility.
This would be something we should change when that config is in use.
So hopefully if you open a bugzilla entry it won't rot forever, but
only until I realise my dream.