https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
--- Comment #15 from Jonathan Wakely ---
Author: redi
Date: Fri May 12 15:53:19 2017
New Revision: 247978
URL: https://gcc.gnu.org/viewcvs?rev=247978&root=gcc&view=rev
Log:
PR libstdc++/78939 make tuple_size depend on tuple_size
PR libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
--- Comment #14 from Jonathan Wakely ---
Author: redi
Date: Fri May 12 14:43:11 2017
New Revision: 247973
URL: https://gcc.gnu.org/viewcvs?rev=247973&root=gcc&view=rev
Log:
PR libstdc++/78939 make tuple_size depend on tuple_size
PR libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
Markus Trippelsdorf changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|7.0 |7.2
--- Comment #12 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
--- Comment #11 from Jonathan Wakely ---
Oops, that was the previous diff, I meant to paste this (which constrains the
__enable_if_has_tuple_size to only be used when _Tp has no cv-quals, so we
avoid ambiguities):
--- a/libstdc++-v3/include/std/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
--- Comment #10 from Jonathan Wakely ---
This works around the ambiguity that PR 79960 describes:
--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -88,24 +88,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct tupl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> These all fail for the same reason, and I think it's a FE bug.
Reported as PR 79960 (seems to be a regression since 4.9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
--- Comment #8 from Jonathan Wakely ---
No, no change. I think we need to change the tuple_size specializations
to be incomplete when tuple_size is incomplete, even though that appears to
contradict the changes made by lwg 2770.
--- a/libstdc++-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
--- Comment #7 from Jakub Jelinek ---
Has there been any resolution for the GB20 vs. LWG2446 conflict in Kona?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Last reconfirmed|2016-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
Jonathan Wakely changed:
What|Removed |Added
CC||kreckel at ginac dot de
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
Ville Voutilainen changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
--- Comment #4 from Björn Fahller ---
It also only partially solves the problem. If the struct is made const, or the
decomposition declaration is changed to "auto const& [p] = s;", it still fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
--- Comment #3 from Jakub Jelinek ---
But that goes against
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2446
So, I think GB 20 is in conflict with LWG2446, we can have just one of those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
--- Comment #2 from Jakub Jelinek ---
I think this boils down if
#include
struct S { int s; };
std::tuple_size t;
is valid or not (with instead of it is invalid).
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 2770. tuple_size specialization is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
17 matches
Mail list logo
