[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; /*...*/
Fixed on trunk by patch for PR 50043
(In reply to comment #0) > Workaround: define parent destructor outside the class definition. Or add explicit 'noexcept' specifiers to the derived destructors.
(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.
(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 ***
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 ***
As I said, there's a simple workaround.
As the testcase compiles with 4.4.x and trunk, but doesn't in 4.6.x and 4.7.x, I'd call this a 4.6/4.7 Regression (unless what 4.4.x compiled it into was completely broken). The question is if the patch is safely backportable though.
I think it compiles with 4.4 because __cook::~__cook is not noexcept, because 4.4 doesn't infer an empty throw spec for a trivial destructor. If you add throw() to ~__cook you get the same errors about looser throw specifiers. So 4.4 was generating different code, but in this example it makes no practical difference because you can't use the noexcept operator in 4.4 to test whether something has an empty exception specifier anyway.