#ifdef __cplusplus namespace __cxxabiv1 { typedef __cxa_cdtor_return_type (*__cxa_cdtor_type)(void *); extern "C" { #endif // Allocate array. void* __cxa_vec_new(size_t __element_count, size_t __element_size, size_t __padding_size, __cxa_cdtor_type constructor, __cxa_cdtor_type destructor); When the above snippet from cxxabi.h gets parsed as "C" then __cxa_cdtor_type won't be defined, the declaration needs to move out of the #ifdef to inside the extern "C" part.
Actually we have to becareful here. What does the IA64 C++ ABI say about the arguments types to __cxa_vec_new, is __cxa_cdtor_type really extern "C" or did they forget to specify the language linkage?
(In reply to comment #1) The other thing is that I think this is a regression from when the ARM eabi support was added.
Ok. My understanding of CXX ABI isn't that great. Some would say "I just code with C/C++" but I also happen to know that that isn't true. Take what I say here as "I'm a user of C/C++ and my understanding of everything behind the scenes may not quite be what it should". It's a typedef for a function pointer that takes a void* parameter. Whether we use it in C/C++ the actual calling semantics should be the same afaik. aka, we push the void* onto the stack, and issue the call to the given pointer address. The size of the actual pointer should be the same size whether we use C or C++, so I fail to see how this would make a difference. The other solution is to close the #ifdef and re-open it, and that imho will look a lot uglier. It won't make a difference to the "C" compiled version (when compared to moving the typedef), whereas I simply fail to see the difference when compiling as a "C++" program (if there is any). As for regression, this worked in 3.4.6, at which point the typedef was absent, and instead the function pointer signatures was handled inside the function declarations: void* __cxa_vec_new(size_t __element_count, size_t __element_size, size_t __padding_size, void (*__constructor) (void*), void (*__destructor) (void*));
Caused by: 2004-09-15 Mark Mitchell <mark@codesourcery.com> * config/cpu/arm/cxxabi_tweaks.h (__cxa_cdtor_return_type): Define. * config/cpu/generic/cxxabi_tweaks.h (__cxa_cdtor_return_type): Define. * libsupc++/cxxabi.h (__cxa_cdtor_return_type): New type.
The language linkage of the type is supposed to matter in some cases -- but G++ doesn't implement that, so I don't think the difference is observable in GNU C++. In any case, we should try to make the file compile in C -- or else remove the #ifdefs -- so, even if we want to keep the C++ linkage for the type, we should provide a declaration in C mode.
I'm reassigning to Benjamin...
I'm following up to the mailing list in the PR trail, since it's very confusing to go back and forth between the two. The technical issue is that in the following code: extern "C" { typedef void (*p1)(); } typedef void (*p2)(); p1 and p2 are distinct types, and, in fact, you can overload based on that. G++ doesn't implement that distinction; we don't keep track of language linkage for types (just for functions) but we should, and, at some point, I'm sure we'll implement that. The reason this is in the standard is so that an implementation can use different calling conventions for C and C++. So, when calling through a function pointer you have to know which kind of function you're calling. (And, yes, name-mangling is supposed to encode the linkage of the function type, when mangling a pointer-to-function type.) So, changing the linkage of __cxa_cdtor_return_type (that name is not specified in the ABI, by the way), technically changes the type of __cxa_vec_new. However, the ABI specification does say that __cxa_vec_new is declared extern "C", and, since it specifically gives this prototype: extern "C" void * __cxa_vec_new ( size_t element_count, size_t element_size, size_t padding_size, void (*constructor) ( void *this ), void (*destructor) ( void *this ) ); that means that the type of the constructor and destructor arguments are also required to be pointers-to-C-functions. In summary, I think Benjamin's proposed change (to change the constructor type to have extern "C" linkage) is in fact required by the ABI. Although it's technically a source-incompatible change, since G++ doesn't implement linkage for function pointers, there's no way that a user of G++ can tell the difference. Therefore, I think that's the right thing to do.
Subject: Bug 29095 Author: bkoz Date: Mon Oct 9 23:53:35 2006 New Revision: 117589 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117589 Log: 2006-10-09 Benjamin Kosnik <bkoz@redhat.com> PR libstdc++/29095 * libsupc++/cxxabi.h (__cxa_cdtor_type): Explicit "C" linkage. * config/cpu/arm/cxxabi_tweaks.h: Same. * config/cpu/generic/cxxabi_tweaks.h: Same. * testsuite/abi: Add. * testsuite/abi/header_cxxabi.cc: New. * testsuite/demangle: Move... * testsuite/abi/demangle: ...here. * testsuite/libstdc++-dg/conformance.exp: Adjust testsuite file calculation. * scripts/create_testsuite_files: Same. * testsuite/lib/libstdc++.exp (v3_target_compile_as_c): New. (libstdc++-dg-test): Use it. Added: trunk/libstdc++-v3/testsuite/abi/ trunk/libstdc++-v3/testsuite/abi/demangle/ - copied from r117575, trunk/libstdc++-v3/testsuite/demangle/ trunk/libstdc++-v3/testsuite/abi/header_cxxabi.c Removed: trunk/libstdc++-v3/testsuite/demangle/ Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/cpu/arm/cxxabi_tweaks.h trunk/libstdc++-v3/config/cpu/generic/cxxabi_tweaks.h trunk/libstdc++-v3/libsupc++/cxxabi.h trunk/libstdc++-v3/scripts/create_testsuite_files trunk/libstdc++-v3/testsuite/lib/libstdc++.exp trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
Subject: Bug 29095 Author: bkoz Date: Wed Oct 11 08:30:42 2006 New Revision: 117629 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117629 Log: 2006-10-09 Benjamin Kosnik <bkoz@redhat.com> PR libstdc++/29095 * libsupc++/cxxabi.h (__cxa_cdtor_type): Explicit "C" linkage. * config/cpu/arm/cxxabi_tweaks.h: Same. * config/cpu/generic/cxxabi_tweaks.h: Same. Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/config/cpu/arm/cxxabi_tweaks.h branches/gcc-4_1-branch/libstdc++-v3/config/cpu/generic/cxxabi_tweaks.h branches/gcc-4_1-branch/libstdc++-v3/libsupc++/cxxabi.h
Fixed in mainline and gcc-4.1.2.
Benjamin, I'm seeing these failures: http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00654.html http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00575.html Are you sure the patch is ok wrt "source-less" (I don't remember the exact name of the procedure, sorry) testing (Codesourcery testing, in other terms)?
Paolo you are correct, non-build testing is at issue. I'm trying to fix...
Subject: Bug 29095 Author: bkoz Date: Mon Oct 16 17:22:38 2006 New Revision: 117788 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117788 Log: 2006-10-16 Benjamin Kosnik <bkoz@redhat.com> PR libstdc++/29095 continued * testsuite/lib/libstdc++.exp (v3_target_compile_as_c): Additions so that testing not in the build directory works for the "C" target language. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/lib/libstdc++.exp