This ICE occurs under unique/odd but reproducible conditions. The key components of the environment for this bug appear to be: 1. 'bool' is typedef'd to a new type which is then #define'd over the existing 'bool' type (this is the case in the common.h head from the ldns package, http://www.nlnetlabs.nl/projects/ldns/). 2. A user-defined class inherits from a templated base class, like std::vector<string>. 3. This same class calls a noexcept method on a vector member (which appears to trigger the build_noexcept_spec function). This bug is reproducible with the following code on gcc-4.7. It compiles without error on gcc-4.6: ---------------------------------------------- typedef bool _Bool; # define bool _Bool #include <vector> #include <iostream> #include <cstring> using namespace std; class Test : public vector<string> { public: Test (Test& that) { arr = std::move(that.arr); } private: std::vector<int*> arr; };
4.7.1 gets an ICE too, but it works on trunk. As it's undefined behaviour (bool is a keyword) and it already works on trunk it might not be worth changing anything.
Confirmed as a regression with r192148. A minor issue IMHO too.
ICEs with -std=c++0x only, also ICEs on trunk.
Created attachment 28874 [details] gcc48-pr54207.patch The testcase is invalid, you can't add typedefs with system reserved names before including standard headers, nor redefine keywords to something else. That said, in this patch is a testcase which IMHO is valid and still ICEs even with current trunk. The thing is that perform_implicit_conversion will not do anything if the type is same_type_p, but different (B vs. bool in this testcase, _Bool vs. bool in the original testcase). In both cases the other type is also a BOOLEAN_TYPE, but distinct from the original one. Doing == boolean_true_node or == boolean_false_node comparison doesn't work in that case, they aren't pointer equal (as they have distinct type), yet they operand_equal_p true. So, either we use operand_equal_p as this patch does (the patch guards it with INTEGER_CST check to avoid calling operand_equal_p unnecessarily, but that can be certainly dropped and done unconditionally if Jason prefers that), or we could for INTEGER_CSTs fold_convert them to boolean_type_node, then the pointer equality comparison would work.
Author: jakub Date: Thu Dec 6 18:55:48 2012 New Revision: 194263 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194263 Log: PR c++/54207 * except.c (build_noexcept_spec): Avoid direct comparison with boolean_true_node or boolean_false_node, instead use operand_equal_p and/or INTEGER_CST check. * pt.c (tsubst_exception_specification): Likewise. * typeck2.c (merge_exception_specifiers): Likewise. * g++.dg/cpp0x/noexcept18.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/except.c trunk/gcc/cp/pt.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
Fixed on the trunk so far.
Author: jakub Date: Fri Feb 1 14:05:42 2013 New Revision: 195653 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195653 Log: Backported from mainline 2012-12-13 Jakub Jelinek <jakub@redhat.com> PR c++/55652 * typeck2.c (merge_exception_specifiers): Don't call operand_equal_p if noex is NULL. * g++.dg/cpp0x/noexcept19.C: New test. 2012-12-06 Jakub Jelinek <jakub@redhat.com> PR c++/54207 * except.c (build_noexcept_spec): Avoid direct comparison with boolean_true_node or boolean_false_node, instead use operand_equal_p and/or INTEGER_CST check. * pt.c (tsubst_exception_specification): Likewise. * typeck2.c (merge_exception_specifiers): Likewise. * g++.dg/cpp0x/noexcept18.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/noexcept18.C branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/noexcept19.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/except.c branches/gcc-4_7-branch/gcc/cp/pt.c branches/gcc-4_7-branch/gcc/cp/typeck2.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
Fixed.
*** Bug 52371 has been marked as a duplicate of this bug. ***