This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3 PATCH] PR libstdc++/66338
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 26 May 2016 16:30:04 +0100
- Subject: Re: [v3 PATCH] PR libstdc++/66338
- Authentication-results: sourceware.org; auth=none
- References: <CAFk2RUZQvzrRYLJd1Up1mXK7GHV9GP1a6OjnhxKA0pvUberDbg at mail dot gmail dot com> <CAFk2RUZnnXP6Vxr0D0r3r7Z5pQwif_rYu-Lnt6L0w76t3UO8DA at mail dot gmail dot com> <CAFk2RUZcehY2LJK5G9PokbAvtOveHdqbCzLUeb-U5BjLWKV7Hw at mail dot gmail dot com> <20160525135552 dot GJ14158 at redhat dot com> <CAFk2RUaOy+V4w0GtwxOc2gnbMznx0R=7eDeU3KmgBwj_XOhw-g at mail dot gmail dot com>
On 26/05/16 01:07 +0300, Ville Voutilainen wrote:
On 25 May 2016 at 16:55, Jonathan Wakely <jwakely@redhat.com> wrote:
On 24/05/16 19:49 +0300, Ville Voutilainen wrote:
On 24 May 2016 at 19:35, Ville Voutilainen <ville.voutilainen@gmail.com>
wrote:
Slight tweak. The avoidance of _NotSameTuple wasn't quite correct for
the templates that
take const tuple<_UElements...>& or tuple<_UElements...>&& instead of
const _UElements&...
or _UElements&&...
This patch introduces a new helper alias to cover those cases and
takes it into use where appropriate.
All tests pass, but I don't have any sane tests to verify this tweak.
..and I don't need to be quite so round-about in the new helper, it
can just check !is_same
instead of doing a nested _TC call. Changelog the same as in the previous
one.
OK for trunk - thanks.
Ack, I will do the mechanics in the forthcoming days, but here's a
question: what do we want to do
about this patch for the gcc6-branch? I fully appreciate being careful
and not committing to the branch right now,
but presumably this patch is a candidate for backporting to gcc6.
Yes, I think so.
There's a trade-off between giving it more time on the trunk for any
issues to arise before we backport it, or putting it on the branch now
and giving more time for problems to show up there because more people
are testing the branch.
I think it shouldn't cause any regressions, so can go on the branch
sooner rather than later.