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.
