The following program fails to compile with Clang++ 3.2: #include <typeinfo> #include <exception> const char* get_name( const std::exception_ptr eptr ) { return eptr.__cxa_exception_type()->name(); } int main() {} The output in the shell is: $ g++-4.7 -std=c++0x -O3 -Wall -Wextra t.cc -o t $ clang++-3.2 -std=c++0x -O3 -Wall -Wextra t.cc -o t t.cc:6:37: error: member access into incomplete type 'const class type_info' return eptr.__cxa_exception_type()->name(); ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/exception_ptr.h:144:19: note: forward declaration of 'std::__exception_ptr::type_info' const class type_info* ^ 1 error generated. $ The problem is that <typeinfo> includes <exception> before it forward-declares std::type_info. In <exception>, type_info is used in the context of std::__exception_ptr, thus Clang generates an implicit forward-declaration for std::__exception_ptr::type_info and, when used in the above code, consequently fails. Further discussion has taken place at <http://stackoverflow.com/q/15098174>.
Something like this should fix it --- a/libstdc++-v3/libsupc++/exception_ptr.h +++ b/libstdc++-v3/libsupc++/exception_ptr.h @@ -44,6 +44,8 @@ extern "C++" { namespace std { + class type_info; + /** * @addtogroup exceptions * @{ @@ -141,7 +143,7 @@ namespace std operator==(const exception_ptr&, const exception_ptr&) _GLIBCXX_USE_NOEXCEPT __attribute__ ((__pure__)); - const class type_info* + const std::type_info* __cxa_exception_type() const _GLIBCXX_USE_NOEXCEPT __attribute__ ((__pure__)); };
Is that something g++ should diagnose too? Or is this because init_rtti_processing forward declares std::type_info class automatically?
It's because of the implicit declaration of std::type_info, G++ correctly diagnoses similar cases with altered namespace names or type names, it only happens for std::type_info. I see no harm in adding an explicit declaration to the libstdc++ header so it works with clang and other compilers that don't declare std::type_info automatically.
(In reply to comment #1) I think the first line you added is enough, as evidenced by my "fix" referenced in the Stack Overflow discussion (see link above). But the second line won't hurt either.
Author: redi Date: Sat Mar 16 20:01:16 2013 New Revision: 196709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196709 Log: PR libstdc++/56468 * libsupc++/exception_ptr.h (type_info): Declare. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/exception_ptr.h
Author: redi Date: Sat Mar 16 20:22:40 2013 New Revision: 196711 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196711 Log: PR libstdc++/56468 * libsupc++/exception_ptr.h (type_info): Declare. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/libsupc++/exception_ptr.h
Fixed on trunk and 4.7 branch so far, the fix will also be done for 4.8.1
(In reply to comment #7) > Fixed on trunk and 4.7 branch so far, the fix will also be done for 4.8.1 It's unusual for a bug to be fixed for a previous release and for trunk, but not on the latest release. Isn't this worth applying to GCC 4.8.0 also? The patch looks safe and simple enough...
Yeah, I think this patch is fine even for 4.8.0, and there is no need to do another RC for that.
Author: redi Date: Sun Mar 17 14:10:39 2013 New Revision: 196749 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196749 Log: PR libstdc++/56468 * libsupc++/exception_ptr.h (type_info): Declare. Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/libsupc++/exception_ptr.h
OK, thanks, guys, this is done then.