public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/53648] New: nested empty tuple
@ 2012-06-12 16:22 chesstr at hotmail dot com
2012-06-12 16:42 ` [Bug c++/53648] nested empty tuples redi at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: chesstr at hotmail dot com @ 2012-06-12 16:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
Bug #: 53648
Summary: nested empty tuple
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: chesstr@hotmail.com
#include <tuple>
int main(){
auto b = std::tuple<std::tuple<std::tuple<>>>{};
}
gives :
error: 'std::_Tuple_impl<1ul>' is an ambiguous base of 'std::_Tuple_impl<0ul,
std::tuple<std::tuple<> > >'
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/53648] nested empty tuples
2012-06-12 16:22 [Bug c++/53648] New: nested empty tuple chesstr at hotmail dot com
@ 2012-06-12 16:42 ` redi at gcc dot gnu.org
2012-06-12 17:13 ` [Bug libstdc++/53648] [C++11] " chesstr at hotmail dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2012-06-12 16:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-06-12
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-06-12 16:42:37 UTC ---
I have a fix for this already, IIRC it's simply a case of not using the EBO for
a tuple that contains std::tuple<>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/53648] [C++11] nested empty tuples
2012-06-12 16:22 [Bug c++/53648] New: nested empty tuple chesstr at hotmail dot com
2012-06-12 16:42 ` [Bug c++/53648] nested empty tuples redi at gcc dot gnu.org
@ 2012-06-12 17:13 ` chesstr at hotmail dot com
2012-06-12 17:28 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: chesstr at hotmail dot com @ 2012-06-12 17:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
--- Comment #2 from chesstr at hotmail dot com 2012-06-12 17:13:33 UTC ---
(In reply to comment #1)
> I have a fix for this already, IIRC it's simply a case of not using the EBO for
> a tuple that contains std::tuple<>
Yes, an easy fix in tuple implementation by modifying __empty_not_final as
below compiles :
template<typename _Tp>
using __empty_not_final
= typename conditional<__is_final(_Tp)||is_same<_Tp,tuple<>>::value,
false_type, is_empty<_Tp>>::type;
instead of
template<typename _Tp>
using __empty_not_final
= typename conditional<__is_final(_Tp), false_type, is_empty<_Tp>>::type;
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/53648] [C++11] nested empty tuples
2012-06-12 16:22 [Bug c++/53648] New: nested empty tuple chesstr at hotmail dot com
2012-06-12 16:42 ` [Bug c++/53648] nested empty tuples redi at gcc dot gnu.org
2012-06-12 17:13 ` [Bug libstdc++/53648] [C++11] " chesstr at hotmail dot com
@ 2012-06-12 17:28 ` redi at gcc dot gnu.org
2012-06-12 18:04 ` chesstr at hotmail dot com
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2012-06-12 17:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-06-12 17:27:50 UTC ---
There are other cases involving non-empty tuples that will still result in an
ambiguity e.g.
struct A { };
auto d = tuple<tuple<tuple<A, A>, A>, A>{};
My solution avoids using the EBO for some condition I don't remember (the
code's on another machine) but it handles all the cases I tested.
I also preserve the property that sizeof(tuple<char, tuple<>>)==1, which I
think your suggestion loses.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/53648] [C++11] nested empty tuples
2012-06-12 16:22 [Bug c++/53648] New: nested empty tuple chesstr at hotmail dot com
` (2 preceding siblings ...)
2012-06-12 17:28 ` redi at gcc dot gnu.org
@ 2012-06-12 18:04 ` chesstr at hotmail dot com
2012-06-14 22:07 ` redi at gcc dot gnu.org
2012-06-14 22:12 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: chesstr at hotmail dot com @ 2012-06-12 18:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
--- Comment #4 from chesstr at hotmail dot com 2012-06-12 18:03:56 UTC ---
(In reply to comment #3)
> There are other cases involving non-empty tuples that will still result in an
> ambiguity e.g.
>
> struct A { };
> auto d = tuple<tuple<tuple<A, A>, A>, A>{};
>
> My solution avoids using the EBO for some condition I don't remember (the
> code's on another machine) but it handles all the cases I tested.
>
> I also preserve the property that sizeof(tuple<char, tuple<>>)==1, which I
> think your suggestion loses.
You are right, the suggestion does not solve the real problem at all. Nice
example.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/53648] [C++11] nested empty tuples
2012-06-12 16:22 [Bug c++/53648] New: nested empty tuple chesstr at hotmail dot com
` (3 preceding siblings ...)
2012-06-12 18:04 ` chesstr at hotmail dot com
@ 2012-06-14 22:07 ` redi at gcc dot gnu.org
2012-06-14 22:12 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2012-06-14 22:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-06-14 22:07:37 UTC ---
Author: redi
Date: Thu Jun 14 22:07:33 2012
New Revision: 188636
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188636
Log:
PR libstdc++/53648
* include/std/tuple (__empty_not_final): Do not use EBO for tuples.
* testsuite/20_util/tuple/53648.cc: New.
* testsuite/20_util/uses_allocator/cons_neg.cc: Adjust dg-error line
number.
Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/53648.cc
- copied, changed from r188635,
trunk/libstdc++-v3/testsuite/20_util/uses_allocator/cons_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple
trunk/libstdc++-v3/testsuite/20_util/uses_allocator/cons_neg.cc
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/53648] [C++11] nested empty tuples
2012-06-12 16:22 [Bug c++/53648] New: nested empty tuple chesstr at hotmail dot com
` (4 preceding siblings ...)
2012-06-14 22:07 ` redi at gcc dot gnu.org
@ 2012-06-14 22:12 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2012-06-14 22:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.8.0
Known to fail| |4.7.1
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-06-14 22:12:13 UTC ---
Fixed
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-06-14 22:12 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-12 16:22 [Bug c++/53648] New: nested empty tuple chesstr at hotmail dot com
2012-06-12 16:42 ` [Bug c++/53648] nested empty tuples redi at gcc dot gnu.org
2012-06-12 17:13 ` [Bug libstdc++/53648] [C++11] " chesstr at hotmail dot com
2012-06-12 17:28 ` redi at gcc dot gnu.org
2012-06-12 18:04 ` chesstr at hotmail dot com
2012-06-14 22:07 ` redi at gcc dot gnu.org
2012-06-14 22:12 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).