* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
@ 2011-11-30 19:34 ` redi at gcc dot gnu.org
2011-11-30 19:40 ` paolo.carlini at oracle dot com
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-11-30 19:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2011-11-30
AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-30 19:08:57 UTC ---
I'll have a go at implementing __is_final, using Paolo's work for PR 26099 as a
starting point.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
2011-11-30 19:34 ` [Bug libstdc++/51365] " redi at gcc dot gnu.org
@ 2011-11-30 19:40 ` paolo.carlini at oracle dot com
2011-11-30 21:26 ` redi at gcc dot gnu.org
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-11-30 19:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-11-30 19:22:32 UTC ---
Yes, should be pretty trivial given the infrastructure already in place. In
semantics should be just matter of calling CLASS_TYPE_P && CLASSTYPE_FINAL
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
2011-11-30 19:34 ` [Bug libstdc++/51365] " redi at gcc dot gnu.org
2011-11-30 19:40 ` paolo.carlini at oracle dot com
@ 2011-11-30 21:26 ` redi at gcc dot gnu.org
2011-11-30 21:30 ` redi at gcc dot gnu.org
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-11-30 21:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-30 21:06:25 UTC ---
Created attachment 25961
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25961
front end patch (missing docs and tests)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (2 preceding siblings ...)
2011-11-30 21:26 ` redi at gcc dot gnu.org
@ 2011-11-30 21:30 ` redi at gcc dot gnu.org
2011-11-30 21:30 ` redi at gcc dot gnu.org
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-11-30 21:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-30 21:19:28 UTC ---
Thanks for the pointer, the hardest part was naming the new intrinsic ;)
We can't have the front-end define __is_final() as an intrinsic and also define
std::__is_final as a class template, so the patches above define
__is_final_class() and std::__is_final<>
It might be better for the front end to define __is_final() then use that
directly in the library and not provide a type trait unless std::is_final gets
added to the library by a DR.
i.e. in <tuple>
template<typename _Tp>
using __empty_base
= typename conditional<__is_final(_Tp), false_type, is_empty<_Tp>>::type;
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (3 preceding siblings ...)
2011-11-30 21:30 ` redi at gcc dot gnu.org
@ 2011-11-30 21:30 ` redi at gcc dot gnu.org
2011-11-30 23:51 ` redi at gcc dot gnu.org
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-11-30 21:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-30 21:07:00 UTC ---
Created attachment 25962
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25962
library patch (missing tests)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (4 preceding siblings ...)
2011-11-30 21:30 ` redi at gcc dot gnu.org
@ 2011-11-30 23:51 ` redi at gcc dot gnu.org
2011-12-01 1:07 ` redi at gcc dot gnu.org
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-11-30 23:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-30 23:35:00 UTC ---
Created attachment 25963
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25963
fix other parts of library
here's a proof of concept patch showing how to fix existing code that inherits
from allocators so that it is ABI-compatible for non-final allocators and also
supports final allocators (by inheriting from a wrapper class instead).
Something like this needs to be done for the containers so they stay backwards
compatible but also work with final types.
(I decided to rename the intrinsic to __is_final and that's what this patch
uses)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (5 preceding siblings ...)
2011-11-30 23:51 ` redi at gcc dot gnu.org
@ 2011-12-01 1:07 ` redi at gcc dot gnu.org
2011-12-03 12:06 ` redi at gcc dot gnu.org
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-12-01 1:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-01 01:07:27 UTC ---
Here's another testcase:
#include <future>
#include <memory>
template<typename T>
struct final_allocator final : std::allocator<T>
{
final_allocator() = default;
template<typename U>
final_allocator(const final_allocator<U>&) { }
template<typename U>
struct rebind { typedef final_allocator<U> other; };
};
final_allocator<int> a;
std::promise<int> p(std::allocator_arg, a);
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (6 preceding siblings ...)
2011-12-01 1:07 ` redi at gcc dot gnu.org
@ 2011-12-03 12:06 ` redi at gcc dot gnu.org
2011-12-11 12:55 ` marc.glisse at normalesup dot org
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-12-03 12:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-03 12:06:08 UTC ---
patch implementing __is_final submitted for approval:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00231.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (7 preceding siblings ...)
2011-12-03 12:06 ` redi at gcc dot gnu.org
@ 2011-12-11 12:55 ` marc.glisse at normalesup dot org
2011-12-11 13:51 ` redi at gcc dot gnu.org
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: marc.glisse at normalesup dot org @ 2011-12-11 12:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
Marc Glisse <marc.glisse at normalesup dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marc.glisse at normalesup
| |dot org
--- Comment #9 from Marc Glisse <marc.glisse at normalesup dot org> 2011-12-11 12:12:29 UTC ---
Hello,
the recent discussion "Structure alignment changes when a constructor or
destructor is added" on gcc-help made me wonder whether it would make sense to
not only derive for empty classes, but actually derive by default and use
members only when necessary (builtin types, final classes). The advantage would
be that derivation allows for a slightly more compact representation in some
cases with the g++ ABI. I really haven't thought much about the consequences.
Sorry for hijacking this bug with this wild idea, but in case it makes sense it
might change slightly the way you want to fix it.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (8 preceding siblings ...)
2011-12-11 12:55 ` marc.glisse at normalesup dot org
@ 2011-12-11 13:51 ` redi at gcc dot gnu.org
2011-12-11 13:56 ` marc.glisse at normalesup dot org
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-12-11 13:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-11 13:39:20 UTC ---
I haven't really thought about it either, but one advantage of depending on
is_empty is that it prevents using the EBO for polymorphic classes, where
derivation could have undesirable effects. That *shouldn't* be a problem as
long as user-defined types don't have virtual functions using reserved names
such as _M_get.
Another problem could be user-defined types with a virtual base, if the tuple
node type (which would be the most-derived type) doesn't know how to construct
the virtual base.
struct A { A(int) { } };
struct B : virtual A { B() : A(1) { } };
std::tuple<B> t;
If tuple derived from B it couldn't construct the A subobject correctly.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (9 preceding siblings ...)
2011-12-11 13:51 ` redi at gcc dot gnu.org
@ 2011-12-11 13:56 ` marc.glisse at normalesup dot org
2011-12-15 10:06 ` redi at gcc dot gnu.org
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: marc.glisse at normalesup dot org @ 2011-12-11 13:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #11 from Marc Glisse <marc.glisse at normalesup dot org> 2011-12-11 13:51:20 UTC ---
(In reply to comment #10)
> I haven't really thought about it either, but one advantage of depending on
> is_empty is that it prevents using the EBO for polymorphic classes, where
> derivation could have undesirable effects.
Ah, right, the set of types that can safely be derived from is rather
restricted: non-builtin, non-final, non-virtual (and possibly more
constraints). And to benefit from additional packing: non-C++03-POD. Probably
not worth the trouble...
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (10 preceding siblings ...)
2011-12-11 13:56 ` marc.glisse at normalesup dot org
@ 2011-12-15 10:06 ` redi at gcc dot gnu.org
2011-12-15 10:10 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-12-15 10:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-15 10:02:50 UTC ---
Author: redi
Date: Thu Dec 15 10:02:45 2011
New Revision: 182360
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182360
Log:
c-family:
PR libstdc++/51365
* c-common.c (RID_IS_FINAL): Add.
* c-common.h (RID_IS_FINAL): Add.
cp:
PR libstdc++/51365
* cp-tree.h (CPTK_IS_FINAL): Add.
* parser.c (cp_parser_translation_unit): Handle RID_IS_FINAL.
(cp_parser_primary_expression, cp_parser_trait_expr): Likewise.
* semantics.c (trait_expr_value, finish_trait_expr): Handle
CPTK_IS_FINAL.
* cxx-pretty-print.c (pp_cxx_trait_expression): Likewise.
testsuite:
PR libstdc++/51365
* g++.dg/ext/is_final.C: New.
Added:
trunk/gcc/testsuite/g++.dg/ext/is_final.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cxx-pretty-print.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (11 preceding siblings ...)
2011-12-15 10:06 ` redi at gcc dot gnu.org
@ 2011-12-15 10:10 ` redi at gcc dot gnu.org
2011-12-20 9:14 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-12-15 10:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-15 10:06:19 UTC ---
front end changes done, I'll work on the library parts this weekend
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (12 preceding siblings ...)
2011-12-15 10:10 ` redi at gcc dot gnu.org
@ 2011-12-20 9:14 ` redi at gcc dot gnu.org
2012-02-04 13:54 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2011-12-20 9:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-20 09:09:56 UTC ---
Author: redi
Date: Tue Dec 20 09:09:50 2011
New Revision: 182523
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182523
Log:
PR libstdc++/51365
* include/std/tuple (_Tuple_impl): Check __is_final as well as
is_empty.
* testsuite/20_util/tuple/51365.cc: New.
Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/51365.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (13 preceding siblings ...)
2011-12-20 9:14 ` redi at gcc dot gnu.org
@ 2012-02-04 13:54 ` redi at gcc dot gnu.org
2013-03-22 14:45 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2012-02-04 13:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.8.0
--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-04 13:53:44 UTC ---
Given the number of other PRs I'm working on and that we're in stage4 I'm not
going to handle 'final' allocators for 4.7 so I'll come back to it for 4.8
(when I also plan to update all the containers to use C++11 allocators)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (14 preceding siblings ...)
2012-02-04 13:54 ` redi at gcc dot gnu.org
@ 2013-03-22 14:45 ` jakub at gcc dot gnu.org
2013-04-28 11:40 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-03-22 14:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.8.0 |4.8.1
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-22 14:44:18 UTC ---
GCC 4.8.0 is being released, adjusting target milestone.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (15 preceding siblings ...)
2013-03-22 14:45 ` jakub at gcc dot gnu.org
@ 2013-04-28 11:40 ` redi at gcc dot gnu.org
2014-04-22 11:36 ` jakub at gcc dot gnu.org
2014-04-22 14:36 ` redi at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2013-04-28 11:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.8.1 |4.9.0
--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-04-28 11:40:24 UTC ---
shared_ptr fixed to handle final allocators by:
Author: redi
Date: Sun Apr 28 11:38:21 2013
New Revision: 198367
URL: http://gcc.gnu.org/viewcvs?rev=198367&root=gcc&view=rev
Log:
PR libstdc++/51365
* include/bits/shared_ptr_base (_Sp_ebo_helper): Helper class to
implement EBO safely.
(_Sp_counted_base::_M_get_deleter): Add noexcept.
(_Sp_counter_ptr): Use noexcept instead of comments.
(_Sp_counted_deleter): Likewise. Use _Sp_ebo_helper.
(_Sp_counted_ptr_inplace): Likewise.
* testsuite/20_util/shared_ptr/cons/51365.cc: New.
* testsuite/20_util/shared_ptr/cons/52924.cc: Add rebind member to
custom allocator and test construction with custom allocator.
* testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust dg-error
line number.
Added:
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/51365.cc
- copied, changed from r198365,
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/52924.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr_base.h
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/52924.cc
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (16 preceding siblings ...)
2013-04-28 11:40 ` redi at gcc dot gnu.org
@ 2014-04-22 11:36 ` jakub at gcc dot gnu.org
2014-04-22 14:36 ` redi at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-04-22 11:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.9.0 |4.9.1
--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.0 has been released
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/51365] cannot use final empty class in std::tuple
2011-11-30 19:22 [Bug libstdc++/51365] New: cannot use final empty class in std::tuple redi at gcc dot gnu.org
` (17 preceding siblings ...)
2014-04-22 11:36 ` jakub at gcc dot gnu.org
@ 2014-04-22 14:36 ` redi at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2014-04-22 14:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
Target Milestone|4.9.1 |4.7.0
--- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm closing this as fixed, I've created Bug 60921 to deal with the remaining
final allocator issues.
^ permalink raw reply [flat|nested] 20+ messages in thread