[Bug c++/53611] New: class with hidden visibility cause function returns pointer to class also be hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53611
Bug #: 53611
Summary: class with hidden visibility cause function returns
pointer to class also be hidden
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kirbyz...@sogou-inc.com
[root@djt-17-109-v06 tmp]# cat tvisi.cpp
extern "C" typedef struct __cook cook_t;
extern "C" cook_t* myopen();
struct __attribute__ ((visibility ("hidden"))) __cook {
virtual ~__cook() = 0;
};
//__attribute__ ((visibility ("default")))
cook_t* myopen()
{
return 0;
}
[root@djt-17-109-v06 tmp]# g++ tvisi.cpp -o libxx.so -shared -fPIC && nm -D
libxx.so | fgrep myopen
05cc T myopen
The function myopen is exported by g++ 4.4.6
[root@djt-17-109-v06 tmp]# g++47 tvisi.cpp -o libxx.so -shared -fPIC && nm -D
libxx.so | fgrep myopen
[root@djt-17-109-v06 tmp]#
The function myopen is not exported by g++ 4.7.0
Workaround: define '__cook' after the definition of 'myopen'
[Bug c++/53613] New: Cannot override a inline "= default" virtual destructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613
Bug #: 53613
Summary: Cannot override a inline "= default" virtual
destructor.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kirbyz...@sogou-inc.com
[root@djt-17-109-v06 tmp]# cat tover.cpp
struct __cook {
virtual ~__cook() = default;
};
struct __cook1: public __cook {
virtual ~__cook1() = default;
};
struct __cook2: public __cook {
virtual ~__cook2();
};
__cook2::~__cook2() {};
struct __cook3: public __cook {
virtual ~__cook3();
};
__cook3::~__cook3() = default;
[root@djt-17-109-v06 tmp]# g++47 -c -std=gnu++11 tover.cpp
tover.cpp:6:10: error: looser throw specifier for 'virtual __cook1::~__cook1()'
tover.cpp:2:10: error: overriding 'virtual __cook::~__cook() noexcept (true)'
tover.cpp:10:10: error: looser throw specifier for 'virtual
__cook2::~__cook2()'
tover.cpp:2:10: error: overriding 'virtual __cook::~__cook() noexcept (true)'
tover.cpp:15:10: error: looser throw specifier for 'virtual
__cook3::~__cook3()'
tover.cpp:2:10: error: overriding 'virtual __cook::~__cook() noexcept (true)
'
[root@djt-17-109-v06 tmp]# g++ -c -std=gnu++0x tover.cpp
# g++ 4.4.6 works
Workaround: define parent destructor outside the class definition.
[root@djt-17-109-v06 tmp]# cat tover.cpp
struct __cook {
virtual ~__cook();
};
__cook::~__cook() = default;
/*...*/
[Bug c++/53611] class with hidden visibility cause function returns pointer to class also be hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53611 --- Comment #1 from Kirby Zhou 2012-06-08 11:16:36 UTC --- gcc source base: DATE 20120604 svn://gcc.gnu.org/svn/gcc/branches/redhat/gcc-4_7-branch@188193
[Bug c++/53611] class with hidden visibility cause function returns pointer to class also be hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53611 --- Comment #3 from Kirby Zhou 2012-06-09 09:43:09 UTC --- If "myopen" returns "__cook", I will agree with you. But "myopen" returns "__cook *", just a pointer. I do not think it is reasonable to hide "myopen". It is a usual method to hide the implementation detail of cook_t, but exports some free function to operate with cook_t*, such as "FILE *". (In reply to comment #2) > I think this is expected behavior as if someone defines a "__cook" in the > executable which links to the shared library, it will be considered a > different > type.
[Bug c++/53613] Cannot override a inline "= default" virtual destructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613 --- Comment #3 from Kirby Zhou 2012-06-11 10:15:58 UTC --- (In reply to comment #1) > Fixed on trunk by patch for PR 50043 Did this patch apply to 4.7 branch? I retested with 4.7 branch 20120610, The bug is still exist.
[Bug c++/53613] Cannot override a inline "= default" virtual destructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613 --- Comment #5 from Kirby Zhou 2012-06-12 02:39:44 UTC --- It is a BAD NEWS about no fix on the 4.7.X branch, and "it's not a regression." The bug breaks a lot of already exist oode which is workable with GCC-4.4.X release. (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > Fixed on trunk by patch for PR 50043 > > > > Did this patch apply to 4.7 branch? > PR 50043 shows a single commit to trunk and has Target Milestone 4.8.0, so no, > it's only fixed on trunk. > > I retested with 4.7 branch 20120610, The bug is still exist. > Yes, and it probably won't be fixed on the release branch as it's not a > regression. New features are not usually added to released versions. > In any case, there's a simple workaround of adding explicit 'noexcept' > specifiers, which will still work with 4.8 > I'm marking this as a dup of PR 50043 as the failure to compile is a direct > consequence of not implementing DR 1123 > *** This bug has been marked as a duplicate of bug 50043 ***
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043 --- Comment #13 from Kirby Zhou 2012-06-13 03:48:34 UTC --- How about back port this patch to 4.7 branch? It cause a lot of compile error which easily confuse programmers. (In reply to comment #9) > Author: paolo > Date: Mon Apr 2 00:13:30 2012 > New Revision: 186058 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186058 > Log: > /cp > 2012-04-01 Paolo Carlini > > PR c++/50043 > * class.c (deduce_noexcept_on_destructor, > deduce_noexcept_on_destructors): New. > (check_bases_and_members): Call the latter. > * decl.c (grokfndecl): Call the former. > * method.c (implicitly_declare_fn): Not static. > * cp-tree.h (deduce_noexcept_on_destructor, implicitly_declare_fn): > Declare > > /testsuite > 2012-04-01 Paolo Carlini > > PR c++/50043 > * g++.dg/cpp0x/noexcept17.C: New. > * g++.old-deja/g++.eh/cleanup1.C: Adjust. > * g++.dg/tree-ssa/ehcleanup-1.C: Likewise. > * g++.dg/cpp0x/noexcept01.C: Likewise. > * g++.dg/eh/init-temp1.C: Likewise. > * g++.dg/eh/ctor1.C: Likwise. > > Added: > trunk/gcc/testsuite/g++.dg/cpp0x/noexcept17.C > Modified: > trunk/gcc/cp/ChangeLog > trunk/gcc/cp/class.c > trunk/gcc/cp/cp-tree.h > trunk/gcc/cp/decl.c > trunk/gcc/cp/method.c > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/g++.dg/cpp0x/noexcept01.C > trunk/gcc/testsuite/g++.dg/eh/ctor1.C > trunk/gcc/testsuite/g++.dg/eh/init-temp1.C > trunk/gcc/testsuite/g++.dg/tree-ssa/ehcleanup-1.C > trunk/gcc/testsuite/g++.old-deja/g++.eh/cleanup1.C
[Bug c++/53654] New: move constructor incorrectly delete copy constructor defined by template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53654
Bug #: 53654
Summary: move constructor incorrectly delete copy constructor
defined by template
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kirbyz...@sogou-inc.com
shared_ptr declares its copy constructor and assign operator by template (if
Y == T). But the nontrivial copy constructor is been deleted by the move
constructor declaration.
template
struct shared_ptr
{
template
shared_ptr( shared_ptr const & r );
template
shared_ptr& operator=( shared_ptr && r );
shared_ptr( shared_ptr && r );
shared_ptr& operator=( shared_ptr && r );
};
struct TTransport {
};
struct TProtocol {
shared_ptr func()
{
return p_;
}
shared_ptr p_;
};
]# g++47 -std=gnu++0x -c tshareptr.cpp
tshareptr.cpp: In member function 'shared_ptr TProtocol::func()':
tshareptr.cpp:20:10: error: use of deleted function 'constexpr
shared_ptr::shared_ptr(const shared_ptr&)'
tshareptr.cpp:3:8: note: 'constexpr shared_ptr::shared_ptr(const
shared_ptr&)' is implicitly declared as deleted because
'shared_ptr' declares a move constructor or move assignment
operator
Workaround:
declare a separate copy constructor individually.
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043 --- Comment #14 from Kirby Zhou 2012-06-15 02:14:48 UTC --- I have tested to apply this patch to 4.7 branch, everythings goes well. Since it breaks already existing code, anybody can do commit backport to 4.7 branch? (In reply to comment #13) > How about back port this patch to 4.7 branch? > It cause a lot of compile error which easily confuse programmers. > (In reply to comment #9) > > Author: paolo > > Date: Mon Apr 2 00:13:30 2012 > > New Revision: 186058 > > > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186058 > > Log: > > /cp > > 2012-04-01 Paolo Carlini > > > > PR c++/50043 > > * class.c (deduce_noexcept_on_destructor, > > deduce_noexcept_on_destructors): New. > > (check_bases_and_members): Call the latter. > > * decl.c (grokfndecl): Call the former. > > * method.c (implicitly_declare_fn): Not static. > > * cp-tree.h (deduce_noexcept_on_destructor, implicitly_declare_fn): > > Declare > > > > /testsuite > > 2012-04-01 Paolo Carlini > > > > PR c++/50043 > > * g++.dg/cpp0x/noexcept17.C: New. > > * g++.old-deja/g++.eh/cleanup1.C: Adjust. > > * g++.dg/tree-ssa/ehcleanup-1.C: Likewise. > > * g++.dg/cpp0x/noexcept01.C: Likewise. > > * g++.dg/eh/init-temp1.C: Likewise. > > * g++.dg/eh/ctor1.C: Likwise. > > > > Added: > > trunk/gcc/testsuite/g++.dg/cpp0x/noexcept17.C > > Modified: > > trunk/gcc/cp/ChangeLog > > trunk/gcc/cp/class.c > > trunk/gcc/cp/cp-tree.h > > trunk/gcc/cp/decl.c > > trunk/gcc/cp/method.c > > trunk/gcc/testsuite/ChangeLog > > trunk/gcc/testsuite/g++.dg/cpp0x/noexcept01.C > > trunk/gcc/testsuite/g++.dg/eh/ctor1.C > > trunk/gcc/testsuite/g++.dg/eh/init-temp1.C > > trunk/gcc/testsuite/g++.dg/tree-ssa/ehcleanup-1.C > > trunk/gcc/testsuite/g++.old-deja/g++.eh/cleanup1.C
